当前位置：首页 > news >正文

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

news 2026/6/28 2:50:38

旧模型的「冤案」

在经典 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）