.NET性能调优：用Span＜T＞实现零拷贝，化解字符串分配与GC压力

服务端开发做久了，总会碰到一类非常典型的问题：解析一段请求头、拆一帧网络封包、或者从日志行里截取某个字段。代码写出来很直白，可一旦上了压测，吞吐量就是上不去。用 perf 一看，大头往往不是算法，而是那些不起眼的字符串复制、字节数组重新分配。GC 的 Gen0 一直在疯涨，线程被垃圾回收卡得死死的。

Span 这名字，在做 .NET 性能调优的人耳朵里已经是老朋友了。它最核心的价值，就是给“零拷贝”提供一个类型安全、零分配的方案：不需要再去手写 unsafe 指针，也不需要为了截取一小段数据而复制一整个对象。每次用 Substring，等于把文档重新打印一遍再裁下来给你；而用 Span 切片，是直接给你一张透明卡片，告诉你去看原件的哪一块。本文会从原理、实战、避坑到量化验证，把我这几年在服务端、中间件里用 Span 的经验完整拆开讲，适合那些已经在用 .NET 写接口、写批处理、写协议解析的开发者。

1. 先理解“零拷贝”：我们到底在优化什么

1.1 最常见的性能浪费：字符串分配与 GC 压力

很多代码写成这样：

string url = request.Path; string apiName = url.Substring(0, url.IndexOf('/'));

从功能上没错，但从内存角度，每一行都在给 GC 加负担。Substring 会立刻在托管堆上生成一个新的 string 对象，内部再携带一份字符数组拷贝。假如这份 URL 是从一个很大的请求体里截出来的，你实际上干了这么几件事：

1. 原请求字符串占据一块大内存。
2. Substring 又分配了一块新的字符串内存。
3. 原本的字符串没有及时销毁，Gen0 里堆了一堆待回收对象。

在低频调用里这都不是事。但在网关、网关里的鉴权模块、API 路由分发、日志切分这些高频路径上，每秒钟几千上万次 Substring，结果就是 GC 线程反复启动，CPU 有 15% 到 20% 都耗在对象分配和回收上。更麻烦的是，分配导致内存碎片和缓存命中率下降。你的代码根本没有计算结果，反而一直在“复制和丢垃圾”。

1.2 零拷贝的三种层次

我在项目里会把零拷贝拆成三个层面来理解，避免一提“零拷贝”就想到操作系统的 sendfile。

• 内存级零拷贝：不分配新内存，直接复用已有的缓冲区域。Span 就是干这个的。
• API 级零拷贝：不需要把内存包装成 string / byte[] 这类更高层的对象，直接对原始区域进行操作。例如直接在 byte[] 切片上做编码判断、数值解析。
• 系统级零拷贝：涉及内核缓冲区直接发送、磁盘拷贝。这是 OS 层的事，.NET 里主要对应 SendFile 这类 API。

本文聚焦前两个层面。特别是第二层，很多人容易忽略：你对一个字节切片做解析时，如果每一步都必须先“转成 string”再处理，就不是真正的零拷贝。

1.3 Span 到底是干嘛的

Span 是一种 ref struct，可以被看作“指针 + 长度”的安全封装。它提供一个连续内存块的读写视图，你通过它去访问底层数组、字符串或者原生内存。它的厉害之处在于：给一个已有的 T[] 或 string 切出一段作为新视图，只需要在栈上创建一个小的结构体，不会在堆上产生新对象。

对于字符串来说，ReadOnlySpan 切片一个 string 内部区域，不需要创建新 string。对于字节来说，ReadOnlySpan 切片一个 byte[]，不需要复制 byte[]。在整个操作过程中，没有多余的堆分配，这就是零拷贝的本质：用视图取代副本。

2. Span 的核心机制：为什么它敢保证零拷贝

2.1 ref struct 与栈上存储

