C# 語言即將在未來的版本（預計 .NET 11 預覽，.NET 12 正式發布）中對 unsafe 關鍵字進行重大重新設計。這次改動的核心目標是將記憶體安全從單純的語法限制，提升為一套可審核、可強制執行的合約機制，使其在設計理念上更接近 Rust 和 Swift。
對於大多數開發者來說，這次更新幾乎沒有影響，因為絕大多數 C# 程式碼都運行在安全模式下。但對於需要處理原生互操作（Interop）或追求極限效能而必須使用 unsafe 的工程師來說，這將徹底改變撰寫與審核不安全程式碼的方式。
理解記憶體安全的核心不變量
在 .NET 中，記憶體安全的核心是不變量：每一次記憶體訪問必須指向活著的記憶體（Live Memory），即該記憶體必須已分配、已初始化且在訪問時仍可用。
安全程式碼（Safe Code）透過編譯器規則與執行時檢查（如 Bounds Checking 邊界檢查）來保證這一點。然而，當我們進入 unsafe 領域時，編譯器無法驗證這些條件，這就產生了未定義行為（Undefined Behavior, UB）的風險，這也是大多數安全性漏洞的根源。
新舊模型的根本差異
在 C# 1.0 的舊模型中，unsafe 關鍵字主要用來建立一個上下文（Context）。只要在類別或方法上標記 unsafe，該範圍內就可以使用指標（Pointer）等功能。這種方式將 unsafe 視為一種語法權限，而非一種安全承諾。
C# 16 的新模型將 unsafe 從語法標記轉變為合約標記。它將不安全操作分為三個層次：
內部 unsafe 區塊（Inner unsafe block）：所有真正危險的操作（如指標解引用、呼叫不安全成員）必須被包裹在 unsafe 中，並在註釋中說明為何此處是安全的。
對欄位（Fields）的影響
新模型同樣將 unsafe 擴展到欄位。當一個欄位的類型無法完整表達其不變量時（例如一個原生指標與其對應長度的關係），該欄位應標記為 unsafe。這會強制所有對該欄位的寫入操作都必須在 unsafe 區塊中進行，從而確保維護該不變量的邏輯在審核時能被集中發現。
對 AI 輔助開發的意義
隨著 AI 生成程式碼的普及，人類審核的壓力劇增。新模型將安全檢查從人類的經驗審核轉移到編譯器強制執行。如果專案啟用了新模型且禁用了 AllowUnsafeBlocks，AI 生成的任何不安全程式碼都無法通過編譯。這將記憶體安全審核從檢查每一行 diff，簡化為檢查一個專案屬性。
導入與相容性
此模型將採取選擇性加入（Opt-in）的方式。開發者可以透過專案屬性開啟新模型。對於舊有的二進位庫，編譯器將採取相容模式，確保指標類型的傳播依然有效，避免安全等級在升級過程中意外下降。
總結
C# 16 的記憶體安全更新並不是讓不安全程式碼變得更容易撰寫，而是讓它變得更容易推理與審核。透過將不安全操作強制區域化（Inner Block）、明確化（Safety Doc）與層級化（Propagation vs Suppression），C# 正在構建一套與現代系統語言同步的安全工程標準。
來源：devblogs.microsoft.com - Improving C# Memory Safety
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。