<p>stackalloc 是 C# 中用于在栈上分配内存的底层机制，仅限不安全上下文中使用，必须初始化局部变量，分配内存生命周期绑定方法作用域，推荐配合 Span<T> 使用以保障安全与性能。</p>
stackalloc 不是“教程级工具”，它是 C# 中极少数能直接控制内存布局的底层机制，用错会崩溃，用对能省掉 GC 压力、避免数组分配、提升热点路径 3–5 倍吞吐。它只在明确需要零分配、短生命周期、固定大小的连续内存时才值得动用。
stackalloc 必须配合 Span 使用，否则 unsafe 风险太高
直接用 int* + stackalloc 虽然合法，但极易越界、悬空、误传指针。现代 C#（7.2+）已支持将 stackalloc 结果直接赋给 Span<t></t> 或 ReadOnlySpan<t></t>，这是唯一推荐的用法。
-
Span<int></int>自动绑定栈帧生命周期，编译器静态检查不会逃逸到堆或跨方法返回 - 所有索引访问带内联边界检查，比手写指针更安全，且 JIT 会优化掉冗余校验
- 不能赋值给
var（类型推导失败），必须显式声明Span<T> - 错误示例：
var s = stackalloc byte[256];→ 编译失败；正确写法：Span<byte> s = stackalloc byte[256];</byte>
stackalloc 分配大小受线程栈限制，别硬扛大数组
默认 Windows 线程栈是 1MB，.NET 默认栈上限约 800KB 可用。分配超限会直接抛 StackOverflowException，且无法 catch —— 进程直接终止。
- 安全阈值建议：单次
stackalloc不超过 64KB（保守起见）；常见场景如解析 HTTP 头、小缓冲区、临时计算数组，用 1KB–8KB 最稳妥 - 不要用
stackalloc替代ArrayPool<T>.Shared.Rent()处理 64KB+ 场景，后者可复用、可控、无栈溢出风险 - 调试时注意：Visual Studio 的“仅我的代码”可能掩盖栈溢出源头，建议关闭该选项并启用本机调试
stackalloc + Span 不能跨 async/await 边界，也不能存入类字段
Span<T> 是 ref struct，天生禁止逃逸。这意味着你无法把它塞进 List<Span<byte>>、不能作为 async 方法的局部变量保留到 await 之后、也不能赋给 class 的字段。
- 典型错误：
async Task Process() { Span<byte> buf = stackalloc byte[1024]; await Task.Delay(1); /* buf 已失效 */ }</byte>→ 编译报错 CS8346 - 若需异步中持有缓冲区，改用
Memory<byte>+ArrayPool<byte>.Shared，这是设计契约，不是限制 - 结构体里不能含
Span<T>字段（违反 ref struct 规则），但可以含ReadOnlySpan<char>参数用于构造函数临时传入
真正难的不是语法，而是判断“这个数据是否真的适合栈上分配”：它是否生命周期严格限定在当前同步方法内？大小是否确定且足够小？有没有被意外捕获或跨上下文传递的风险？这些问题比写一行 stackalloc 关键字重要得多。
