Span是C# 7.2引入的栈分配、零分配、类型安全的内存切片类型，本质是“指向连续内存块的轻量视图”，适用于短期、局部、高性能场景如字符串解析和二进制协议解包。

Span 是什么，什么时候该用它

Span 是 C# 7.2 引入的栈分配、零分配、类型安全的内存切片类型，本质是“指向连续内存块的轻量视图”。它不拥有内存，只引用——所以不能跨 await 边界、不能作为类字段、不能装箱。适合短期、局部、高性能场景：比如字符串解析、二进制协议解包、数组/堆栈缓冲区的分段处理。

常见误用：拿 Span<t></t> 替代 List<t></t> 或长期缓存数据——这会编译失败或运行时报 System.ArgumentException: Span must be stack-only。

如何从常见数据源创建 Span

创建方式直接决定性能和安全性，关键看底层是否支持栈视图：

• Span<byte></byte> 可安全来自：栈数组（stackalloc byte[256]）、堆数组（new byte[1024].AsSpan()）、Memory<t></t>（调用 .Span）
• string → Span<char></char>：用 "hello".AsSpan()，零拷贝；但注意 Span<char></char> 是只读视图，不能修改字符串内容
• ReadOnlySpan<char></char> 更常用：避免意外写入，且兼容更多 API（如 int.TryParse(ReadOnlySpan<char>, out int)</char>）
• 禁止：从 StringBuilder.ToString() 直接 .AsSpan()——返回的是新字符串，生命周期短，且可能触发 GC；应改用 StringBuilder 的 Span 接口（如 builder.AsSpan()，需 .NET 6+）

Span 常见性能陷阱与规避方式

看似高效，但一不留神就掉回堆分配或引发异常：

C#

"避开 C# 常见错误——空陷阱、异步陷阱、LINQ 陷阱及资源泄漏。"

下载

• 隐式装箱：把 Span<t></t> 传给接受 object 或泛型约束为 class 的方法 → 编译失败（error CS8345: Field or property cannot be of type 'Span<t>' unless it is declared as 'ref readonly'</t>）
• 跨异步边界：在 async 方法里捕获 Span<t></t> 并 await 后使用 → 运行时报 System.InvalidOperationException: Cannot use a Span<t> across await</t>
• 过度切片：频繁调用 span.Slice(i, len) 不产生新内存，但每次生成新结构体（值类型），若在 tight loop 中大量创建，可能增加栈压力（尤其嵌套深时）
• 误用 ToArray()：span.ToArray() 触发堆分配 → 应优先用 Memory<t></t> + MemoryPool<byte>.Shared.Rent()</byte> 配合 Span 操作，最后再拷贝

实际提速案例：UTF-8 字符串解析中的 Span 应用

比如解析形如 "key=value&flag=true" 的 query string，不用 string.Split('&') 和 Substring（每步都分配新字符串）：

static void ParseQuery(ReadOnlySpan<char> input)
{
    int start = 0;
    while (input.Slice(start).IndexOf('&') is int ampIdx && ampIdx >= 0)
    {
        var pair = input.Slice(start, ampIdx);
        int eqIdx = pair.IndexOf('=');
        if (eqIdx > 0)
        {
            ReadOnlySpan<char> key = pair.Slice(0, eqIdx).Trim();
            ReadOnlySpan<char> value = pair.Slice(eqIdx + 1).Trim();
            // 直接用 ReadOnlySpan<char> 调用 int.TryParse / bool.TryParse 等
        }
        start += ampIdx + 1;
    }
}

这个版本全程无字符串分配，GC 压力趋近于零。但要注意：所有参与解析的 API 必须原生支持 ReadOnlySpan<char></char>（如 .NET Core 2.1+ 的 int.TryParse）；旧版框架需升级或手动实现字符遍历逻辑。

真正难的不是写对 Span<t></t>，而是判断哪一段逻辑值得重构——往往要先用 dotTrace 或 dotMemory 抓到热点分配点，再针对性替换。盲目全量改成 Span 可能让代码更难懂，却换不来实际收益。