Span 之所以是 ref struct，是因为它的内部持有一个类似 ref 字段的引用，还可能持有引用指向的数据来源。CLR 不允许这样的结构体被装箱，也不允许它跑到托管堆上成为某个类的字段。编译器强制把它限制在栈上，这样它的生命周期可以被静态分析，天然规避了“引用悬空”的风险。

好处是，创建和销毁 Span 的代价极低。它就是一个栈上的小结构体，几个字节而已，不触发 GC，不导致内存分配。而普通 string 变量也好，byte[] 变量也好，它们本身是引用，指向堆对象；但 Span 本身不是引用，它是一个载体，携带“指向某个区域的指针 + 长度”。

这个设计非常聪明。它让你能用“值类型”的方式去操作潜在的堆内存、栈内存，但不用承担手工指针管理的风险。

2.2 切片的本质：偏移引用和长度

理解 Span 的切片操作，只要记住一个公式：切片不是复制，是改变视图。

ReadOnlySpan<char> line = "GET /api/users HTTP/1.1"; ReadOnlySpan<char> method = line.Slice(0, 3); // GET ReadOnlySpan<char> path = line.Slice(4, 10); // /api/users

Slice 内部做的事情：创建一个新的 Span，其引用指向原 Span 的引用 + 偏移量，长度设置为切片后的长度。因为 Span 自身只是一个栈上的视图对象，不去拷贝原数据，所以这个操作分摊到每次调用上几乎是零成本。底层也可能是从一个数组的引用开始，但代码层面对你透明。

同样道理适用于 ReadOnlyMemory ，Memory 是堆上容器。区别在于 Memory 可以存为字段、跨越 async 状态机，而 Span 不行。日常处理同步方法内的短生命周期操作时，Span 是首选。

2.3 三种底层内存来源

Span 可以指向三类存储，这是它通用性更强的关键：

1. 托管数组：T[]，最常见。
2. 字符串内部存储：ReadOnlySpan 可以指向 string 的字符区域。
3. 原生内存或栈内存：通过 stackalloc 创建，或通过 MemoryMarshal.CreateSpan 从非托管指针包装。

这三种来源看似不同，但使用 Span 的操作逻辑完全一致。这让你的业务解析函数可以同时处理 byte[]、字符串片段、栈上缓冲区，而不需要写多套重载。

2.4 Span vs Memory：定位必须分清

很多人问为什么有了 Span，还要有 Memory 。核心原因是 ref struct 无法进入托管堆。异步方法的“状态机”是在堆上分配的，跨 await 保存的局部变量必须支持字段存储，而 Span 做不到。所以 .NET 引入了 Memory ，它把“引用连续区域”的抽象改成可存储的包装器。

打个比方，Span 是你在厨房里拿着的菜刀，方便、轻巧，但是不能放回抽屉里沉淀；Memory 是把菜刀做成了带锁的柜子，可以放到任何地方，用的时候再打开。实际开发里，如果某个库函数只同步处理一块 buffer，参数类型用 ReadOnlySpan 最优雅；如果这个缓冲区有可能被异步任务继续持有，就必须用 ReadOnlyMemory 。

2.5 stackalloc 与 ArrayPool 联动

另一个零拷贝途径是使用栈上内存：

Span<byte> buffer = stackalloc byte[256];

这种情况完全不在托管堆分配内存，而是在当前线程栈中划出一块区域。对于临时处理一块小数据，比 new byte[] 再归还给 ArrayPool 更直接。但要注意，栈空间是有限的（不同平台默认 1MB 左右），大区块不能 stackalloc。通常我会控制在 1KB 以内，超过之后果断使用 ArrayPool .Shared 租借数组。

3. 实战：那些可以立刻改成零拷贝的场景

3.1 字符串切片不再 ToString

业务代码里最常见的复制来自“解析后取子串”。比如解析 Nginx 日志的一行：

ReadOnlySpan<char> line = logLine; ReadOnlySpan<char> ip = line.Slice(0, line.IndexOf(' ')); ReadOnlySpan<char> method = line.Slice(ip.Length + 1, 3);

这里我没有创建任何新字符串。后续如果需要判断 method 是不是 “GET”，直接：

