C#怎么使用stackalloc分配_C#栈上内存分配优化方法教程【高级】

stackalloc 是 C# 里少数能让你直接操纵内存布局的底层机制，它不是在“教程级”的玩具，而是实打实的性能利器。用对了，热点路径的吞吐能提升 3 到 5 倍，GC 压力也降下来了；用错了，程序直接崩溃给你看。所以，它只适合那些明确需要零分配、短生命周期、固定大小连续内存的场景。那么，这个工具到底该怎么用？我们从头捋一遍。

先说一个核心判断：stackalloc 必须配合 Span 使用，否则 unsafe 的风险太高。

直接用 int* 加 stackalloc 虽然语法上合法，但很容易越界、悬空、误传指针，这种写法在现代 C# 里已经不推荐了。从 C# 7.2 开始，stackalloc 的结果可以直接赋给 Span 或 ReadOnlySpan，这才是官方推荐的、也是唯一靠谱的用法。

• Span 会自动绑定栈帧的生命周期，编译器会静态检查，确保它不会逃逸到堆上或者跨方法返回。
• 所有索引访问都带有内联的边界检查，比手写指针安全得多，而且 JIT 会优化掉冗余的校验。
• 这里有个坑：不能直接用 var 来声明，类型推导会失败。必须显式写出 Span。比如 var s = stackalloc byte[256]; 编译会报错，正确的写法是 Span s = stackalloc byte[256];。

接下来要注意的是，stackalloc 分配的大小受线程栈限制，别硬扛大数组。

默认情况下，Windows 的线程栈是 1MB，而 .NET 的默认栈上限大概在 800KB 左右可用。一旦分配超限，就会直接抛出 StackOverflowException，而且这个异常是无法 catch 的——进程会直接终止。所以，安全阈值很重要：建议单次 stackalloc 不要超过 64KB，保守一点更好。常见的场景，比如解析 HTTP 头、小缓冲区、临时计算数组，用 1KB 到 8KB 是最稳妥的。另外，如果处理的是 64KB 以上的场景，就别用 stackalloc 了，改用 ArrayPool.Shared.Rent() 更合适，它既可复用又可控制，还没有栈溢出的风险。调试时也要留意：Visual Studio 的“仅我的代码”功能可能会掩盖栈溢出的源头，建议关掉这个选项，并启用本机调试。

还有一个关键点：stackalloc + Span 不能跨 async/await 边界，也不能存入类字段。

因为 Span 是 ref struct，天生就禁止逃逸。这意味着你不能把它塞进 List>，不能作为 async 方法的局部变量保留到 await 之后，也不能赋给 class 的字段。一个典型的错误写法是 async Task Process() { Span buf = stackalloc byte[1024]; await Task.Delay(1); /* buf 已失效 */ }，这会导致编译报错 CS8346。如果需要在异步中持有缓冲区，正确的做法是改用 Memory 配合 ArrayPool.Shared。这不是限制，而是设计契约。另外，结构体里不能包含 Span 字段，这违反了 ref struct 的规则，但可以包含 ReadOnlySpan 参数，用于构造函数临时传入。

说到底，真正考验人的不是语法本身，而是判断“这个数据是否真的适合栈上分配”。它的生命周期是否严格限定在当前同步方法内？大小是否确定且足够小？有没有被意外捕获或跨上下文传递的风险？这些问题，远比写一行 stackalloc 关键字重要得多。