stackalloc只能在unsafe上下文中使用，需方法加unsafe修饰符并启用不安全代码；分配内存生命周期绑定当前栈帧，仅限同步方法内短时使用，推荐配合span以保障安全与性能。
stackalloc 只能在 unsafe 上下文中使用
直接在方法体里写 stackalloc int[10] 会报错 CS0214：“指针和固定大小缓冲区只能在不安全上下文中使用”。必须给方法加 unsafe 修饰符，并确保项目启用不安全代码（<allowunsafeblocks>true</allowunsafeblocks>）。
常见错误是只在局部加 unsafe 块，但调用方没标记，或者忘了在 .csproj 里开开关——编译直接失败，不会等到运行时。
- 方法签名要显式声明：
unsafe static void ProcessData() - 不能在 async 方法里用
stackalloc（因为栈帧可能被挂起，生命周期无法保证） - 不能作为返回值直接返回（比如
return stackalloc byte[256]），会触发 CS8353：“stackalloc 表达式不能用于 ref 返回或 out 参数”
stackalloc 分配的内存不能跨作用域存活
stackalloc 分配的是当前栈帧的一部分，函数返回时自动释放。这意味着你不能把它存进类字段、传给异步回调、或试图在 finally 块外继续访问。
典型翻车场景：把 Span<byte></byte> 包装成字段，以为能复用；或者在 Task.Run(() => { ... }) 里访问之前 stackalloc 的内存——此时原栈帧早已销毁，读到的是随机垃圾或触发访问冲突。
- 安全做法：只在当前同步方法内使用，且生命周期明确短于方法执行时间
- 若需跨作用域，必须拷贝数据（如用
Span.CopyTo到堆上byte[]） - 可配合
Span<t></t>使用，但注意Span本身只是视图，不延长底层内存寿命
数组长度必须是编译期常量或 Span 构造时的已知值
stackalloc 不支持运行时变量长度（比如 int n = ReadSize(); int* p = stackalloc int[n];），除非用 C# 12+ 的“可变栈分配”语法（stackalloc int[length] 要求 length 是 const 或 constexpr 上下文中的确定值）。
旧版本（C# 7.2–11）只允许常量表达式；C# 12 允许非常量但需满足 constexpr 约束（例如参数带 [ConstantExpected] 属性、或来自 const 字段）。实际中多数情况仍得写死大小，或退回到 Marshal.AllocHGlobal + 手动释放。
- 安全上限建议控制在 1–4 KB 内，避免栈溢出（尤其递归深或线程栈小的环境）
- 调试时可用
RuntimeHelpers.IsStackSpaceAvailable(size)预检（.NET 6+），但它是提示性 API，不保证后续分配成功 - 别用
stackalloc替代合理设计的池化策略——它不是万能堆替代品
Span 和 ReadOnlySpan 是 stackalloc 最自然的搭档
直接操作 int* 指针容易出错，而 Span<t></t> 提供类型安全、边界检查（Debug 模式）、且能无缝接收 stackalloc 内存，是官方推荐组合。
例如：Span<byte> buffer = stackalloc byte[1024];</byte> 这行既不 unsafe，又自动管理生命周期——只要 buffer 在作用域内，底层内存就有效。
- 写入前务必检查长度：
if (buffer.Length - 避免隐式转换陷阱：不要把
Span<byte></byte>直接传给期望byte[]的 API，可能触发装箱或复制 - 对只读场景优先用
ReadOnlySpan<t></t>，编译器能做更多优化，也防止误写
栈上分配真正省掉的不是 GC 压力，而是对象头、同步块索引、以及跨代晋升带来的间接开销；但它换来了更严苛的生命周期约束和更隐蔽的崩溃方式——越快，越得盯紧作用域和长度。