if (method.Equals("GET".AsSpan(), StringComparison.Ordinal))

如果需要把它写进数据库或日志，可以用原始 span 配合管道写入，在最后一步才 ToString，甚至不一定需要 ToString，直接通过编码器把字符 span 转成字节写入流。

在我的经验里，做协议解析时至少要保证 80% 的中间步骤不产生 string 对象。真正需要调用以 string 为参数的库时，再构造也没关系，但别在每次切片、每个判断上都构造一遍。

3.2 解析二进制协议：长度前缀与字节序

网络封包经常是“头 + 长度 + 载荷”的布局。传统写法是用 BinaryReader 读流，它内部会做不少分配和边界判断。换成 Span 加 BinaryPrimitives，可以做到全程零分配解析。

static bool TryReadFrame(ReadOnlySpan<byte> buffer, out int consumed, out ReadOnlySpan<byte> payload) { consumed = 0; payload = default; if (buffer.Length < 4) return false; int frameLength = BinaryPrimitives.ReadInt32LittleEndian(buffer.Slice(0, 4)); if (frameLength < 0 || buffer.Length < 4 + frameLength) return false; payload = buffer.Slice(4, frameLength); consumed = 4 + frameLength; return true; }

这里面没有一次 new byte[]，也没有一次 Buffer.BlockCopy。BinaryPrimitives 直接以大端或小端方式读取基础类型，底层通过 unsafe 指针操作完成，速度远高于 BinaryReader 的逐字节解析。如果你希望代码比这更安全，还可以用 MemoryMarshal.TryGetArray 拿到底层数组，不过通常没有这个必要。

协议缓冲区如果是从网络流中读取的，使用 PipeReader 更理想。它返回 ReadOnlySequence ，是分段缓冲区的一种抽象，通过 SequenceReader 可以按顺序消费，避免把多个分段拼接成一个连续 buffer 的复制成本。配合 Span 解析时要注意分段处理，但这篇文章我们先聚焦连续缓冲区场景。

3.3 数字快速转换与字符判断

传统代码里从字符串截取一段后需要转 int：

string portStr = line.Slice(a, b).ToString(); int port = int.Parse(portStr);

这就有两次分配：ToString 生成字符串，解析再生成整数包装（如果装箱还好，值类型没有，但字符串分配跑不掉）。目前 .NET 已经提供 int.Parse(ReadOnlySpan ) 重载，可以直接写：

ReadOnlySpan<char> portSpan = line.Slice(a, b); int port = int.Parse(portSpan, CultureInfo.InvariantCulture);

同理，int.TryParse、DateTime.Parse 都有 Span 重载（DateTime.Parse 在部分版本用 ReadOnlySpan 重载）。对于字节缓冲区里的 UTF-8 数字，也可以直接用 System.Buffers.Text.Utf8Parser.TryParse 来解析，不需要先转换成临时 string。

3.4 字符串搜索与比较

很多查找类 API，只要不修改内容，都很适合用 Span：

• StartsWith / EndsWith
• Contains
• IndexOf
• SequenceEqual
• Replace（对字符串替换需要新对象，别用 Span 硬搞）

举一个实例，判断请求方法：

if (request.Span.StartsWith("POST".AsSpan()))

或者在字节缓冲中查找分隔符：

int newLineIndex = buffer.IndexOf((byte)'\n');

IndexOf 返回 int，后面直接 Slice(0, newLineIndex)，全程没有复制。注意字符和字节类型不同，IndexOf 对 ReadOnlySpan 查找 byte，对 ReadOnlySpan 查找 char。

3.5 Encoding 转换也可以零拷贝

.NET 默认的 Encoding.GetString(byte[], int, int) 会创建一个新字符串，这本身就是一次完整拷贝。如果只是想要“判断这段字节是不是纯 ASCII”，或者“计算某种编码下这段字符占多少字节”，完全可以用 span 配合编码器处理。真正需要字符串语义的时候，也别刻意排斥转换，转换本身有它存在的必要。

