如果你写过一段有点规模的C#服务多半对“字符串转来转去、数组拷来拷去”这件事深有体会。一条日志进来Substring截几个字段Split再拆一下一个请求处理的中间对象随随便便就多出七八个等到流量上来GC尖峰就成了服务延迟里最扎眼的那根刺。早年我优化这类问题思路很简单——尽量减少字符串操作次数效果嘛有那么一点但总感觉治标不治本。直到我真正把Span用进生产代码才意识到以前的很多优化其实绕了远路。Span这个名字大家不陌生但不少人只停留在“用它可以少点堆分配”的层面对背后的零拷贝切片机制、ref struct限制、以及它在二进制协议解析里的正确打开方式反而讲不清楚。这篇内容是我拿实际项目做的一次复盘从一个工业设备通信解析的任务切入围绕Span的底层结构、三类零拷贝切片的实战写法、以及stackalloc、TryFormat、MemoryMarshal这些配套高性能工具把原理和坑逐个过一遍。适合手里正握着字节数组、字符串解析代码想压GC、想提升解析吞吐的C#/.NET开发者尤其适合做网关、上位机、协议栈和采集程序的兄弟。1. 为什么我放弃了SubstringC#内存访问的“复制地狱”1.1 传统字符串处理到底分配了多少中间对象先别急着上代码我们算一笔账。假设你要从一行日志里取某个字段的值最常见的写法是这样string line 2024-06-18 10:24:55 INFO backend torque6000; int start line.IndexOf(torque, StringComparison.Ordinal) 7; int end line.IndexOf( , start); string token line.Substring(start, end - start); int torque int.Parse(token);这段代码本身没毛病逻辑清晰运行也对。但它干了什么事Substring分配了一个新的stringint.Parse接收字符串后又可能进行内部规范化处理如果这个解析逻辑在循环里跑每秒几万次那Young Gen堆上就全是这些用完即弃的临时字符串。更夸张的是Split。很多人解析CSV或者带分隔符的协议时喜欢一句line.Split(,)看着省事实际上不仅仅会分配一个string[]数组还会为每个字段分配独立的string对象。一个字段较多的报文一行解析下来轻轻松松多出十几个对象。这些对象在后续的GC扫描中都逃不掉而GC每次运行就会STWStop The World哪怕只是短暂的暂停在高频交易或者实时设备控制场景里就是不可接受的毛刺。很多朋友不理解GC为什么会影响性能总觉得“反正内存够用”。其实问题不在于内存够不够而在于托管堆上的垃圾对象越多GC需要扫描、标记、压缩的工作量就越大。当分配速率远大于回收速率时GC会频繁触发程序的表现就像一台刚开机就一直在后台跑杀毒软件的电脑表面看CPU占用不高实际响应延迟忽高忽低。1.2 从扭矩读取场景看到的典型分配链前段时间我在做一个工业设备通信的网关设备是一台扭矩控制器类似那种拧螺丝但能实时回传扭矩值的工具。它的通信协议很简单上位机发一条命令帧设备返回一帧状态数据里面带扭矩数值。起初我按惯性思维写了个解析器byte[] response ReadFromDevice(); int payloadOffset 8; int length 4; byte[] torqueBytes new byte[length]; Array.Copy(response, payloadOffset, torqueBytes, 0, length); int torque BitConverter.ToInt32(torqueBytes, 0); string display torque.ToString();这段代码看着不复杂实际每一行都可能产生垃圾new byte[length]堆上分配一个新数组就为了复制4个字节Array.Copy一次数据拷贝int.ToString()分配字符串后面如果再拼上单位、设备号还得再加几个字符串对象。我再往深挖发现问题不止在解析这一层。底层ReadFromDevice返回的这个byte[]其实是从Socket Receive回调里拷贝出来的而之前的那次拷贝又是为了确保缓冲区的数据不被下一帧覆盖。也就是说“多一次拷贝”这个习惯是层层叠加出来的每一层都觉得自己只是多复制了一小段而已。这种复制链路的坏处在解析低频时看不出来一旦设备以几十甚至上百赫兹的频率上报网关还要同时承担多个协议转换分配压力就上来了。之前跑了一晚上内存曲线像锯齿GC次数非常难看。这时我才真正下决心把整条链路重写成零拷贝风格——核心工具就是SpanT。2. 拆开Span的底层设计ref struct、引用与长度2.1 Span 在运行时其实就是“引用长度”很多C#开发者刚接触Span时会直觉地把它理解成“像数组一样的东西”。这个理解方向对但不够本质。SpanT真正保存的是两个字段一个是指向数据起始位置的托管引用在unsafe场景下也可能是原始指针另一个是长度。它本质上是一种“带边界的窗口”非常像C/C里“指针长度”的组合只不过在托管世界里CLR用这个结构体把安全性给兜住了。正是这个设计让“切片”不再需要复制。数组切片、字符串切片、非托管内存切片最终都只是创建一个新的ref和新的length底层那几MB数据还是那些数据一个字节都不会动。你可以把Span想象成在窗户纸上开一个方孔你看到的范围变了但窗户纸本身没变。我们要读取“torque6000”中的“6000”直接开一个指向那四个字符的窗口就行没必要把“6000”这四个字符剪下来贴到别处。下面这段代码展示的是最核心的切片能力byte[] buffer new byte[1024]; // 取偏移8、长度20的一段作为“切片” Spanbyte payload buffer.AsSpan(8, 20); // 再切一段不复制任何数据 Spanbyte torqueField payload.Slice(6, 4);Slice操作返回的还是Span它照样持有原数组的引用只是窗口位置变了。整个过程没有堆分配、没有字节拷贝——这就是零拷贝最直观的体现。2.2 ref struct的约束为什么这么严格SpanT被定义为ref struct这是它的身份标签也是限制的来源。ref struct类型有两条硬性规定只能出现在栈上不能装箱成object不能作为普通类的字段、不能进入LINQ查询表达式、不能穿越await边界。这意味着你不能写一个返回ListSpanint的方法不能把Span存进数组也不能在async方法里跨await持有Span。这些限制看起来烦人但它们是安全性的基石。试想一下Span持有的是一个托管引用CLR需要随时知道这个引用的来源对象还在不在堆上。如果允许Span被装箱、被放进类字段、被莫名其妙地缓存起来那么管理引用生命周期就会变得极其困难。栈上类型让编译器可以通过静态分析判断Span的生命周期确保它不会比源数据活得更久从而避免悬挂引用。如果确实需要把数据引用保存到堆上标准答案是MemoryT。MemoryT是普通结构体可以装箱、可以放字段、可以进异步方法用它拿到Memory.Span之后才进行真正的零拷贝切片操作。所以实际项目里有个常见组合接口和存储层用Memorybyte计算和解析层用Spanbyte各管各的活。使用场景SpanTMemoryT方法参数/局部变量可以可以类字段/集合存储不行可以async方法中跨await不行可以Lambda/闭包捕获不行可以直接零拷贝切片原生支持通过.Span后再切片3. 三类零拷贝切片实战字符串解析、字节处理与Native内存3.1 字符串场景把Substring换成AsSpan字符串在C#里是UTF-16编码的内部就是一个ReadOnlySpanchar的天然载体。遇到“从一段文本中取出子字段”的需求正确姿势不是Substring而是AsSpan。AsSpan不会产生新字符串它只是开了一个只读窗口。我用开头那个日志解析的例子做改造string line 2024-06-18 10:24:55 INFO backend torque6000; int start line.IndexOf(torque, StringComparison.Ordinal) 7; int end line.IndexOf( , start); ReadOnlySpanchar valueSpan line.AsSpan(start, end - start); int torque int.TryParse(valueSpan, out int result) ? result : 0;这段逻辑和Substring版本几乎一样但有一个内核差别没有分配任何一个新字符串。int.TryParse有一个ReadOnlySpanchar的重载可以直接解析窗外的那几个字符底层做的事情和解析字符串完全一致。再进阶一点如果要在日志文本里反复寻找某个字段可以连IndexOf也换成Span的搜索方式。比如给扭矩设备解析文本响应时我曾经写过这样一个方法在原始文本上搜索torque关键字然后直接切出后面的数字区域。整个过程完全无分配。private static bool TryParseTorque(ReadOnlySpanchar line, out int torque) { ReadOnlySpanchar key torque; int index line.IndexOf(key); if (index 0) { torque 0; return false; } int start index key.Length; int end start; while (end line.Length char.IsAsciiDigit(line[end])) { end; } if (end start) { torque 0; return false; } return int.TryParse(line.Slice(start, end - start), out torque); }这里line.IndexOf(key)是对只读Span做的子串查找不会分配临时字符串数字区域的判断是直接在原始文本的Span窗口上扫描。整条链路中输入的那根string没有被改动也没有任何中间string被创造出来。3.2 字节场景切出payload用BinaryPrimitives直接读整数处理二进制协议时Span的零拷贝价值体现得更彻底。先看一个扭矩控制器的帧结构示意偏移长度含义04帧头 0xAA 0x55 0x01 0x0042命令字64扭矩值int32小端序102CRC16校验传统做法是Array.Copy把扭矩值拷贝到临时数组再BitConverter.ToInt32。换成Span后是这样Spanbyte frame ReadFrame(); int torque BinaryPrimitives.ReadInt32LittleEndian(frame.Slice(6, 4));frame.Slice(6, 4)没有复制任何一个字节它只是构造了一个窗口指向从第6个字节开始的4个字节。BinaryPrimitives.ReadInt32LittleEndian则直接在原始内存上按小端序读出整数完全没有中间数组。读出来之后通常还需要校验CRC、拼响应帧、把扭矩值转成文本上报。这里有个容易被忽略的经验如果你接下来要把int torque转成字符串用torque.ToString()会分配字符串对吧但在很多场景下我们并不需要那个字符串对象真正存在只需要它的字符填充到一个更大的缓冲区里。这时候用TryFormat更合适它能把数字直接格式化进某个Span零分配完成。这个后面详细说。二进制解析还有一个杀手级用法MemoryMarshal.Cast。它可以把一个Spanbyte直接重新解释成SpanSomeStruct连字段级别的拷贝都省掉。比如上面那个帧结构如果定义一个布局匹配的结构体[StructLayout(LayoutKind.Sequential, Pack 1)] private readonly struct TorqueFrame { public readonly uint Header; public readonly ushort Command; public readonly int Torque; public readonly ushort Crc; }解析时就可以这样Spanbyte buffer ReadFrame(); SpanTorqueFrame frames MemoryMarshal.Castbyte, TorqueFrame(buffer); int torque frames[0].Torque;这一步本质上是在告诉你字节数组里本来是byte视角的数据现在换成了TorqueFrame视角底层数据块丝毫没动。这对解析固定布局的协议帧来说效率提升是碾压级的。3.3 Native内存场景用Span直接封住非托管缓冲区工业设备通信里常遇到非托管内存比如某些SDK通过回调给你一个IntPtr和长度让你自己解析内容。以前的标准操作是Marshal.Copy先把原生内存拷到托管数组解析完再释放这一来一回又是两份数据副本。有了Span可以直接在非托管指针上开窗口unsafe { byte* ptr (byte*)nativePtr.ToPointer(); int length nativeLength; Spanbyte nativeSpan new Spanbyte(ptr, length); // 直接在这个Span上解析不需要任何拷贝 int torque BinaryPrimitives.ReadInt32LittleEndian(nativeSpan.Slice(6, 4)); }new Spanbyte(ptr, length)是Span提供的指针构造重载它把非托管内存装进了托管安全的窗口里。后续所有解析代码都跑在这段原生内存上零拷贝、零分配。需要注意的是这种用法必须放在unsafe上下文中而且你得自己对指针的有效期负责Span不管理原生内存的生命周期。我自己第一次用这个方式时最大的感受是之前还要纠结“拷到byte[]之后谁负责释放”的问题拷完的数组会不会被GC移动、要不要固定现在全都省了。设备SDK告诉我缓冲区地址和大小我直接就在上面开干干完不管释放因为释放本来就是SDK的事。3.4 三类场景选择速查数据源常规做法Span做法是否零拷贝stringSubstring / SplitAsSpan Slice是byte[]Array.Copy / BitConverterAsSpan BinaryPrimitives是非托管IntPtrMarshal.Copy转托管数组new Spanbyte(ptr, len)是二进制结构数组逐字段Marshal.ReadInt32MemoryMarshal.Cast是一句话总结凡是你能拿到一段连续内存并且只需要“查看其中一部分”的场景都有机会用Span把复制省掉。4. 性能进阶stackalloc、TryFormat与MemoryMarshal4.1 stackalloc临时缓冲区直接放栈上很多解析过程需要一个临时缓冲区来拼报文、转字符串常规做法是new byte[...]这会在每次调用时产生堆分配。如果缓冲区很小完全可以用stackalloc把它放在栈上方法一结束自动释放根本不经过GC。举一个具体场景把扭矩值格式化后填入某个上报帧里。假设帧里有一段文本区域需要写入torque6000这样的ASCII内容用Span加stackalloc可以写得非常干净Spanchar buffer stackalloc char[64]; buffer[..7].CopyTo(torque.AsSpan()); if (torque.TryFormat(buffer[7..], out int written, D, CultureInfo.InvariantCulture)) { ReadOnlySpanchar payload buffer[..(7 written)]; // payload就是要发送或展示的内容 }stackalloc char[64]在栈上申请了64个字符的空间没有堆对象。方法返回后这块空间自动回收。这比反复new StringBuilder或者string.Concat不知道省了多少。不过stackalloc有个度的问题。栈空间是有限的默认线程栈也就1MB左右一次申请几十个字节没问题但如果申请几MB则可能直接栈溢出而且栈溢出是整个进程崩溃连catch都救不回来。我的经验是临时缓冲区在1KB以内优先用stackalloc超过这个量级就用ArrayPoolbyte.Shared让池化的数组来兜底。4.2 TryFormat把数字格式化变成无分配操作说到数字转字符串很多人第一反应是ToString()。但它会分配一个字符串对象。在只需要把数字填进某个已有缓冲区的场景里这个分配完全没有必要。TryFormat是为这类需求设计的它把格式化结果直接写入目标Span写多少个字符由out int written告诉你。上面的例子里我用一行torque.TryFormat(buffer[7..], out int written, D, CultureInfo.InvariantCulture)就把扭矩值格式好放进了缓冲区。它不会创造一个“中间字符串”整个过程从数字到字符是一次性的。这个API最早是给IFormattable做底层支持的后来作为公开API放了出来。用熟了之后你会发现在拼报文、写文件缓冲区、做日志落盘时它能帮你砍掉一大批小对象分配。我在自己项目里把一些高频路径的int.ToString()改成TryFormat后年轻代GC次数肉眼可见地降了一截。4.3 MemoryMarshal.Cast把字节流直接映射成结构数组前面提到MemoryMarshal.Cast可以把Spanbyte变成SpanT这是二进制协议解析里的重要大招。它要求T是blittable类型也就是托管内存布局与非托管内存布局一致没有引用类型字段。上面那个TorqueFrame结构体就满足这个条件。这个能力相当于C/C里把char*强转成struct*的玩法但CLR会顺带检查目标类型布局。在协议解析中它让我可以这样写代码Spanbyte buffer ReadFrame(); SpanTorqueFrame frames MemoryMarshal.Castbyte, TorqueFrame(buffer); foreach (ref readonly TorqueFrame frame in frames) { if (frame.Header ! 0xAA550100) { continue; } int torque frame.Torque; // 处理扭矩值 }这里foreach (ref readonly ...)本身就是配合ref struct类型做高效遍历的方式不会产生装箱。整段代码在一帧数据上完成了解析和遍历没有任何字段级别的拷贝。但要注意两个容易踩的细节目标结构体最好用[StructLayout(LayoutKind.Sequential, Pack 1)]显式声明避免编译器为了对齐而偷偷插入填充字节导致布局和你协议定义不一致小端序问题。BinaryPrimitives和MemoryMarshal.Cast都遵循平台字节序。工业设备绝大多数是小端协议x86/x64上没问题如果跑在ARM平台上遇到大端设备就要先做字节反转处理。5. 性能背后的暗礁async限制、边界检查与内存悬挂5.1 async方法里的Span禁令以及用Memory续命这是新手最容易撞墙的地方。你写了个网络接收的async方法想直接用Span处理收到的数据public async Task HandleAsync(Socket socket) { byte[] buffer new byte[1024]; int read await socket.ReceiveAsync(buffer, SocketFlags.None); Spanbyte data buffer.AsSpan(0, read); // 编译通过 await Task.Delay(1); // 这里会编译报错 Process(data); }原因前面讲过Span不能跨await存活编译器在语法层面就拦住了。解决办法是理解“数据归谁所有”。ReceiveAsync用的是数组那么这个数组本身是堆对象完全可以在await之后继续用。你要做的只是把“窗口”延后创建public async Task HandleAsync(Socket socket) { byte[] buffer new byte[1024]; int read await socket.ReceiveAsync(buffer, SocketFlags.None); // await结束之后才创建窗口编译通过 Spanbyte data buffer.AsSpan(0, read); Process(data); }如果确实需要在await期间保留数据引用那就上MemorybyteMemorybyte memory buffer.AsMemory(0, read); await Task.Delay(1); Spanbyte data memory.Span; Process(data);Memorybyte可以被async方法携带因为它是普通结构体。到了真正要做高性能切片的地方再从Memory拿到Span。这个“接口用Memory、计算用Span”的原则在异步TCP服务里非常好用。5.2 边界检查的真相别把Slice的参数算错Span.Slice本身是有边界检查的你传的起始位置加长度如果超出原Span长度会抛ArgumentOutOfRangeException。这意味着它有安全性但不是无条件的。在release模式下JIT会根据上下文中已有的长度信息消除一部分边界检查但如果代码分支太多、分析不过来边界检查依然存在。我在实际项目里踩过一个相关的坑把帧头长度直接写死在Slice的参数里后来协议升级帧头从4字节变成8字节结果所有解析代码的偏移量全错了。排查时因为抛异常的位置不直观花了不少时间。后来我养成了习惯在帧解析入口统一算好字段偏移所有Slice操作都基于变量而不是魔法数字。比如int headerSize 8; int torqueOffset headerSize 2; int torqueSize 4; Spanbyte torqueField frame.Slice(torqueOffset, torqueSize);这样协议一变只需要改定义偏移的地方。别小看这个习惯它救了我后面的多次协议变更。5.3 Native内存的释放顺序与悬挂风险非托管内存用Span包住之后虽然访问方便但有个责任不能丢Span本身不管理生命周期。如果你new Spanbyte(ptr, length)之后把ptr指向的内存释放了再继续用这个Span那就是典型的悬挂引用轻则读到垃圾数据重则程序崩溃。我见过一种比较隐蔽的错误是把非托管内存的释放动作放在异步回调里而调用方还拿着之前创建的Span继续解析。代码在编译期没有那么明显的错误提示运行时的表现也时好时坏非常难排查。我的建议是谨慎使用非托管指针构造Span并且在使用它的方法上明确标记unsafe用方法名和注释强提醒“此Span生命周期仅限于本次调用”。如果这段内存是外部SDK管理的就严格做一个“窗口期”约定Span只在收到回调到回调返回之间有效绝不缓存、绝不跨方法传递。5.4 什么时候别用Span说了这么多好处我还是想泼一点冷水阶段不是万能的也有不该用它的地方。字符串很短复制开销可以忽略比如截取一个两位数的状态码Substring的分配成本微乎其微为了“省一次分配”把代码改得晦涩不值得。需要把结果长期保存Span是栈上的窗口你没法把它存进字段、集合如果数据后续要跨方法跨线程使用老老实实返回string或byte[]。代码可读性优先的场景团队里不是每个人都了解ref struct的约束如果把异步方法改得到处是Span和Memory会让维护成本上升。优化热点路径可以但没必要把整条业务链路都激进改造。归根到底Span是一种武器它的价值体现在“真正被流量打中”的路径上。我在扭矩解析这个场景里动手是因为它每秒调用数千次、分配对象数量多到影响GC如果是一条低频的管理命令解析优先保证代码清晰就好。另外分享一个实践心得做这类优化一定要先测量、后动手。我习惯先用dotnet-counters或者BenchmarkDotNet把热点方法的堆分配量打出来确认分配大头在哪几行再去针对性改造。没有数据支撑的“优化”大部分时候只是在给后续维护埋雷。 
长河君 · 2026/10/6 5:08:31 · 阅读 1.2k C# Span零拷贝实战：从字符串解析到二进制协议的性能优化
如果你写过一段有点规模的C#服务多半对“字符串转来转去、数组拷来拷去”这件事深有体会。一条日志进来Substring截几个字段Split再拆一下一个请求处理的中间对象随随便便就多出七八个等到流量上来GC尖峰就成了服务延迟里最扎眼的那根刺。早年我优化这类问题思路很简单——尽量减少字符串操作次数效果嘛有那么一点但总感觉治标不治本。直到我真正把Span用进生产代码才意识到以前的很多优化其实绕了远路。Span这个名字大家不陌生但不少人只停留在“用它可以少点堆分配”的层面对背后的零拷贝切片机制、ref struct限制、以及它在二进制协议解析里的正确打开方式反而讲不清楚。这篇内容是我拿实际项目做的一次复盘从一个工业设备通信解析的任务切入围绕Span的底层结构、三类零拷贝切片的实战写法、以及stackalloc、TryFormat、MemoryMarshal这些配套高性能工具把原理和坑逐个过一遍。适合手里正握着字节数组、字符串解析代码想压GC、想提升解析吞吐的C#/.NET开发者尤其适合做网关、上位机、协议栈和采集程序的兄弟。1. 为什么我放弃了SubstringC#内存访问的“复制地狱”1.1 传统字符串处理到底分配了多少中间对象先别急着上代码我们算一笔账。假设你要从一行日志里取某个字段的值最常见的写法是这样string line 2024-06-18 10:24:55 INFO backend torque6000; int start line.IndexOf(torque, StringComparison.Ordinal) 7; int end line.IndexOf( , start); string token line.Substring(start, end - start); int torque int.Parse(token);这段代码本身没毛病逻辑清晰运行也对。但它干了什么事Substring分配了一个新的stringint.Parse接收字符串后又可能进行内部规范化处理如果这个解析逻辑在循环里跑每秒几万次那Young Gen堆上就全是这些用完即弃的临时字符串。更夸张的是Split。很多人解析CSV或者带分隔符的协议时喜欢一句line.Split(,)看着省事实际上不仅仅会分配一个string[]数组还会为每个字段分配独立的string对象。一个字段较多的报文一行解析下来轻轻松松多出十几个对象。这些对象在后续的GC扫描中都逃不掉而GC每次运行就会STWStop The World哪怕只是短暂的暂停在高频交易或者实时设备控制场景里就是不可接受的毛刺。很多朋友不理解GC为什么会影响性能总觉得“反正内存够用”。其实问题不在于内存够不够而在于托管堆上的垃圾对象越多GC需要扫描、标记、压缩的工作量就越大。当分配速率远大于回收速率时GC会频繁触发程序的表现就像一台刚开机就一直在后台跑杀毒软件的电脑表面看CPU占用不高实际响应延迟忽高忽低。1.2 从扭矩读取场景看到的典型分配链前段时间我在做一个工业设备通信的网关设备是一台扭矩控制器类似那种拧螺丝但能实时回传扭矩值的工具。它的通信协议很简单上位机发一条命令帧设备返回一帧状态数据里面带扭矩数值。起初我按惯性思维写了个解析器byte[] response ReadFromDevice(); int payloadOffset 8; int length 4; byte[] torqueBytes new byte[length]; Array.Copy(response, payloadOffset, torqueBytes, 0, length); int torque BitConverter.ToInt32(torqueBytes, 0); string display torque.ToString();这段代码看着不复杂实际每一行都可能产生垃圾new byte[length]堆上分配一个新数组就为了复制4个字节Array.Copy一次数据拷贝int.ToString()分配字符串后面如果再拼上单位、设备号还得再加几个字符串对象。我再往深挖发现问题不止在解析这一层。底层ReadFromDevice返回的这个byte[]其实是从Socket Receive回调里拷贝出来的而之前的那次拷贝又是为了确保缓冲区的数据不被下一帧覆盖。也就是说“多一次拷贝”这个习惯是层层叠加出来的每一层都觉得自己只是多复制了一小段而已。这种复制链路的坏处在解析低频时看不出来一旦设备以几十甚至上百赫兹的频率上报网关还要同时承担多个协议转换分配压力就上来了。之前跑了一晚上内存曲线像锯齿GC次数非常难看。这时我才真正下决心把整条链路重写成零拷贝风格——核心工具就是SpanT。2. 拆开Span的底层设计ref struct、引用与长度2.1 Span 在运行时其实就是“引用长度”很多C#开发者刚接触Span时会直觉地把它理解成“像数组一样的东西”。这个理解方向对但不够本质。SpanT真正保存的是两个字段一个是指向数据起始位置的托管引用在unsafe场景下也可能是原始指针另一个是长度。它本质上是一种“带边界的窗口”非常像C/C里“指针长度”的组合只不过在托管世界里CLR用这个结构体把安全性给兜住了。正是这个设计让“切片”不再需要复制。数组切片、字符串切片、非托管内存切片最终都只是创建一个新的ref和新的length底层那几MB数据还是那些数据一个字节都不会动。你可以把Span想象成在窗户纸上开一个方孔你看到的范围变了但窗户纸本身没变。我们要读取“torque6000”中的“6000”直接开一个指向那四个字符的窗口就行没必要把“6000”这四个字符剪下来贴到别处。下面这段代码展示的是最核心的切片能力byte[] buffer new byte[1024]; // 取偏移8、长度20的一段作为“切片” Spanbyte payload buffer.AsSpan(8, 20); // 再切一段不复制任何数据 Spanbyte torqueField payload.Slice(6, 4);Slice操作返回的还是Span它照样持有原数组的引用只是窗口位置变了。整个过程没有堆分配、没有字节拷贝——这就是零拷贝最直观的体现。2.2 ref struct的约束为什么这么严格SpanT被定义为ref struct这是它的身份标签也是限制的来源。ref struct类型有两条硬性规定只能出现在栈上不能装箱成object不能作为普通类的字段、不能进入LINQ查询表达式、不能穿越await边界。这意味着你不能写一个返回ListSpanint的方法不能把Span存进数组也不能在async方法里跨await持有Span。这些限制看起来烦人但它们是安全性的基石。试想一下Span持有的是一个托管引用CLR需要随时知道这个引用的来源对象还在不在堆上。如果允许Span被装箱、被放进类字段、被莫名其妙地缓存起来那么管理引用生命周期就会变得极其困难。栈上类型让编译器可以通过静态分析判断Span的生命周期确保它不会比源数据活得更久从而避免悬挂引用。如果确实需要把数据引用保存到堆上标准答案是MemoryT。MemoryT是普通结构体可以装箱、可以放字段、可以进异步方法用它拿到Memory.Span之后才进行真正的零拷贝切片操作。所以实际项目里有个常见组合接口和存储层用Memorybyte计算和解析层用Spanbyte各管各的活。使用场景SpanTMemoryT方法参数/局部变量可以可以类字段/集合存储不行可以async方法中跨await不行可以Lambda/闭包捕获不行可以直接零拷贝切片原生支持通过.Span后再切片3. 三类零拷贝切片实战字符串解析、字节处理与Native内存3.1 字符串场景把Substring换成AsSpan字符串在C#里是UTF-16编码的内部就是一个ReadOnlySpanchar的天然载体。遇到“从一段文本中取出子字段”的需求正确姿势不是Substring而是AsSpan。AsSpan不会产生新字符串它只是开了一个只读窗口。我用开头那个日志解析的例子做改造string line 2024-06-18 10:24:55 INFO backend torque6000; int start line.IndexOf(torque, StringComparison.Ordinal) 7; int end line.IndexOf( , start); ReadOnlySpanchar valueSpan line.AsSpan(start, end - start); int torque int.TryParse(valueSpan, out int result) ? result : 0;这段逻辑和Substring版本几乎一样但有一个内核差别没有分配任何一个新字符串。int.TryParse有一个ReadOnlySpanchar的重载可以直接解析窗外的那几个字符底层做的事情和解析字符串完全一致。再进阶一点如果要在日志文本里反复寻找某个字段可以连IndexOf也换成Span的搜索方式。比如给扭矩设备解析文本响应时我曾经写过这样一个方法在原始文本上搜索torque关键字然后直接切出后面的数字区域。整个过程完全无分配。private static bool TryParseTorque(ReadOnlySpanchar line, out int torque) { ReadOnlySpanchar key torque; int index line.IndexOf(key); if (index 0) { torque 0; return false; } int start index key.Length; int end start; while (end line.Length char.IsAsciiDigit(line[end])) { end; } if (end start) { torque 0; return false; } return int.TryParse(line.Slice(start, end - start), out torque); }这里line.IndexOf(key)是对只读Span做的子串查找不会分配临时字符串数字区域的判断是直接在原始文本的Span窗口上扫描。整条链路中输入的那根string没有被改动也没有任何中间string被创造出来。3.2 字节场景切出payload用BinaryPrimitives直接读整数处理二进制协议时Span的零拷贝价值体现得更彻底。先看一个扭矩控制器的帧结构示意偏移长度含义04帧头 0xAA 0x55 0x01 0x0042命令字64扭矩值int32小端序102CRC16校验传统做法是Array.Copy把扭矩值拷贝到临时数组再BitConverter.ToInt32。换成Span后是这样Spanbyte frame ReadFrame(); int torque BinaryPrimitives.ReadInt32LittleEndian(frame.Slice(6, 4));frame.Slice(6, 4)没有复制任何一个字节它只是构造了一个窗口指向从第6个字节开始的4个字节。BinaryPrimitives.ReadInt32LittleEndian则直接在原始内存上按小端序读出整数完全没有中间数组。读出来之后通常还需要校验CRC、拼响应帧、把扭矩值转成文本上报。这里有个容易被忽略的经验如果你接下来要把int torque转成字符串用torque.ToString()会分配字符串对吧但在很多场景下我们并不需要那个字符串对象真正存在只需要它的字符填充到一个更大的缓冲区里。这时候用TryFormat更合适它能把数字直接格式化进某个Span零分配完成。这个后面详细说。二进制解析还有一个杀手级用法MemoryMarshal.Cast。它可以把一个Spanbyte直接重新解释成SpanSomeStruct连字段级别的拷贝都省掉。比如上面那个帧结构如果定义一个布局匹配的结构体[StructLayout(LayoutKind.Sequential, Pack 1)] private readonly struct TorqueFrame { public readonly uint Header; public readonly ushort Command; public readonly int Torque; public readonly ushort Crc; }解析时就可以这样Spanbyte buffer ReadFrame(); SpanTorqueFrame frames MemoryMarshal.Castbyte, TorqueFrame(buffer); int torque frames[0].Torque;这一步本质上是在告诉你字节数组里本来是byte视角的数据现在换成了TorqueFrame视角底层数据块丝毫没动。这对解析固定布局的协议帧来说效率提升是碾压级的。3.3 Native内存场景用Span直接封住非托管缓冲区工业设备通信里常遇到非托管内存比如某些SDK通过回调给你一个IntPtr和长度让你自己解析内容。以前的标准操作是Marshal.Copy先把原生内存拷到托管数组解析完再释放这一来一回又是两份数据副本。有了Span可以直接在非托管指针上开窗口unsafe { byte* ptr (byte*)nativePtr.ToPointer(); int length nativeLength; Spanbyte nativeSpan new Spanbyte(ptr, length); // 直接在这个Span上解析不需要任何拷贝 int torque BinaryPrimitives.ReadInt32LittleEndian(nativeSpan.Slice(6, 4)); }new Spanbyte(ptr, length)是Span提供的指针构造重载它把非托管内存装进了托管安全的窗口里。后续所有解析代码都跑在这段原生内存上零拷贝、零分配。需要注意的是这种用法必须放在unsafe上下文中而且你得自己对指针的有效期负责Span不管理原生内存的生命周期。我自己第一次用这个方式时最大的感受是之前还要纠结“拷到byte[]之后谁负责释放”的问题拷完的数组会不会被GC移动、要不要固定现在全都省了。设备SDK告诉我缓冲区地址和大小我直接就在上面开干干完不管释放因为释放本来就是SDK的事。3.4 三类场景选择速查数据源常规做法Span做法是否零拷贝stringSubstring / SplitAsSpan Slice是byte[]Array.Copy / BitConverterAsSpan BinaryPrimitives是非托管IntPtrMarshal.Copy转托管数组new Spanbyte(ptr, len)是二进制结构数组逐字段Marshal.ReadInt32MemoryMarshal.Cast是一句话总结凡是你能拿到一段连续内存并且只需要“查看其中一部分”的场景都有机会用Span把复制省掉。4. 性能进阶stackalloc、TryFormat与MemoryMarshal4.1 stackalloc临时缓冲区直接放栈上很多解析过程需要一个临时缓冲区来拼报文、转字符串常规做法是new byte[...]这会在每次调用时产生堆分配。如果缓冲区很小完全可以用stackalloc把它放在栈上方法一结束自动释放根本不经过GC。举一个具体场景把扭矩值格式化后填入某个上报帧里。假设帧里有一段文本区域需要写入torque6000这样的ASCII内容用Span加stackalloc可以写得非常干净Spanchar buffer stackalloc char[64]; buffer[..7].CopyTo(torque.AsSpan()); if (torque.TryFormat(buffer[7..], out int written, D, CultureInfo.InvariantCulture)) { ReadOnlySpanchar payload buffer[..(7 written)]; // payload就是要发送或展示的内容 }stackalloc char[64]在栈上申请了64个字符的空间没有堆对象。方法返回后这块空间自动回收。这比反复new StringBuilder或者string.Concat不知道省了多少。不过stackalloc有个度的问题。栈空间是有限的默认线程栈也就1MB左右一次申请几十个字节没问题但如果申请几MB则可能直接栈溢出而且栈溢出是整个进程崩溃连catch都救不回来。我的经验是临时缓冲区在1KB以内优先用stackalloc超过这个量级就用ArrayPoolbyte.Shared让池化的数组来兜底。4.2 TryFormat把数字格式化变成无分配操作说到数字转字符串很多人第一反应是ToString()。但它会分配一个字符串对象。在只需要把数字填进某个已有缓冲区的场景里这个分配完全没有必要。TryFormat是为这类需求设计的它把格式化结果直接写入目标Span写多少个字符由out int written告诉你。上面的例子里我用一行torque.TryFormat(buffer[7..], out int written, D, CultureInfo.InvariantCulture)就把扭矩值格式好放进了缓冲区。它不会创造一个“中间字符串”整个过程从数字到字符是一次性的。这个API最早是给IFormattable做底层支持的后来作为公开API放了出来。用熟了之后你会发现在拼报文、写文件缓冲区、做日志落盘时它能帮你砍掉一大批小对象分配。我在自己项目里把一些高频路径的int.ToString()改成TryFormat后年轻代GC次数肉眼可见地降了一截。4.3 MemoryMarshal.Cast把字节流直接映射成结构数组前面提到MemoryMarshal.Cast可以把Spanbyte变成SpanT这是二进制协议解析里的重要大招。它要求T是blittable类型也就是托管内存布局与非托管内存布局一致没有引用类型字段。上面那个TorqueFrame结构体就满足这个条件。这个能力相当于C/C里把char*强转成struct*的玩法但CLR会顺带检查目标类型布局。在协议解析中它让我可以这样写代码Spanbyte buffer ReadFrame(); SpanTorqueFrame frames MemoryMarshal.Castbyte, TorqueFrame(buffer); foreach (ref readonly TorqueFrame frame in frames) { if (frame.Header ! 0xAA550100) { continue; } int torque frame.Torque; // 处理扭矩值 }这里foreach (ref readonly ...)本身就是配合ref struct类型做高效遍历的方式不会产生装箱。整段代码在一帧数据上完成了解析和遍历没有任何字段级别的拷贝。但要注意两个容易踩的细节目标结构体最好用[StructLayout(LayoutKind.Sequential, Pack 1)]显式声明避免编译器为了对齐而偷偷插入填充字节导致布局和你协议定义不一致小端序问题。BinaryPrimitives和MemoryMarshal.Cast都遵循平台字节序。工业设备绝大多数是小端协议x86/x64上没问题如果跑在ARM平台上遇到大端设备就要先做字节反转处理。5. 性能背后的暗礁async限制、边界检查与内存悬挂5.1 async方法里的Span禁令以及用Memory续命这是新手最容易撞墙的地方。你写了个网络接收的async方法想直接用Span处理收到的数据public async Task HandleAsync(Socket socket) { byte[] buffer new byte[1024]; int read await socket.ReceiveAsync(buffer, SocketFlags.None); Spanbyte data buffer.AsSpan(0, read); // 编译通过 await Task.Delay(1); // 这里会编译报错 Process(data); }原因前面讲过Span不能跨await存活编译器在语法层面就拦住了。解决办法是理解“数据归谁所有”。ReceiveAsync用的是数组那么这个数组本身是堆对象完全可以在await之后继续用。你要做的只是把“窗口”延后创建public async Task HandleAsync(Socket socket) { byte[] buffer new byte[1024]; int read await socket.ReceiveAsync(buffer, SocketFlags.None); // await结束之后才创建窗口编译通过 Spanbyte data buffer.AsSpan(0, read); Process(data); }如果确实需要在await期间保留数据引用那就上MemorybyteMemorybyte memory buffer.AsMemory(0, read); await Task.Delay(1); Spanbyte data memory.Span; Process(data);Memorybyte可以被async方法携带因为它是普通结构体。到了真正要做高性能切片的地方再从Memory拿到Span。这个“接口用Memory、计算用Span”的原则在异步TCP服务里非常好用。5.2 边界检查的真相别把Slice的参数算错Span.Slice本身是有边界检查的你传的起始位置加长度如果超出原Span长度会抛ArgumentOutOfRangeException。这意味着它有安全性但不是无条件的。在release模式下JIT会根据上下文中已有的长度信息消除一部分边界检查但如果代码分支太多、分析不过来边界检查依然存在。我在实际项目里踩过一个相关的坑把帧头长度直接写死在Slice的参数里后来协议升级帧头从4字节变成8字节结果所有解析代码的偏移量全错了。排查时因为抛异常的位置不直观花了不少时间。后来我养成了习惯在帧解析入口统一算好字段偏移所有Slice操作都基于变量而不是魔法数字。比如int headerSize 8; int torqueOffset headerSize 2; int torqueSize 4; Spanbyte torqueField frame.Slice(torqueOffset, torqueSize);这样协议一变只需要改定义偏移的地方。别小看这个习惯它救了我后面的多次协议变更。5.3 Native内存的释放顺序与悬挂风险非托管内存用Span包住之后虽然访问方便但有个责任不能丢Span本身不管理生命周期。如果你new Spanbyte(ptr, length)之后把ptr指向的内存释放了再继续用这个Span那就是典型的悬挂引用轻则读到垃圾数据重则程序崩溃。我见过一种比较隐蔽的错误是把非托管内存的释放动作放在异步回调里而调用方还拿着之前创建的Span继续解析。代码在编译期没有那么明显的错误提示运行时的表现也时好时坏非常难排查。我的建议是谨慎使用非托管指针构造Span并且在使用它的方法上明确标记unsafe用方法名和注释强提醒“此Span生命周期仅限于本次调用”。如果这段内存是外部SDK管理的就严格做一个“窗口期”约定Span只在收到回调到回调返回之间有效绝不缓存、绝不跨方法传递。5.4 什么时候别用Span说了这么多好处我还是想泼一点冷水阶段不是万能的也有不该用它的地方。字符串很短复制开销可以忽略比如截取一个两位数的状态码Substring的分配成本微乎其微为了“省一次分配”把代码改得晦涩不值得。需要把结果长期保存Span是栈上的窗口你没法把它存进字段、集合如果数据后续要跨方法跨线程使用老老实实返回string或byte[]。代码可读性优先的场景团队里不是每个人都了解ref struct的约束如果把异步方法改得到处是Span和Memory会让维护成本上升。优化热点路径可以但没必要把整条业务链路都激进改造。归根到底Span是一种武器它的价值体现在“真正被流量打中”的路径上。我在扭矩解析这个场景里动手是因为它每秒调用数千次、分配对象数量多到影响GC如果是一条低频的管理命令解析优先保证代码清晰就好。另外分享一个实践心得做这类优化一定要先测量、后动手。我习惯先用dotnet-counters或者BenchmarkDotNet把热点方法的堆分配量打出来确认分配大头在哪几行再去针对性改造。没有数据支撑的“优化”大部分时候只是在给后续维护埋雷。