C# 内存安全性的重大演进：重新定义 unsafe 关键字
TL;DR
一句话概括这场变革：把「指针」从洪水猛兽变成可控工具，把真正的危险精确到「解引用」这一刀。
核心数据：
- .NET 11 预览版 → .NET 12 生产就绪
- 新模型代号：MemorySafetyRules 1
- 目标：让 C# 获得「近似 Rust」的内存安全，而非引入完整的借用检查器
一、问题的根源：旧的 unsafe 太粗糙
1.1 旧模型的「冤案」
在经典 C# 里，只要用了int*这类指针，就得套一层unsafe大括号。
问题是：这太过度了。
- 声明一个指针
int* p = &value;—— 编译器直接红牌 - 但调个
Marshal.AllocHGlobal()—— 居然是「安全」的？
这种「内外不一致」让代码审计变成了真·扫雷游戏：
表面风平浪静，内部暗流涌动。
1.2 新模型的「翻案」
新规则把「非安全」的判定从「用指针」改成「解引用非托管内存」。
| 操作 | 旧模型 | 新模型 |
|---|---|---|
int* p = &value; | ❌ 必须 unsafe | ✅ 安全 |
fixed (buf)获取栈数组 | ❌ 必须 unsafe | ✅ 安全 |
*p = 42;解引用 | ✅ 可以安全 | ❌ 必须 unsafe |
stackalloc Span<T>未初始化 | ❌ 被「误杀」 | ✅ 精准识别 |
二、stackalloc 的三条件：真危险的精确定位
这是新模型最核心的技术突破。
只有同时满足以下三条，stackalloc 才被判为 unsafe：
- 隐式转 Span：被转换成
Span<T>或ReadOnlySpan<T> - 无初始化列表：没用
stackalloc int buf[4] = {1,2,3,4} - 在 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 → 方法体全程 unsafe | 签名 unsafe = 仅外部契约 ✓ |
| 无法区分「对外承诺」vs「内部实现」 | 内部仍受编译器安全保护 ✅ |
// 新模型下： unsafe void ProcessBuffer(byte* ptr) { // 签名不安全？但方法体内部可以是安全的！ // 只有真的解引用时才需要 unsafe 块 unsafe { *ptr = 42; } }3.5 过渡期诊断
为了避免「升级空窗期」，编译器很贴心：
- 没开启新模型的代码调用新版指针成员？
- 调用方不在 unsafe 上下文？
→编译警告/错误，给你慢慢迁移的时间。
四、ref 安全性的「逃生通道」
ref 安全性分析很保守，经常误杀「实则安全」的代码。
新模型在 unsafe 上下文中做了降级处理：
| 原先 | 新模型 |
|---|---|
| 硬性编译错误 | ⚠️ 警告 |
| 无法绕过 | 需要三层确认： |
- 开启
/unsafe - 声明
unsafe上下文 - 显式压制警告
这就是「打破玻璃」的合法通道。
五、C# vs Rust：Runtime 的根本分歧
.NET 垃圾回收器 (自动且不确定性地管理内存) ↑ [高性能路径] ↓ +------------------+ +------------------+ | 次级引用下行借用 | | ArrayPool 复用 | | (ref struct / | | (无仿射所有权， | | 生命周期单向栈传) | | 面临二次释放隐患)| +------------------+ +------------------+Rust靠的是所有权+生命周期+借用检查器 → 完全静态保障
C#必须走另一条路：次级引用（Second-class References）
「只能往下传，不能存堆上」—— 低追踪成本实现高强度安全
但这也暴露了短板：ArrayPool 的归还无法阻止二次访问。
六、生态迁移：三张表
6.1 P/Invoke 迁移
| 旧模式 | 新模式 |
|---|---|
| IntPtr 伪装指针，无 unsafe | 原生方法导入标记 unsafe 契约 ✅ |
动作：IntPtr/nint→byte*/void*重构
6.2 数组/栈缓冲区
| 旧模式 | 新模式 |
|---|---|
| 全局 unsafe 方法体 | 局部 unsafe { } 块隔离 ✅ |
替代方案：优先使用Span<T>或 C# 12 内联数组
6.3 显式布局联合体
| 旧模式 | 新模式 |
|---|---|
| 隐式重叠，缺乏审计 | 必须显式标注 safe/unsafe ✅ |
七、架构设计建议
三条落地准则：
① 互操作隔离层
- 所有 P/Invoke、非托管封装 → 独立底层程序集
- 开启
<MemorySafetyRules>1</MemorySafetyRules>强制内部升级
② 局部化 unsafe
- 丢弃「整方法 unsafe」的惯性
- 只在最关键的解引用那几行套
unsafe { }
配合文档标签：
/// <summary> /// 调用前必须确保 ptr 指向有效且已初始化的内存 /// </summary> unsafe byte* ProcessBuffer(byte* ptr);③ 优先托管替代
能用Span<T>就别用裸指针。
JIT 编译器对 Span 的边界检查消除已足够成熟，性能不输裸指针。
结语
这场演进的核心不是「让 C# 变成 Rust」，而是让内存安全的边界从「暴力圈地」变成「精准灌溉」。