Span在高并发下不触发GC压力，因其是栈上视图、不分配堆内存，仅持指针和长度；避免了byte[]频繁分配导致的Gen0对象洪流，且作用域结束即失效，无引用滞留，GC无需追踪。
Span 为什么在高并发下不触发 GC 压力
Span<t></t> 是栈上视图，本身不分配堆内存，只持有指向已有内存的指针 + 长度。高并发场景下大量短生命周期的字节处理（如 HTTP 请求头解析、序列化缓冲区切片），用 Span<byte></byte> 替代 byte[] 可避免每请求都 new 一个数组——后者直接变成 GC 第 0 代对象洪流。
关键点在于：Span<t></t> 不能跨 await 边界，也不能作为字段存储，一旦离开作用域就自动失效，这反而是优势：没有引用滞留，GC 完全不用追踪它。
stackalloc 在循环和高并发中必须配合 fixed 或 Span 使用
直接写 stackalloc byte[1024] 看似省事，但编译器要求它必须出现在 unsafe 上下文，且不能用于返回值或逃逸到方法外。高并发下常见错误是把它塞进 async 方法体里，结果编译不过：Cannot use stackalloc in async method。
正确做法是立即转成 Span<t></t>：
unsafe
{
byte* ptr = stackalloc byte[1024];
Span<byte> buffer = new Span<byte>(ptr, 1024);
// 后续所有操作基于 buffer，安全且零分配
}这样既利用了栈分配的低延迟，又通过 Span<t></t> 获得类型安全和边界检查（Debug 模式下）。
stackalloc 大小超过 1MB 会触发 StackOverflowException
默认线程栈大小在 Windows 是 1MB（.NET Core / 6+ 默认也是约 1MB）。如果并发线程数多，每个都 stackalloc byte[2048] 看似安全，但叠加局部变量、调用栈深度后极易溢出——尤其在 IIS 或 Kestrel 的长连接场景中，栈空间比想象中紧张。
建议遵循以下原则：
- 单次
stackalloc不超过 8KB，更稳妥是 ≤ 4KB - 对不确定长度的数据（如用户上传的 JSON body），绝不用
stackalloc，改用ArrayPool<byte>.Shared.Rent()</byte> - 用
Span<t>.TryCopyTo()</t>做安全回退，避免因容量不足导致逻辑分支爆炸
Span + stackalloc 组合在 Socket 读写中的典型误用
高频网络服务（如自定义协议网关）常试图用 stackalloc 配合 Socket.ReceiveAsync()，但这是错的：Socket.ReceiveAsync() 要求传入 Memory<byte></byte>，而 stackalloc 产生的 Span<byte></byte> 无法直接升格为 Memory<byte></byte>（因为后者可能被异步回调持有，栈内存已销毁）。
正确路径只有两条：
- 同步收发：用
Socket.Receive(Span<byte>)</byte>，配合stackalloc+Span完全可行 - 异步收发：必须用
ArrayPool<byte>.Shared.Rent()</byte>，收到后再用Span切片解析，最后Return()
混淆这两者会导致偶发崩溃或数据错乱，而且问题在线上高并发时才暴露，复现困难。