ReadOnlySpan<byte> utf8Bytes = ...; int charCount = Encoding.UTF8.GetCharCount(utf8Bytes);

这个方法不会分配字符串，只是估算。更近一步，.NET 提供 Encoding.UTF8.GetString(ReadOnlySpan )，传入 span，底层也可以利用内部缓存减少分配，但不代表零拷贝。如果需要真正的零拷贝编码场景，考虑使用第三方的高性能 UTF-8 处理库，或者自己遍历字节判断。对大多数人而言，用 span 方式传递缓冲区，把转换推迟到最终输出阶段，已经能赚到大头。

4. 实操过程与避坑清单：哪些“零拷贝”会踩雷

4.1 ref struct 的五个限制及应对

Span 是 ref struct，所以有一串普通类没有的限制，我列在这里，都是实际编译踩过的：

1. 不能装箱为 object、不能赋值给 interface 变量。
2. 不能作为 class 或 struct 的字段。
3. 不能用于泛型类型参数，除非该泛型参数在编译时也被约束为 ref struct。
4. 不能跨 await 使用（async 方法内不能用 Span 局部变量保存状态）。
5. 不能在迭代器中使用（yield return 内部不允许 ref struct 参数）。

你可能会遇到 CS8350、CS8175、CS4013 这类编译错误。它们不是 bug，是编译器在保护你。解决办法通常是换用 ReadOnlyMemory ，或者把整个同步处理段拆成一个同步方法，只让异步外壳等待它完成。

比如网络数据从一个 socket 异步读完，你希望直接在缓冲上解析。正确做法是：

ValueTask<int> receiveTask = socket.ReceiveAsync(buffer, SocketFlags.None); int received = await receiveTask; // 不能直接持有 Span 跨 await，但 await 之后再取 Span 是可以的 ReadOnlySpan<byte> data = buffer.AsSpan(0, received);

只要你不把 Span 对象本身当成跨 await 的局部变量，这个思路就没问题。实际中，我经常用一个同步方法把真正解析逻辑封装起来，传入 ReadOnlySpan ，然后从异步方法里 sync 调用它。

4.2 悬垂引用与生命周期管理

零拷贝意味着“引用别人的内存”，因此谁拥有这块内存、什么时候归还，必须清清楚楚。

用 ArrayPool 时最常见的坑是：把一个租来的数组转换成 Span，然后业务方法返回了这个 Span，但外层已经把数组归还。这是明摆着的悬挂引用。编译器无法检测这种情况，因为 Span 只是结构体，打包进方法返回值时全靠开发者的自觉。

我的经验是：如果方法要把内部缓冲区暴露给调用方，要么调用方同步处理完立刻归还，要么把这段缓冲区包装成 Memory + IMemoryOwner 形式，由调用方负责 Dispose。前后两者只能选一个，不能混用。代码审查时看到“Span 被 return 出去”，我一定会停下来检查它的来源和所有者。

4.3 字符串与字节转换不是免费的

有人以为把 string.AsSpan() 之后解析就彻底零拷贝了。这个想法基本正确，但要注意两点：

1. string.AsSpan() 确实不复制字符，它直接指向字符串内部字符区域。这是零拷贝。
2. 但如果你要从 byte[] 中取出文字内容做比较，byte 和 char 不是同一类型。byte[] 与 string 之间的转换需要编码过程，编码过程必然涉及计算。真正的零拷贝不是在“字符集合”层面上的零拷贝，而是说不要做不必要的内存复制。

所以在做 HTTP 解析时，最好的方法不是把 UTF-8 字节转成 string 再 AsSpan，而是直接用 ReadOnlySpan 偏移比较方法名和路径。比如：

ReadOnlySpan<byte> method = requestLine.Slice(0, 3); if (method.SequenceEqual("GET"u8))

"GET"u8是 C# 11 提供的 UTF-8 字符串字面量，编译后直接生成 ReadOnlySpan ，和待比较的字节切片做 SequenceEqual，全程不涉及字符编码，最省。

