FileStream.Read(Span) 更快因其零拷贝特性，跳过内核缓冲区到托管堆的冗余复制，且Span为栈上视图、无GC压力；需.NET Core 2.1+，禁跨await使用，小固定尺寸优先用stackalloc+Span，大或复用场景选Memory+ArrayPool。
为什么 FileStream.Read(Span) 比 ReadByte() 或 byte[] 更快
因为 FileStream.Read(Span<byte>)</byte> 直接把磁盘数据写入你提供的内存切片，不额外分配数组、不复制缓冲区。而 ReadByte() 每次只读 1 字节，调用开销大；Read(byte[], ...) 又必须提前分配 byte[]，哪怕你只处理其中一部分。
关键点在于：零拷贝 ≠ 不复制数据，而是跳过「内核缓冲区 → 托管堆数组」这层冗余拷贝。Span 是栈上视图，生命周期由调用方控制，运行时能做边界检查但不触发 GC。
- 必须用 .NET Core 2.1+ 或 .NET 5+，.NET Framework 不支持
FileStream.Read(Span<byte>)</byte> - 不要在异步方法里把
Span<byte></byte>存到字段或跨 await 边界传递 —— 它不能逃逸到堆，否则编译直接报错Cannot use local 'span' in this context because it would escape the method body - 同步读取场景下，
Span<byte></byte>和ReadOnlySpan<byte></byte>性能几乎无差别；但如果你只解析不修改（比如解析 PNG 头），优先用ReadOnlySpan<byte></byte>，语义更安全
如何安全地用 ReadOnlySpan 解析文件头而不分配内存
常见需求：读前 8 字节判断文件类型（如 ELF 的 \x7fELF、PNG 的 \x89PNG\r\n\x1a\n）。用 ReadOnlySpan<byte></byte> 能避免 new byte[8]，且编译器会做越界检查。
实操时注意：FileStream 必须打开为 FileAccess.Read，且位置可 seek；如果文件是只读流（如网络响应流），得先确认它是否支持 CanSeek。
- 用
stream.Position = 0回到开头，再调用stream.Read(buffer)，其中buffer是栈分配的stackalloc byte[8]或长度为 8 的Span<byte></byte> - 别直接对
ReadOnlySpan<byte></byte>调用ToArray()—— 那就白做了，立刻触发堆分配 - 比较字节时用
MemoryExtensions.SequenceEqual()（需 using System.Memory），比手写 for 循环更安全，且 JIT 会优化成 memcmp
var header = stackalloc byte[8];
stream.Read(header);
if (header.StartsWith(new byte[] { 0x89, 0x50, 0x4e, 0x47 })) {
// 是 PNG
}
Span 和 Memory 在文件读取中的分工
Span<byte></byte> 是栈/寄存器驻留的轻量视图，适合短生命周期操作（如单次解析）；Memory<byte></byte> 是它的“堆友好”兄弟，能跨 await、存字段、传回调 —— 但代价是可能触发 GC。
典型误用：想反复读一个大文件的多个块，却每次用 stackalloc byte[4096]。栈空间有限，大 buffer 容易栈溢出；此时该用 Memory<byte></byte> + ArrayPool<byte>.Shared.Rent()</byte>。
- 小固定尺寸（≤ 1KB）、单次使用 →
Span<byte></byte>+stackalloc - 需要复用、异步等待、或尺寸不确定 →
Memory<byte></byte>，配合ArrayPool<byte>.Shared.Rent(size)</byte>租借，用完.Return() -
FileStream.ReadAsync(Memory<byte>)</byte>是 .NET 5+ 原生支持的，不用自己包装Task.Run模拟
容易被忽略的兼容性坑：Linux vs Windows 文件句柄与 Span
在 Linux 上用 FileStream 包装 SafeFileHandle（比如通过 System.IO.File.OpenHandle）时，某些低层 I/O 操作（如 Read）可能不完全适配 Span 路径，尤其在启用 FileOptions.Asynchronous 时。
现象：程序在 Windows 正常，Linux 上抛 NotSupportedException: Memory-mapped files are not supported on this platform —— 即使你没用内存映射。根源是底层 PAL 层对 Span 支持有延迟。
- 生产环境若需跨平台，建议统一用
Memory<byte></byte>替代Span<byte></byte>做异步读取，兼容性更好 - 调试时用
RuntimeInformation.IsOSPlatform(OSPlatform.Linux)判断，必要时降级到byte[]分支 - 别依赖
Span<byte></byte>的“绝对零开销”——JIT 优化程度和 OS 底层实现都会影响实际表现，压测比理论更重要
