C# 内存安全性的重大演进：重新定义 unsafe 关键字

导读：.NET 产品经理 Richard Lander 披露了 C# 16 与 .NET 11/12 的核心蓝图——在不丢失 GC 的前提下，让 C# 在底层内存控制上更接近 Rust 的安全保障。

TL;DR

一句话概括这场变革：把「指针」从洪水猛兽变成可控工具，把真正的危险精确到「解引用」这一刀。

核心数据：

• .NET 11 预览版 → .NET 12 生产就绪
• 新模型代号：MemorySafetyRules 1
• 目标：让 C# 获得「近似 Rust」的内存安全，而非引入完整的借用检查器

一、问题的根源：旧的 unsafe 太粗糙

1.1 旧模型的「冤案」

在经典 C# 里，只要用了 int* 这类指针，就得套一层 unsafe 大括号。

问题是：这太过度了。

• 声明一个指针 int* p = &value; —— 编译器直接红牌
• 但调个 Marshal.AllocHGlobal() —— 居然是「安全」的？

这种「内外不一致」让代码审计变成了真·扫雷游戏：

表面风平浪静，内部暗流涌动。

1.2 新模型的「翻案」

新规则把「非安全」的判定从「用指针」改成「解引用非托管内存」。

二、stackalloc 的三条件：真危险的精确定位

这是新模型最核心的技术突破。

只有同时满足以下三条，stackalloc 才被判为 unsafe：

1. 隐式转 Span：被转换成 Span<T> 或 ReadOnlySpan<T>
2. 无初始化列表：没用 stackalloc int buf[4] = {1,2,3,4}
3. 在 SkipLocalsInitAttribute 成员内：内存暴露未初始化垃圾数据

一句话：精准锁定物理危险区域，不伤及无辜。

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

语言设计组的最新拍板：

3.1 safe 关键字

不用 SafeRuntime 那种元数据属性，直接引入 safe 上下文关键字。

safe {
    // 这里面的代码经过编译器安全审计
}

3.2 类型声明上的 unsafe

直接标为编译期错误。

unsafe class MyClass { }  // ❌ 废弃！

正确姿势：在具体成员上标记。

3.3 字段的 unsafe

字段可以单独标记 unsafe。

unsafe struct Buffer {
    unsafe byte* Data;  // ✅ 读取时需要 unsafe 上下文
}

3.4 签名与实现的解耦

这是最重磅的设计变更：

// 新模型下：
unsafe void ProcessBuffer(byte* ptr) {
    // 签名不安全？但方法体内部可以是安全的！
    
    // 只有真的解引用时才需要 unsafe 块
    unsafe {
        *ptr = 42;
    }
}

3.5 过渡期诊断

为了避免「升级空窗期」，编译器很贴心：

• 没开启新模型的代码调用新版指针成员？
• 调用方不在 unsafe 上下文？

→ 编译警告/错误，给你慢慢迁移的时间。

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

ref 安全性分析很保守，经常误杀「实则安全」的代码。

新模型在 unsafe 上下文中做了降级处理：

1. 开启 /unsafe
2. 声明 unsafe 上下文
3. 显式压制警告

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

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

         .NET 垃圾回收器
    (自动且不确定性地管理内存)
              ↑
     [高性能路径]
              ↓
+------------------+    +------------------+
| 次级引用下行借用 |    | ArrayPool 复用  |
| (ref struct /   |    | (无仿射所有权，  |
|  生命周期单向栈传) |    | 面临二次释放隐患)|
+------------------+    +------------------+

Rust 靠的是所有权+生命周期+借用检查器 → 完全静态保障

C# 必须走另一条路：次级引用（Second-class References）

「只能往下传，不能存堆上」—— 低追踪成本实现高强度安全

但这也暴露了短板：ArrayPool 的归还无法阻止二次访问。

六、生态迁移：三张表

6.1 P/Invoke 迁移

动作：IntPtr/nint → byte*/void* 重构

6.2 数组/栈缓冲区

替代方案：优先使用 Span<T> 或 C# 12 内联数组

6.3 显式布局联合体

七、架构设计建议

三条落地准则：

① 互操作隔离层

• 所有 P/Invoke、非托管封装 → 独立底层程序集
• 开启 <MemorySafetyRules>1</MemorySafetyRules> 强制内部升级

② 局部化 unsafe

• 丢弃「整方法 unsafe」的惯性
• 只在最关键的解引用那几行套 unsafe { }

配合文档标签：

/// <summary>
/// 调用前必须确保 ptr 指向有效且已初始化的内存
/// </summary>
unsafe byte* ProcessBuffer(byte* ptr);

③ 优先托管替代

能用 Span<T> 就别用裸指针。

JIT 编译器对 Span 的边界检查消除已足够成熟，性能不输裸指针。

结语

这场演进的核心不是「让 C# 变成 Rust」，而是让内存安全的边界从「暴力圈地」变成「精准灌溉」。

• 把真正的危险留给开发者自己决定
• 把「无害声明」从不必要的管控中解放出来
• 给足「逃生通道」，但要求你清醒

.NET 11 预览在望，.NET 12 生产就绪。

你的 unsafe 代码，准备好迎接新十年了吗？

参考资料：C# Language Design Minutes - May 2026