stackalloc 是在栈上分配内存，不是堆
stackalloc在 C# 中用于在当前线程的栈上直接分配一块连续内存，返回
Span<t></t>或
ReadOnlySpan<t></t>。它不经过 GC 管理，也不触发堆分配，所以速度快、无 GC 压力——但代价是：这块内存生命周期严格绑定于当前方法作用域，且必须在栈空间内完成分配。
常见误用是把它当成“轻量级堆替代品”，比如在循环里反复
stackalloc，或分配过大的块，结果不是性能提升，而是直接 栈溢出（StackOverflowException），且该异常无法被
try/catch捕获。
stackalloc 分配大小受栈剩余空间限制
默认线程栈大小在 Windows 上是 1MB（.NET 进程主线程），线程池线程通常也是 1MB；Linux/macOS 可能更小（如 512KB）。
stackalloc请求的字节数超过当前栈剩余空间时，运行时会立即抛出
StackOverflowException——注意，这不是“接近耗尽”的警告，而是硬性失败。
stackalloc int[1024 * 1024]≈ 4MB → 必然溢出
stackalloc byte[8192]（8KB）→ 一般安全，但若嵌套调用深（如递归 + 多层栈帧），仍可能踩线 结构体大小影响显著：
stackalloc MyStruct[100]要按
Unsafe.SizeOf<mystruct>()</mystruct>计算真实字节数
不能在 try/catch 中捕获 StackOverflowException
.NET 不允许托管代码捕获
StackOverflowException（从 .NET Framework 2.0 起强制限制）。即使你写：
try
{
Span<int> s = stackalloc int[1000000];
}
catch (StackOverflowException)
{
// 这段代码永远不会执行
}程序会直接崩溃（进程终止），不会进入 catch 块。这是设计使然：栈已损坏，运行时无法保证异常处理本身的栈帧还能安全压入。
因此，预防是唯一手段：
永远对stackalloc的元素数量做静态上限检查（例如用
#if DEBUG断言） 避免在 public API 或不确定输入规模的路径中使用
stackalloc优先考虑
ArrayPool<t>.Shared.Rent()</t>替代大块临时缓冲区
stackalloc 不能跨方法返回或存储到字段
stackalloc返回的是栈上地址，一旦方法返回，该地址就失效。编译器会阻止你把它赋给类字段、静态变量，或作为
ref/
out参数传出（除非用
ref struct且严格限定生命周期）。
以下写法会被 C# 编译器拒绝：
private Span<byte> _buffer; // ❌ 字段类型不能是 Span<T>（ref struct）
<p>Span<byte> GetBuffer()
{
return stackalloc byte[256]; // ❌ 编译错误：Cannot return a stackalloc expression
}真正安全的用法只有一种：在单个方法体内分配、使用、结束——中间不逃逸，不延长生命周期。哪怕只是传给一个接受
Span<t></t>的本地函数，也必须确保该函数不保存引用。
栈空间不是可伸缩资源，
stackalloc的“快”是以确定性为前提的。越想省事越容易崩，尤其在高并发或深度调用场景下，一个没算准的
stackalloc就可能让整个线程静默退出。
