導(dǎo)讀：.NET 產(chǎn)品經(jīng)理 Richard Lander 披露了 C# 16 與 .NET 11/12 的核心藍(lán)圖——在不丟失 GC 的前提下，讓 C# 在底層內(nèi)存控制上更接近 Rust 的安全保障。

TL;DR

一句話概括這場(chǎng)變革：把「指針」從洪水猛獸變成可控工具，把真正的危險(xiǎn)精確到「解引用」這一刀。

核心數(shù)據(jù)：

• .NET 11 預(yù)覽版 → .NET 12 生產(chǎn)就緒
• 新模型代號(hào)：MemorySafetyRules 1
• 目標(biāo)：讓 C# 獲得「近似 Rust」的內(nèi)存安全，而非引入完整的借用檢查器

一、問題的根源：舊的 unsafe 太粗糙

1.1 舊模型的「冤案」

在經(jīng)典 C# 里，只要用了 int* 這類指針，就得套一層 unsafe 大括號(hào)。

問題是：這太過度了。

• 聲明一個(gè)指針 int* p = &value; —— 編譯器直接紅牌
• 但調(diào)個(gè) Marshal.AllocHGlobal() —— 居然是「安全」的？

這種「內(nèi)外不一致」讓代碼審計(jì)變成了真·掃雷游戲：

表面風(fēng)平浪靜，內(nèi)部暗流涌動(dòng)。

1.2 新模型的「翻案」

新規(guī)則把「非安全」的判定從「用指針」改成「解引用非托管內(nèi)存」。

二、stackalloc 的三條件：真危險(xiǎn)的精確定位

這是新模型最核心的技術(shù)突破。

只有同時(shí)滿足以下三條，stackalloc 才被判為 unsafe：

• 隱式轉(zhuǎn) Span：被轉(zhuǎn)換成 Span<T> 或 ReadOnlySpan<T>
• 無初始化列表：沒用 stackalloc int buf[4] = {1,2,3,4}
• 在 SkipLocalsInitAttribute 成員內(nèi)：內(nèi)存暴露未初始化垃圾數(shù)據(jù)

一句話：精準(zhǔn)鎖定物理危險(xiǎn)區(qū)域，不傷及無辜。

三、LDM 核心決策（2026年5月13日）

語言設(shè)計(jì)組的最新拍板：

3.1 safe 關(guān)鍵字

不用 SafeRuntime 那種元數(shù)據(jù)屬性，直接引入 safe 上下文關(guān)鍵字。

safe {
    // 這里面的代碼經(jīng)過編譯器安全審計(jì)
}

3.2 類型聲明上的 unsafe

直接標(biāo)為編譯期錯(cuò)誤。

unsafe class MyClass { }  // ? 廢棄！

正確姿勢(shì)：在具體成員上標(biāo)記。

3.3 字段的 unsafe

字段可以單獨(dú)標(biāo)記 unsafe。

unsafe struct Buffer {
    unsafe byte* Data;  // ? 讀取時(shí)需要 unsafe 上下文
}

3.4 簽名與實(shí)現(xiàn)的解耦

這是最重磅的設(shè)計(jì)變更：

// 新模型下：
unsafe void ProcessBuffer(byte* ptr) {
    // 簽名不安全？但方法體內(nèi)部可以是安全的！
    
    // 只有真的解引用時(shí)才需要 unsafe 塊
    unsafe {
        *ptr = 42;
    }
}

3.5 過渡期診斷

為了避免「升級(jí)空窗期」，編譯器很貼心：

• 沒開啟新模型的代碼調(diào)用新版指針成員？
• 調(diào)用方不在 unsafe 上下文？

→ 編譯警告/錯(cuò)誤，給你慢慢遷移的時(shí)間。

四、ref 安全性的「逃生通道」

ref 安全性分析很保守，經(jīng)常誤殺「實(shí)則安全」的代碼。

新模型在 unsafe 上下文中做了降級(jí)處理：

• 開啟 /unsafe
• 聲明 unsafe 上下文
• 顯式壓制警告

這就是「打破玻璃」的合法通道。

五、C# vs Rust：Runtime 的根本分歧

         .NET 垃圾回收器
    (自動(dòng)且不確定性地管理內(nèi)存)
              ↑
     [高性能路徑]
              ↓
+------------------+    +------------------+
| 次級(jí)引用下行借用 |    | ArrayPool 復(fù)用  |
| (ref struct /   |    | (無仿射所有權(quán)，  |
|  生命周期單向棧傳) |    | 面臨二次釋放隱患)|
+------------------+    +------------------+

Rust 靠的是所有權(quán)+生命周期+借用檢查器 → 完全靜態(tài)保障

C# 必須走另一條路：次級(jí)引用（Second-class References）

「只能往下傳，不能存堆上」—— 低追蹤成本實(shí)現(xiàn)高強(qiáng)度安全

但這也暴露了短板：ArrayPool 的歸還無法阻止二次訪問。

六、生態(tài)遷移：三張表

6.1 P/Invoke 遷移

動(dòng)作：IntPtr/nint → byte*/void* 重構(gòu)

6.2 數(shù)組/棧緩沖區(qū)

替代方案：優(yōu)先使用 Span<T> 或 C# 12 內(nèi)聯(lián)數(shù)組

6.3 顯式布局聯(lián)合體

七、架構(gòu)設(shè)計(jì)建議

三條落地準(zhǔn)則：

① 互操作隔離層

• 所有 P/Invoke、非托管封裝 → 獨(dú)立底層程序集
• 開啟 <MemorySafetyRules>1</MemorySafetyRules> 強(qiáng)制內(nèi)部升級(jí)

② 局部化 unsafe

• 丟棄「整方法 unsafe」的慣性
• 只在最關(guān)鍵的解引用那幾行套 unsafe { }

配合文檔標(biāo)簽：

/// <summary>
/// 調(diào)用前必須確保 ptr 指向有效且已初始化的內(nèi)存
/// </summary>
unsafe byte* ProcessBuffer(byte* ptr);

③ 優(yōu)先托管替代

能用 Span<T> 就別用裸指針。

JIT 編譯器對(duì) Span 的邊界檢查消除已足夠成熟，性能不輸裸指針。

結(jié)語

這場(chǎng)演進(jìn)的核心不是「讓 C# 變成 Rust」，而是讓內(nèi)存安全的邊界從「暴力圈地」變成「精準(zhǔn)灌溉」。

• 把真正的危險(xiǎn)留給開發(fā)者自己決定
• 把「無害聲明」從不必要的管控中解放出來
• 給足「逃生通道」，但要求你清醒

.NET 11 預(yù)覽在望，.NET 12 生產(chǎn)就緒。

你的 unsafe 代碼，準(zhǔn)備好迎接新十年了嗎？

到此這篇關(guān)于C# 內(nèi)存安全性的重大演進(jìn)：重新定義 unsafe 關(guān)鍵字的文章就介紹到這了,更多相關(guān)c#  unsafe 關(guān)鍵字內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論