C# out 變數與 && 短路：修正 CS0165 確定指派錯誤

C# out 變數搭配 && 時出現 CS0165，通常不是編譯器不理解 out，而是右側方法可能因短路而完全不執行。只要程式在條件式之後讀取該區域變數，編譯器就必須證明每一條能走到讀取點的路徑都已完成指派；若左側可以是 false，這項證明便不成立。

本文把問題限定在 C# 的確定指派、條件邏輯 AND 與 out 參數，不延伸為一般非同步、LINQ、列舉或靜態初始化教學。範例只建立隔離的 .NET 10 主控台專案，不連接資料庫、網路服務或既有應用程式。核心搜尋意圖是：為什麼 out 已寫在方法呼叫中，後面仍然出現「使用未指派的區域變數」，以及如何用可驗證的控制流程修正。

為什麼 out 寫在 && 右側仍會觸發 CS0165？

&& 會在左側為假時跳過右側，因此右側方法中的 out 指派不是每條路徑都會發生；條件式結束後直接讀取變數，編譯器便無法證明它一定有值。

先看最小失敗形狀：宣告 decimal floor;，把 TryFloor(out floor) 放在 isComplete && ... 的右側，然後在下一行輸出 floor。人類讀者可能把注意力放在 TryFloor 的簽章，認為 out 保證方法回傳前一定賦值；但那項保證只在「方法真的被呼叫」時成立。當 isComplete 為 false，執行階段不需要進入 TryFloor，所以不存在可完成指派的方法呼叫。

CS0165 關心的是讀取點以前的所有可達控制流程，而不是某一條測試資料剛好走過的路徑。即使你知道正式資料中 isComplete 幾乎總為真，編譯器仍不能把「通常」當成語言保證。反過來說，把測試值暫時改成常數 true，也不代表原本變動條件已經安全；正式程式一旦恢復可變輸入，短路路徑仍然存在。

Microsoft 的 CS0165 文件把問題歸類為區域變數可能在指派前被讀取；條件邏輯運算子文件則明確說明 && 只在左運算元為真時才計算右運算元。兩份官方資料共同支持這個結論：out 規則沒有失效，真正缺少的是「右側呼叫必定發生」的控制流程證據。

這也說明為什麼錯誤位置常落在後面的 Console.WriteLine(floor)，而不是落在 TryFloor(out floor)。呼叫本身在被執行時可以合法指派；問題直到程式嘗試取得 floor 的值才具體化。閱讀錯誤時，應從被標記的讀取點往回追所有分支，不要只盯著 out 關鍵字。

確定指派分析實際在保護什麼？

確定指派是編譯期的控制流程證明：在取得區域變數值以前，每一條可到達該位置的路徑都必須已完成指派，否則程式即使某次測試能跑，也不能通過建置。

區域變數與欄位不同。欄位通常有型別預設值，區域變數則不會因為宣告就自動取得可讀取的業務值。這個差異讓拼字、分支遺漏及短路更早在建置階段被揭露。若語言允許未證明的區域變數讀取，程式可能把不具意義的內容當成有效計算結果，錯誤會從明確的編譯失敗變成更難追查的執行期資料問題。

分析單位是流程狀態，而不是變數名稱是否曾經出現在等號左側或 out 參數中。以下三條路徑要分開看：左側為真且方法回傳真、左側為真但方法回傳假、左側為假而右側完全跳過。前兩條路徑都會呼叫方法，因此符合 out 在正常回傳前必須賦值的規則；第三條路徑沒有呼叫方法，才是條件式之後不能讀取的原因。

方法回傳的布林值與 out 是否被賦值也不是同一個問題。依 C# 方法契約，只要方法正常回傳，out 參數就必須被指派，即使方法回傳 false 也一樣。因此，把「Try 方法回傳假」誤解成「out 沒有值」會混淆兩層語意。本文的重點不是方法內部漏賦值，而是方法外部可能根本沒進入呼叫。

