C# 靜態欄位初始化順序：診斷與修正

C# 類別若在靜態欄位初始器中讀取另一個尚未完成初始化的靜態欄位，該類別可能在執行靜態初始化時失敗。外層例外通常是 TypeInitializationException，可採取行動的根因則位於 InnerException。這篇文章以 .NET 9 的隔離式主控台專案說明文字順序、預設值、例外包裝與兩種修正方式，並提供可直接重現的固定版本測試。

直接答案：C# 靜態欄位為何會受到宣告順序影響

同一型別的靜態欄位初始器會依原始碼文字順序執行；較前面的初始器若讀取較後面的欄位，只會看到該欄位的預設值，因此參考型別可能是空值並讓型別初始化失敗。

關鍵不是欄位在檔案中看起來都「有指定值」，而是指定值何時生效。類別初始化時，所有靜態欄位會先取得預設值，再依文字順序執行欄位初始器。若類別沒有明確的靜態建構式，規格只保證這些初始器會在第一次使用該類別的靜態欄位之前執行，確切時機由實作決定。假設 All 先呼叫 BuildAll()，而 BuildAll() 依賴的 Source 宣告在後方，當方法執行時 Source 尚未跑到 new()。若建構式不接受空值，內層就會拋出可辨識的參數例外；執行階段再把它包成 TypeInitializationException。

這個錯誤容易被誤判為「偶發載入問題」，因為失敗點常不是應用程式啟動的第一行，而是某條首次使用相關靜態欄位的功能路徑。測試順序、反射或相依注入掃描也可能間接改變觀察到的觸發位置。然而，一旦該型別在目前處理序中初始化失敗，繼續重試同一靜態欄位並不是可靠的復原策略；應先修正初始化設計，再以新的處理序驗證。

先讀 InnerException，不要只處理外層例外

TypeInitializationException 是型別初始化失敗的外層訊號，不等於根因；診斷時必須記錄型別名稱、完整例外鏈與最內層堆疊，才能判斷是空值、格式、檔案或其他初始化工作失敗。

.NET API 文件指出，靜態建構式或欄位初始器拋出的例外會由執行階段包裝。這表示只看外層訊息通常只能知道「某型別初始化失敗」，無法知道哪個輸入違反前置條件。安全的調查方式是在本機測試中捕捉外層例外，檢查 InnerException 的型別與堆疊，並回到該型別所有靜態欄位初始器及靜態建構式逐一檢查。

不要用寬泛的 catch 吞掉例外後回傳空集合。那會把確定性缺陷轉成更晚發生的資料錯誤，讓後續呼叫端失去可觀察的失敗條件。也不要把修法簡化成在 BuildAll() 裡到處加入空值容忍；如果 Source 在設計上必須存在，容忍空值只會掩蓋宣告順序。較好的處置是讓依賴關係在程式結構上清楚可見。

修法一：先宣告依賴，再建立衍生靜態資料

當初始化工作純粹、快速且沒有外部副作用時，最直接的修法是把來源欄位放在衍生欄位之前，讓程式碼的文字順序與資料相依方向一致。

以下範例刻意同時保留錯誤、正確排序與延遲初始化三個型別。Bad.All 在 Bad.Source 賦值前執行；Ordered 先完成來源集合；Lazy 則把建置推遲到屬性第一次被讀取。範例只使用記憶體內固定字串，不接觸網路、資料庫、帳號或不可逆操作。

static class Ordered
{
    private static readonly List Source = new() { "alpha" };
    public static readonly List All = BuildAll();

    private static List BuildAll() => new(Source);
}

static class Lazy
{
    private static List? _all;
    private static readonly List Source = new() { "alpha" };
    public static List All => _all ??= BuildAll();

    private static List BuildAll() => new(Source);
}

排序修正的優點是簡單、沒有額外同步物件，而且一眼可看出先後關係。限制則是維護者日後重新排列欄位時可能再次引入相同缺陷。因此，若保留急切初始化，應加入專門碰觸該型別的測試，並在程式碼審查清單中要求「衍生欄位不得寫在依賴之前」。部分型別宣告分散在多個檔案時，更不應依賴檔案之間的文字順序，因為它不適合作為穩定契約。

修法二：用延遲初始化移除文字順序相依

當衍生資料建立成本較高、未必會被使用，或希望欄位排列不再決定正確性時，應使用具備清楚生命週期的延遲初始化，並為並行存取選擇適當同步語意。

最短的 _all ??= BuildAll() 能把建立時間推遲到屬性存取，但它不是所有並行情境的完整答案。兩個執行緒可能同時看到 _all 為空並各自呼叫建置方法；若建置方法純粹且結果等價，最終欄位仍可能得到可用結果，卻會重複工作。若要求工廠只執行一次，必須另選具備明確同步語意的機制，記錄其狀態轉換，並加入多執行緒測試。選擇前要先寫下需要保證的是「結果可用」還是「工廠只執行一次」。

延遲初始化也不能用來合理化外部副作用。靜態初始化若讀取可變設定、存取遠端資源或啟動背景工作，失敗時會把型別可用性與環境狀態綁在一起，並讓單元測試難以隔離。更務實的設計是把需要 I/O 的工作移到可注入服務，由組合根控制建立、重試與取消；靜態成員只保留不可變常數或純函式可推導的資料。

