Span可消除堆分配，是.NET Core 2.1+/5+数据处理默认安全姿势；高频解析、切片、像素操作等场景必须用Span替代Substring/Array.Copy；其ref struct特性禁止逃逸出栈帧，跨异步或长期持有需改用Memory。
直接用 Span<t></t> 替代数组切片、字符串子串、字节拷贝等操作，能立刻消除堆分配——这是性能提升最确定、见效最快的路径。它不是“可选优化”，而是现代 .NET（.NET Core 2.1+ / .NET 5+）中处理数据的默认安全姿势。
什么时候必须用 Span 而不能用数组或字符串操作
当你在高频路径里做以下操作时，string.Substring()、Array.Copy()、new byte[n] 就是性能瓶颈源头：
- HTTP 请求头解析、CSV/JSON 行级拆分（每秒数千次调用）
- 网络包接收后按协议字段切片（如 TCP payload 中取 length + body）
- 图像像素缓冲区局部修改（不复制整帧）
- 循环内反复截取
ReadOnlySpan<char></char>做IndexOf或Trim
典型错误写法：var part = input.Substring(start, length); → 每次都 new string，触发 GC。
正确写法：var part = input.AsSpan().Slice(start, length); → 零分配，纯指针偏移。
Span 的生命周期限制和逃逸陷阱
Span<t></t> 是 ref struct，编译器强制它不能“逃逸出栈帧”。这意味着：
- ❌ 不能作为类的字段（
private Span<byte> _buffer;</byte>编译报错） - ❌ 不能存储在 async 方法的局部变量里并跨
await使用（await Task.Delay(1); span[0] = 1;不合法） - ❌ 不能装箱、不能泛型约束为
T where T : struct（因 ref struct 不是普通 struct）
常见误用：把 Span<byte></byte> 存进 Dictionary 或返回给上层调用方。结果不是运行时报错，而是编译失败，错误信息类似 CS8345: Field or auto-implemented property cannot be of type 'Span<byte>' unless it is declared as static or const</byte>。
从 Span 切换到 Memory 的实际决策点
当你要把内存视图传给异步方法、缓存复用、或跨方法边界长期持有时，Memory<t></t> 是唯一合规选择：
- ✅ 异步场景：
async Task ProcessAsync(Memory<byte> data)</byte>—— 然后内部用data.Span操作 - ✅ 缓冲池复用：
var rented = ArrayPool<byte>.Shared.Rent(8192); var mem = rented.AsMemory();</byte> - ✅ 字段存储：
private Memory<byte> _pendingBuffer;</byte>（Span在这里会直接编译不过）
注意：Memory<t></t> 本身不操作内存，它只是个“可逃逸容器”；真正干活的仍是 .Span 属性。所以不要在 hot path 里反复调用 mem.Span——提取一次复用即可。
stackalloc 和 Span 的组合使用风险
Span<int> span = stackalloc int[1024];</int> 看起来很美，但有硬性限制：
- 只能在
unsafe上下文中使用（需项目启用<allowunsafeblocks>true</allowunsafeblocks>） - 大小必须是编译期常量（
stackalloc int[size]中size不能是变量） - 栈空间有限，Windows 默认线程栈约 1MB；单次
stackalloc超过几 MB 容易栈溢出（StackOverflowException）
更稳妥的做法：小缓冲（≤ 1KB）用 stackalloc + Span，大缓冲走 ArrayPool<t>.Shared</t> + Memory<t></t>。两者不是替代关系，而是按规模分级使用的工具链。
最容易被忽略的点：Span 的安全性完全依赖编译器检查，不是运行时防护。一旦你绕过类型系统（比如用 Unsafe.AsPointer 手动构造 Span），越界读写不会抛异常，而是静默破坏内存——调试极其困难。所以优先用 .AsSpan()、.Slice() 这类安全工厂方法，别自己拼指针。