編譯器的判定可被程式結構影響。例如在 if (condition && TryFloor(out var floor)) 的真分支內，兩個條件都已成立，右側必然執行過，所以 floor 在該區塊內可讀。離開這個能證明呼叫發生的範圍後，如果還有未執行右側的其他路徑，便不能任意把同一結論帶到外面。這是控制流程縮小變數可安全使用範圍的實際例子。

最穩定的修法：先呼叫，再組合條件

若後續流程無論條件結果如何都需要讀取 out 值，最清楚的修法是先單獨呼叫 Try 方法保存結果，再把布林結果與其他條件組合，讓指派與決策成為兩個可檢查步驟。

修正後的結構是 bool hasFloor = TryFloor(out floor);，接著才計算 isComplete && hasFloor。這樣所有走到後續讀取點的路徑都已經執行 TryFloor，編譯器可以證明 floor 已指派；程式碼審查者也能分開問兩個問題：計算是否成功，以及目前狀態是否允許採用該結果。

這個修法會改變一項行為：原本左側為假時不呼叫右側方法，拆開之後則每次都會呼叫。因此只有在方法安全、成本可接受，而且後續確實需要結果時才適用。若 Try 方法包含昂貴工作、可觀察副作用或不應在前置條件失敗時執行，不能為了消除編譯錯誤就盲目提前呼叫；應改用下一節的範圍內使用方式，或重新設計回傳模型。

方法命名也應協助審查。TryFloor 暗示回傳值表示能否取得符合契約的結果，而 floor 是輸出資料。若方法同時修改外部狀態、寫入檔案或觸發遠端操作，Try 模式便容易讓讀者低估副作用。本文測試中的方法只增加本機計數器並回傳固定數值，用於觀察是否被呼叫；這不是對正式業務方法的副作用建議。

不要用 floor = 0; 當成不加思考的修正。預先給預設值確實能讓確定指派成立，但它也可能讓「方法根本沒執行」與「方法成功算出零」變得無法區分。只有在零確實是公開契約中的有效預設，而且呼叫端能辨認資料來源時，初始化才是合理設計。否則應保留明確的成功旗標，或使用能表示缺值的資料模型。

何時應把 out 變數限制在 if 真分支？

若結果只有在前置條件與 Try 方法同時成功時才有意義，就把變數宣告在 if 條件內，並只在真分支讀取；這能保留短路，也讓有效範圍對應業務契約。

if (isComplete && TryFloor(out var floor)) 的真分支具有兩項已證明事實：isComplete 為真，而且 TryFloor 已被執行並回傳真。因此在區塊內使用 floor 是自然且安全的。假分支可能來自前置條件失敗，也可能來自 Try 方法回傳假；若需要區分兩者，應先拆出具名結果，而不是在假分支猜測是哪一段造成。

將變數限制在最小範圍還有維護優點。後續程式不會在缺少成功條件的地方誤用它，重構時也較不容易把讀取移出保護區。變數生命週期越長，需要記住的隱含條件越多；把值與成立條件放在同一個區塊，可以降低「值還在，但前提已不清楚」的風險。

需要注意的是，out var floor 的宣告範圍與「確定可安全讀取的流程位置」不是完全相同概念。名稱可能在較大的語法範圍中可見，但編譯器仍依流程判斷某個位置是否已指派。不要只因編輯器能自動完成變數名稱，就認定每一條路徑都可讀；最可靠的判斷仍是建置結果與清楚的分支結構。

若假分支也需要錯誤原因，建議回傳具名結果型別或錯誤列舉，而不是增加多個彼此依賴的 out 參數。本文不主張全面禁止 out，但當成功值、失敗原因及部分結果同時存在時，單一結果物件通常更容易測試。那是 API 設計議題；CS0165 的最小修正仍應先忠實處理短路路徑。

常見錯修與程式碼審查陷阱

