stackalloc配合Span是处理临时小数组最高效方案；它在栈分配、免GC、缓存友好，适合≤128字节且生命周期短的场景，但需unsafe上下文且不可逃逸。
在C#中处理临时小数组时，stackalloc 和常规堆数组（如 new int[10]）各有优劣。选择哪个更高效，取决于使用场景、数组大小和生命周期。下面我们从性能角度分析两者的差异，并给出实际建议。
内存分配位置与GC影响
stackalloc 在栈上分配内存，不经过垃圾回收器（GC），释放由方法调用结束自动完成，几乎没有额外开销。
- 堆数组通过
new[]分配，内存位于托管堆，会增加GC压力，尤其是频繁创建的小数组。 - 栈分配适合生命周期短、作用域明确的场景，避免不必要的GC暂停。
性能实测对比（小数组）
以创建长度为8~32的整型数组为例：
- stackalloc：分配时间几乎为零，访问速度更快（局部性好，缓存友好）。
- 堆数组：即使很小，也会触发堆分配，CLR需记录对象头、同步块等元数据，带来固定开销。
在高频率循环中使用临时数组时，stackalloc 可显著减少分配次数，提升吞吐量。
使用限制与安全考虑
stackalloc 并非万能，有几点需要注意：
- 只能用于 unsafe 上下文或允许栈分配的表达式（C# 7.3+ 放宽了部分限制）。
- 分配大小必须是编译时常量或受控表达式，避免栈溢出（例如不能分配几KB以上）。
- 返回或逃逸栈指针是危险操作，需配合 red">Span
安全封装使用。
推荐写法：
Spanbuffer = stackalloc int[16];
这样既安全又能享受栈分配优势。
实际建议：何时用哪个？
- 临时缓冲区（如格式化字符串、简单计算），长度小于 128 字节 → 优先 stackalloc + Span。
- 数组需跨方法传递、生命周期较长 → 使用堆数组或 ArrayPool 共享池。
- 不确定大小或可能较大（> 1KB）→ 避免 stackalloc，改用 ArrayPool
.Shared 。
基本上就这些。对于临时小数组，stackalloc 配合 Span 是目前最轻量、高效的方案，合理使用可明显降低内存负载，提升性能。