4.4 不要盲目追求零拷贝

很多人学了这个技巧后开始把所有方法都重写成 Span 版，结果代码可读性断崖式下跌，收益却很低。零拷贝优化的核心在于热路径。如果一个方法每秒只调用几十次，而每次创建的对象都很小，你花一整晚重构成 Span 完全是白费。

我的判断标准是：

• 对象分配频率高不高？
• 分配出来的对象生命周期长不长？
• 是否在循环或高频调度中？
• 一次分配的大小是否超过 85KB？如果分配的是大型对象，越容易被放到 LOH，回收代价极高，收益更明显。

如果这些问题里有至少两个答案是否，那把优先级往后放一放。

4.5 与旧框架的兼容性

Span 并不是 net6.0 才有的东西。在 .NET Core 2.1 时代就加入了核心 API。net48 和 netstandard2.0 也能通过 System.Memory NuGet 包使用大部分 API，但有些 API 确实受限，比如 string.Create、某些 MemoryExtensions 重载可能不可用。开发类库时要注意目标框架差异。

还有一个隐藏点：当你把调用方传入的 ReadOnlySpan 转成 stream 时，不能直接用 Span 本身做异步操作，因为 Stream 的 ReadAsync 需要 Memory/Memory 参数。通常的桥接方案是把 ReadOnlySpan 底层数组取出来，用 MemoryMarshal.TryGetArray 拿一段 ArraySegment 再转成 Memory。但这种做法有所有权风险，最好是把整个解析输入先用 ArrayPool 复制到一块固定内存，再做异步流式操作。

5. 性能测试与求证：量化收益

5.1 先用 BenchmarkDotNet 把话说清楚

谈到性能优化，没有数据就是在讲故事。我做这类优化时的标配是 BenchmarkDotNet。以字符串切片为例，做个简单基准：

[MemoryDiagnoser(false)] public class SliceBenchmark { private readonly string data = "GET /api/users?page=2 HTTP/1.1"; [Benchmark] public string SubstringVersion() { int firstSpace = data.IndexOf(' '); int secondSpace = data.IndexOf(' ', firstSpace + 1); return data.Substring(firstSpace + 1, secondSpace - firstSpace - 1); } [Benchmark] public ReadOnlySpan<char> SpanVersion() { var span = data.AsSpan(); int firstSpace = span.IndexOf(' '); int secondSpace = span.Slice(firstSpace + 1).IndexOf(' '); return span.Slice(firstSpace + 1, secondSpace); } }

注意 SpanVersion 返回的是 ReadOnlySpan ，BenchmarkDotNet 对这种返回类型支持度可能有限，更好的做法是直接把结果调用一次 ToString() 或者在内部做一次消费，避免 JIT 把整个计算折叠掉。实际测试结果的大方向很一致：Substring 版本每调用一次分配一个新字符串对象，Gen0 分配量在几十字节；Span 版本是零分配，耗时通常下降 50% 以上。

5.2 观察 GC 分配与暂停

除了 BenchmarkDotNet 的 MemoryDiagnoser 之外，运行时还可以观察：

• dotnet-counters monitor --process-id xxx --counters System.Runtime
• PerfView 的 GC 事件

重点看 Gen0 数量：如果优化前每百万次解析导致 Gen0 回收千百次，优化后降低到个位数，说明分配压力大幅缓解。GC 暂停时间也会随之减少。在真实服务里，你会发现应用的 CPU 总占用率并没有下降很多，但延迟的 P99（如百分位延迟）会明显改善，因为线程不再被 GC 打断。

5.3 用测试数据倒推收益

假设你有一个 API 网关，核心路由解析每请求执行 3 次 Substring，每次分配 30 字节，单请求分配 90 字节。若 QPS 是 1 万，每秒分配 900KB 的临时对象。这些对象大部分活不过 Gen0，但对 GC 来说，这 900KB 每秒钟都需要扫描，相当于每 10 秒触发一次 9MB 的 GC 压力。改成 Span 后，这部分完全消失。虽然单个对象 30 字节很小，可架不住量大，积少成多。