最常見的錯修是為了讓編譯器安靜而加入任意預設值、重複呼叫 Try 方法，或移除短路條件；這些做法可能改變業務語意，卻沒有把資料有效性寫成可測試契約。

第一種錯修是把區域變數初始化為零，之後不保存 Try 方法是否真的執行。這會通過編譯，但呼叫端無法區分短路、計算失敗與合法零值。第二種錯修是在條件式內呼叫一次，後面為了取得值再呼叫一次。若方法耗時、依賴可變輸入或具有副作用，兩次結果可能不同；即使目前是純函式，重複工作也使程式意圖變得含糊。

第三種錯修是把 && 改成 &。布林 & 會計算兩側，表面上能讓右側呼叫發生，但它同時移除短路，可能在前置條件不成立時執行原本刻意避免的工作。運算子變更是語意變更，不是單純編譯器提示修正。只有需求明確要求兩側都執行，而且測試覆蓋例外與副作用時，才可考慮使用非短路運算子。

第四種錯修是使用 null-forgiving、警告停用或寬泛例外處理。CS0165 是編譯錯誤，不是可用註記合理化的可空性警告；即使換成其他資料型別，隱藏診斷也不會補上缺失的指派路徑。應讓程式結構表達何時呼叫、何時成功、何時可讀，而不是把工具的證據要求拿掉。

審查時可以使用四個問題：右側是否可能被短路？後續是否在條件外讀取輸出？提前呼叫是否會改變成本或副作用？預設值能否與真實結果清楚區分？若任何答案不明確，先建立最小測試，不要直接在既有大型方法內試錯。

驗證與重現：固定 .NET 10 建立失敗與成功對照

這組本機驗證用同一個固定 SDK 建立一個預期編譯失敗專案與一個成功專案，分別觀察 CS0165、真分支可讀，以及左側為假時右側未被呼叫。

前置條件：Windows 或其他可執行 .NET SDK 的本機環境、可寫入的全新資料夾，以及 .NET SDK 10.0.400。測試不引用第三方套件，不讀取既有專案，不連接外部服務。global.json 用來固定 SDK 選擇；若指定版本不存在，應停止並記錄前置條件不符，不要刪除版本鎖定後宣稱得到同一組結果。

建立根目錄 csharp-definite-assignment-lab，加入 global.json，再建立 Bad 與 Good 兩個子目錄。
將下列專案檔與程式碼存到對應目錄；先執行 Bad 建置，要求非零結束碼且診斷包含 CS0165。
執行 Good 專案，要求三行 PASS: 標記與零結束碼；任何缺少標記、例外或建置失敗都算未通過。

global.json：

{
  "sdk": {
    "version": "10.0.400",
    "rollForward": "disable"
  }
}

兩個子目錄都使用同一份專案檔，檔名分別為 Bad.csproj 與 Good.csproj：


  
    Exe
    net10.0
    enable
    enable
    true

Bad/Program.cs：

decimal floor;
bool isComplete = false;

Need(isComplete && TryFloor(out floor), "floor calculation");
Console.WriteLine(floor);

static bool TryFloor(out decimal floor)
{
    floor = 12.5m;
    return true;
}

static void Need(bool condition, string name)
{
    Console.WriteLine($"{name}:{condition}");
}

Good/Program.cs：

int calls = 0;
decimal floor;

bool hasFloor = TryFloor(out floor);
bool accepted = true && hasFloor;
Assert(accepted, "split-call-condition");
Assert(floor == 12.5m, "split-call-value");
Assert(calls == 1, "split-call-count");

calls = 0;
if (true && TryFloor(out decimal scopedFloor))
{
    Assert(scopedFloor == 12.5m, "if-block-value");
}
else
{
    throw new InvalidOperationException("The true branch should run.");
}
Assert(calls == 1, "if-block-count");

calls = 0;
bool skipped = false && TryFloor(out decimal unusedFloor);
Assert(!skipped, "short-circuit-result");
Assert(calls == 0, "short-circuit-skips-right-operand");