不可變性同樣重要。即使初始化順序正確，公開可變的 List 仍允許呼叫端修改全域內容。若資料是查表用途，應回傳唯讀介面、不可變集合或每次投影出的副本。這與初始化順序是兩個不同問題：前者確保第一次建立正確，後者確保建立後不被任意改寫。測試應分開驗收，避免只因程式沒有拋例外就判定設計安全。

驗證與重現：固定 .NET 9.0.305 觀察三種結果

這組測試已在排程環境以 .NET SDK 9.0.305 實際執行；建置為零警告、零錯誤，並觀察到錯誤型別被包裝、正確排序成功，以及延遲屬性重複讀取傳回同一個快取物件。

建立全新的隔離資料夾，加入 global.json 並把 SDK 固定為 9.0.305，再建立目標框架為 net9.0 的主控台專案。
在 Program.cs 放入 Bad、Ordered、Lazy 三個型別；Bad 必須讓 All 宣告在 Source 之前，另外兩個型別使用本文修法。
在專案資料夾執行 dotnet build --configuration Release && dotnet run --no-build --configuration Release，逐行核對可觀察標記。

完整測試核心如下；執行前置條件只有本機 .NET SDK 9.0.305，不需要容器或外部服務。

using System.Collections.Generic;

try
{
    _ = Bad.All;
    Console.WriteLine("BAD:NO_EXCEPTION");
}
catch (TypeInitializationException ex)
{
    Console.WriteLine($"BAD:{ex.GetType().Name}:{ex.InnerException?.GetType().Name}");
}

Console.WriteLine($"ORDERED:{Ordered.All.Count}");
Console.WriteLine($"LAZY:{Lazy.All.Count}:{ReferenceEquals(Lazy.All, Lazy.All)}");

static class Bad
{
    public static readonly List All = BuildAll();
    private static readonly List Source = new() { "alpha" };
    private static List BuildAll() => new(Source);
}

static class Ordered
{
    private static readonly List Source = new() { "alpha" };
    public static readonly List All = BuildAll();
    private static List BuildAll() => new(Source);
}

static class Lazy
{
    private static List? _all;
    private static readonly List Source = new() { "alpha" };
    public static List All => _all ??= BuildAll();
    private static List BuildAll() => new(Source);
}

預期輸出如下：

BAD:TypeInitializationException:ArgumentNullException
ORDERED:1
LAZY:1:True

本次真實輸出標記為 BAD:TypeInitializationException:ArgumentNullException、ORDERED:1 與 LAZY:1:True。第一個標記證明較後方來源欄位仍是預設空值，且執行階段保留了內層例外；第二個標記證明調整宣告順序後建立一筆資料；第三個標記證明示範屬性連續讀取傳回同一個快取物件。這些只驗證語意與修法，不代表任何效能數字。

失敗條件也要明確。若出現 BAD:NO_EXCEPTION，表示錯誤案例未按指定順序建置；若沒有 ArgumentNullException，應檢查建構式或框架版本是否不同；若 ORDERED 不是一，表示固定測試資料被改動；若 LAZY 最後不是 True，表示屬性沒有保留快取結果。每次改動靜態欄位結構後重新執行，才能避免測試只覆蓋過時版本。

程式碼審查與回歸測試清單

審查靜態狀態時，先畫出欄位之間的單向依賴，再確認初始化不做外部 I/O、失敗可觀察、並行保證明確、回傳資料不會被任意修改，最後用新處理序觸發一次。

搜尋所有 static 欄位初始器與靜態建構式，標記它們讀取的其他靜態成員。
確認來源欄位位於衍生欄位之前，或改用不依賴文字順序的延遲設計。
檢查工廠方法是否純粹；設定檔、遠端呼叫與背景工作應移到可注入服務。
需要單次建立保證時使用適當的執行緒安全機制，不把 ??= 當成萬用同步方案。
測試外層與內層例外，不要只斷言「會失敗」；同時驗證正確路徑的資料內容。
每個案例使用新的測試處理序，避免已完成或已失敗的型別狀態污染其他案例。
若公開的是集合，明確決定唯讀、不可變或副本語意，避免全域可變狀態。

這份清單也適用於將舊式靜態工具類別拆成服務的重構。第一階段先加入重現測試，第二階段使建立邏輯成為純函式，第三階段把需要環境輸入的部分移出靜態型別，最後才刪除舊入口。每一步都保留可觀察結果，比一次大幅改寫更容易判斷是哪個變更破壞契約。

官方依據與適用邊界

本文的核心結論由 C# 類別規格與 .NET 例外 API 文件交叉查核，兩個 HTTPS 頁面本次都實際開啟並回傳 HTTP 200；範例結果則來自本機固定版本測試。

C# 語言規格的靜態欄位初始化章節說明，靜態欄位變數初始器會轉換為指定動作，並依它們出現在類別宣告中的文字順序執行。官方連結：。

TypeInitializationException API 文件說明，當類別初始器拋出例外時，執行階段會建立外層例外，原始例外可從 InnerException 取得。官方連結：。

規格證據支持的是執行順序與例外包裝，不代表所有靜態初始化都應改成延遲模式。排序、受控的延遲初始化與注入服務各自解決不同問題：排序適合純粹且便宜的確定性資料；延遲模式適合未必使用或需要明確建立語意的資料；注入服務適合需要設定、I/O、取消或重試的工作。先定義生命週期與可觀察條件，再選擇機制，才能真正移除脆弱的隱性相依。