6. 常见问题与排查技巧实录

6.1 编译错误一箩筐

我在团队里经常被问到的编译错误，几乎都来自 ref struct 限制。总结几个最常见的：

• CS8350：此结构体不允许用于“ref struct”字段。如果你在自定义 ref struct 里存 Span，没问题，但在类字段里存 Span 就会报这个。
• CS8175：无法在 async 方法中使用 ref struct。把跨 await 的数据改成 Memory 。
• CS9091：/ CS9204？迭代器相关。不要在迭代器方法参数里用 Span 类型。

遇到这些错误，第一反应不是硬绕，而是拆解状态机边界。把同步处理的逻辑扔进一个单独方法，让速度关键路径保持 Span，异步流程里改用 Memory 缓冲。

6.2 库 API 如何安全暴露 Span

设计一个库时，比如一个解析器，你的公共方法可以接收 ReadOnlySpan 输入，输出请不要直接返回 Span，除非文档明确说明“返回值在输入 span 有效期间可用”。这对调用方是较强的约束。更好的 API 设计是返回 ReadOnlyMemory ，或者返回一个已解析的结构体对象，内部保存切片的起点和长度。

另一个思路是让库直接使用 IMemoryOwner ：

public interface IFrameConsumer { void Consume(ReadOnlySequence<byte> frames); }

用 ReadOnlySequence 表示不连续缓冲区，消费者内部通过 SequenceReader 遍历，不会产生拼接复制。

6.3 渐进式改造：不要一把梭

如果是一个运行中的老项目，最稳妥的方法是从 Profiler 前三甲入手：

1. 先用 dotnet-trace 采样，找出分配量最大的方法。
2. 把这些方法的参数改成 ReadOnlySpan 或 ReadOnlySpan 。
3. 内部把 new string 替换成 span 切片和 TryParse。
4. 单元测试保证逻辑不变。
5. 上线后对比 GC 指标。

每次只动一个模块，收益看得见，风险也可控。我见过太多人试图“一次性把整个代码库都改成 Span”，最后在某个 async 边界卡两周，灰溜溜放弃。渐进式改造远比推倒重来好。

6.4 在处理特别大的缓冲区时的注意点

如果输入缓冲区超过几 MB，使用 stackalloc 会导致栈溢出，千万别硬上。此时可以：

• 字符串：不要 Substring，先计算好切片的 offset、length，最后一次性输出。
• 字节流：用 ArrayPool .Shared 租借大块缓冲，处理完成后归还。归还时务必保证没有其他引用持有。

如果遇到某些库要求接收 byte[] 而不是 Span，可以用 MemoryMarshal.TryGetArray 尝试取回底层数组，但前提是你用的是数组作为底层存储。这个操作有额外开销，也会有数组所有权泄露风险，能不用就不用。

6.5 最后一个小技巧：把参数设计成 span 而不是 string

新建公共方法时，对于只读处理逻辑，我推荐尽量接收 ReadOnlySpan 或者 ReadOnlySpan ，而不是 string 或 byte[]。这样调用方可以用字符串、数组、栈缓冲区、原生内存等各种来源，灵活性极大。唯一的代价是一旦方法签名里出现 ref struct，这个 API 就不能在 async 方法、迭代器、类字段里直接持有，但这两个场景本身也不应该用托管字符串硬扛大对象。

在老 .NET 框架上，如果需要兼容，可以同时提供 string 参数的重载，内部转成 span 后共用同一实现。这种模式既给了调用方便利，又没有丢失性能敏感路径上的优化空间。

我自己的习惯是：拿到一个解析任务，先判断这段数据以后会不会被异步保存。如果不会，直接用 Span 从读入到算出结果一路贯穿，边界处才转成最终输出对象。如果会，把所有中间层都改成 Memory 或 ReadOnlySequence，只有最后的计算节点转换成 Span。这个原则实际执行下来，既没有把代码带偏，也没有在 GC 上吃大亏。