Console.WriteLine("PASS: split call assigns the out variable before later use");
Console.WriteLine("PASS: an out variable is readable inside the proven true branch");
Console.WriteLine("PASS: false && rightOperand skips the Try method");

bool TryFloor(out decimal value)
{
    calls++;
    value = 12.5m;
    return true;
}

static void Assert(bool condition, string name)
{
    if (!condition)
    {
        throw new InvalidOperationException($"FAIL:{name}");
    }
}

完整指令在根目錄執行：

dotnet --version
dotnet build Bad/Bad.csproj -c Release --nologo
dotnet run --project Good/Good.csproj -c Release --nologo

本次排程環境已實際執行。dotnet --version 回傳 10.0.400；Bad 專案建置以結束碼一失敗，診斷為 CS0165，指出 floor 可能未指派；Good 專案以結束碼零完成，並輸出三行 PASS。這是控制流程與編譯器診斷驗證，不是效能測試；未量測速度、記憶體或不同 SDK 的比較結果。

如何把這條規則放進日常維護？

維護時應把「結果何時存在」寫進控制流程與測試，而不是只求區域變數能編譯；先選擇提前計算或成功分支內使用，再以負向案例證明短路確實存在。

對既有程式碼，先搜尋含 && 或 || 的複合條件，再檢查右側是否含有 out、狀態變更或昂貴呼叫。接著追蹤輸出值在條件之後的讀取位置。這不是要求全面改寫所有 Try 模式，而是找出「呼叫可能跳過，但值卻被當成必然存在」的矛盾。

單元測試至少應包含左側為真、左側為假、Try 方法回傳真與回傳假。若提前呼叫是修法，再加一項呼叫次數斷言，確認方法是否按設計執行；若保留短路，則在左側為假時要求呼叫次數為零。呼叫次數不是效能指標，而是控制流程證據。

程式碼審查描述也應具體。不要只寫「修正未初始化變數」，而應寫「原本右側可能被短路，條件外讀取無法證明已指派；現在先取得結果後組合條件」或「現在只在成功分支使用輸出」。這種說法能讓下一位維護者知道哪些行為不得在重構時被無意改回去。

與站內既有 C# 文章相比，本題不討論靜態欄位文字順序、列舉數值契約、LINQ 回傳值丟棄或 async/await 完成語意。它處理的是區域變數在短路條件下的確定指派與可用範圍，搜尋問題、錯誤代碼及驗收方式均不同。來源筆記已完整閱讀，但只採用 out 位於 && 右側的通用語言陷阱，沒有帶入環境名稱、實際資料或個人成果。

結論與官方查核範圍

CS0165 的正確修法不是欺騙編譯器，而是讓控制流程明確證明輸出值已存在；需要條件外使用就先呼叫，需要保留短路就把使用限制在已證明成功的分支。

官方 CS0165 說明、布林邏輯運算子參考與 C# 變數規格頁面本次皆已以 HTTPS 實際開啟並回傳 HTTP 200。這些資料支持確定指派與短路語意；本機 .NET 10 測試則提供指定程式的可觀察結果。本文沒有宣稱所有 SDK 都輸出完全相同的在地化文字，也沒有把一次建置結果外推為跨版本相容性保證。

實務決策可縮成兩句：如果後面一定要用值，就讓產生值的呼叫一定發生；如果呼叫必須受前置條件保護，就只在能證明呼叫成功的分支使用值。兩種結構都比任意預設值、重複呼叫或改成非短路運算子更容易審查與回歸測試。

下一步是在獨立測試專案重現 Bad 與 Good 兩個案例，再把同樣的路徑分析套到自己的方法。先確認哪條路徑跳過呼叫、哪個位置讀取輸出，以及提前執行是否改變副作用；完成這三項判斷後，CS0165 就不再只是編譯器阻擋，而會成為可讀的流程契約檢查。