C#中的unsafe关键字用于声明一段包含指针操作的不安全上下文。默认情况下，C#编译器禁止直接使用指针，因为托管代码依赖CLR进行内存管理，对象的地址可能在垃圾回收过程中发生变化。unsafe允许开发者在明确标记的范围内绕过这些限制，直接使用指针、执行地址运算和手动内存分配。虽然名字叫不安全，但并非代码本身危险，而是意味着编译器不再提供完整的类型安全和内存安全检查，责任转移到了开发者身上。
不安全代码仍然运行在CLR之上，并不是完全脱离托管环境。它只是打开了一扇可以触碰底层内存的窗口，例如通过指针访问数组元素、与非托管动态库交换数据，或者在栈上分配连续内存。要使用这一特性，除了在代码中加入unsafe关键字，还必须先让编译器和项目允许不安全代码，否则即使代码写对了也无法通过编译。
unsafe关键字的含义与托管类型安全
在托管环境中，CLR会跟踪所有引用类型对象的元数据，执行边界检查、类型转换检查，并由垃圾回收器统一回收不再使用的内存。这个过程让C#在大多数情况下避免了C/C++中常见的内存泄漏、野指针和缓冲区溢出问题。一旦代码被标记为unsafe，编译器就不再保证这些约束。例如，一个int类型的指针可以指向任意内存地址，如果越界读写，程序可能崩溃，甚至破坏其他对象的数据。
unsafe上下文可以作用于方法、类、结构体或者单独的代码块。常见的写法是在方法前加上unsafe修饰符，例如unsafe void CopyData()。也可以在普通方法内部使用unsafe { }创建局部不安全块。这种局部写法更推荐，因为它把风险限制在最小范围内，让代码审查时更容易定位需要重点检查的部分。指针类型在unsafe上下文中声明，如int* p表示指向32位整数的指针，void*表示未知类型的指针。
需要明确的是，unsafe并不等同于非托管。unmanaged通常指完全不受CLR控制的内存或资源，例如通过Marshal类手动申请的堆内存；而unsafe代码仍然可以访问托管对象，只是需要通过fixed锁定对象地址。两者经常一起出现，但概念并不完全相同。理解这一点有助于判断何时真正需要unsafe，而不是把所有底层操作都塞进不安全代码块。
启用不安全代码的几种方式
要在项目中启用不安全代码，最直接的方法是修改项目文件。对于使用SDK风格的项目，可以在.csproj文件中加入配置项。需要把<AllowUnsafeBlocks>true</AllowUnsafeBlocks>放在<PropertyGroup>节点中。这样编译器在构建整个项目时就会开放unsafe支持，所有文件中的unsafe代码都会被接受。对于旧式项目，Visual Studio的界面路径是项目属性中的生成选项卡，勾选允许不安全代码即可，本质上也是在项目文件中写入相同的配置。
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net8.0</TargetFramework>
<AllowUnsafeBlocks>true</AllowUnsafeBlocks>
</PropertyGroup>
</Project>
如果不想修改项目文件，也可以在使用命令行编译时追加unsafe参数。使用csc编译代码时，命令大致为csc -unsafe Program.cs。如果使用dotnet CLI，则仍建议通过项目文件配置，因为直接调用csc的场景较少。对于只有一个文件需要unsafe而其他文件不需要的情况，项目文件设置会整体放开，无法按文件单独控制。此时可以考虑把不安全代码集中到单独的程序集或类中，减少影响范围。
部分开发者会尝试在代码里只写unsafe而不修改项目配置，结果会遇到编译错误CS0227：不安全代码只会在使用unsafe编译时出现。这个错误提示很明确，说明编译器已经识别出unsafe修饰符，但构建参数没有允许它。解决思路就是回到项目文件或项目属性中增加AllowUnsafeBlocks设置。配置完成后，重新生成项目，编译器才会继续处理指针相关语法。
fixed语句、指针遍历与栈上分配
在unsafe上下文中操作托管数组或其他引用类型时，最大的问题是垃圾回收器可能移动对象。GC在回收内存时会压缩堆，存活对象会被移动到连续区域，之前保存的对象地址随即失效。如果持有一个指向对象内部字段的指针，GC移动对象后这个指针就会变成悬空指针。fixed语句可以暂时固定对象的地址，确保在语句块内对象不会被移动，从而安全地使用指针访问其内存。
int[] numbers = { 10, 20, 30, 40, 50 };
unsafe
{
fixed (int* p = numbers)
{
int sum = 0;
for (int i = 0; i < numbers.Length; i++)
{
sum += *(p + i);
}
Console.WriteLine(sum);
}
}
上面的代码用fixed固定数组numbers，然后通过指针p逐个访问元素。p + i表示从数组起始地址向后偏移i个int大小，再通过解引用操作符读取值。这种方式绕过了数组索引的边界检查，在处理大量连续数据时可以获得更紧凑的机器指令。不过指针运算不会自动检查越界，一旦i超出数组长度，读取或写入就会访问到未知内存。
stackalloc是另一个与unsafe紧密相关的功能，它允许在栈上分配一块连续内存，而不经过托管堆。栈内存的生命周期与当前方法绑定，方法返回后自动释放，因此不存在GC回收问题。栈空间通常比较小，适合分配几十KB以内的临时缓冲区。如果试图分配过大的空间，会触发StackOverflowException。使用stackalloc时可以直接用指针访问内存，也可以通过Span<T>来安全地包裹这块内存。
unsafe
{
int* buffer = stackalloc int[64];
for (int i = 0; i < 64; i++)
{
buffer[i] = i * i;
}
for (int i = 0; i < 8; i++)
{
Console.WriteLine(buffer[i]);
}
}
在实际项目中，fixed更多用于与非托管API交互、锁定对象进行原地序列化，或者临时提高数组访问性能。指针遍历数组的收益并不是每次都明显，因为现代JIT对普通数组遍历已经做了大量优化，甚至能自动消除边界检查。因此除非经过性能剖析确认热点，否则不必为了微小的性能提升而引入指针运算。
unsafe在非托管互操作与性能敏感场景中的价值
与非托管代码交互是unsafe最常见的用途之一。很多系统级API、C/C++动态库或硬件驱动接口要求调用方传入原始指针或指向缓冲区的地址。例如图像处理中，需要把像素数据传给底层编码器，或者从采集设备读取帧数据。C#中可以通过IntPtr传递地址，但要在托管对象和原始指针之间转换，还是需要unsafe和fixed配合。这样可以在不复制数据的情况下直接把托管数组的内容暴露给外部代码。
序列化也是指针发挥作用的场景。对于结构体连续存储的数组，直接通过指针获取结构体字节视图，再写入流或网络缓冲区，可以减少中间对象分配。很多高性能网络库在内部会使用unsafe来处理数据包头部，因为它需要根据协议偏移量读取整型、浮点数和字节序列。手动解析时使用指针访问比反复调用BitConverter或BinaryReader更快，不过也会让代码更难读、更难维护。
另一个应用是对大型数组进行原地变换。比如对图像做灰度处理时，可以用fixed固定像素数组，然后通过指针遍历每个像素的RGB通道。这种写法省去了数组索引器带来的额外指令，在百万像素级别循环中能体现出一定优势。但JIT优化后的普通for循环同样可能达到接近性能，因此在决定使用unsafe之前，最好用BenchmarkDotNet做对比测试，而不是凭感觉猜测性能差距。
常见风险与更安全的替代方案
unsafe带来的风险主要集中在内存安全和类型安全两个方面。指针可以随意修改内存，如果计算偏移时出错，可能覆盖其他对象的数据，导致程序状态异常但不会立刻崩溃。这类问题排查起来非常困难，因为它可能表现为遥远位置的一个随机错误。类型安全方面，指针可以在一定程度上把一种类型的内存重新解释为另一种类型，这在规避编译器类型检查的同时，也破坏了类型系统的保护作用。
平台兼容性同样值得注意。unsafe代码依赖底层内存布局和指针大小，不同架构、不同运行时的行为可能不同。例如32位和64位平台上指针长度不同，结构体对齐规则也可能变化。如果安全代码可以通过调整算法实现相同目标，或者可以使用Span<T>、Memory<T>这类现代内存抽象来避免指针，就应优先选择安全方案。Span能够提供高效的切片和遍历，同时保留数组边界检查，性能接近指针但安全性高很多。
对于必须与非托管库交互的情况，可以先考虑使用Marshal.AllocHGlobal分配非托管内存，再通过Marshal.Copy在托管数组和非托管内存之间复制数据。虽然复制会带来一些开销，但这种方式完全不需要unsafe代码，安全性更高，也更容易调试。只有当复制成为性能瓶颈，或者外部API要求直接使用指针时，才引入unsafe。即使使用unsafe，也应当把不安全代码隔离在专门的类中，并为核心算法编写单元测试，重点验证边界条件和空指针情况。
unsafe不是一个应该被完全避免的特性，它提供了一条在必要时接触底层内存的通道。理解它的含义、启用方式以及潜在风险，能帮助开发者在性能、互操作和安全性之间做出更合理的取舍。对于大多数业务应用，安全代码已经足够；对于需要榨取最后一点性能或与原生世界紧密交互的场景，unsafe仍然是一个不可替代的工具。