span不能直接用于file.readallbytes/writeallbytes，需改用filestream配合stackalloc或arraypool实现零分配；读小文件可用栈缓冲区，大文件应选memory+异步流。
Span 不能直接传给 File.ReadAllBytes 或 File.WriteAllBytes
这两个静态方法返回的是新分配的 byte[]，不接受 Span<byte></byte> 作为参数。想用 Span<byte></byte> 减少内存分配，必须绕过这些高层封装，改用流式 API（如 FileStream）并配合栈上缓冲区或池化内存。
用栈上缓冲区 + FileStream.Read(Span) 读小文件
对几 KB 到几 MB 的文件，可直接在栈上分配固定大小的 Span<byte></byte>，避免堆分配。注意：栈空间有限（默认约 1MB），单次分配别超 85KB（.NET 栈帧安全阈值）。
-
Span<byte></byte>必须由stackalloc byte[N]或ArrayPool<byte>.Shared.Rent()</byte>提供，不能是new byte[N]转成的 —— 后者仍是托管堆对象，失去零分配意义 -
FileStream.Read(Span<byte>)</byte>是同步阻塞调用，适合 I/O 不频繁或可控场景；若需高并发，应搭配Memory<byte></byte>和FileStream.ReadAsync(Memory<byte>)</byte> - 务必检查返回值：它表示实际读取字节数，可能小于缓冲区长度（尤其文件末尾或网络流）
var buffer = stackalloc byte[4096];
using var fs = new FileStream("data.bin", FileMode.Open, FileAccess.Read, FileShare.Read, 4096, FileOptions.None);
int total = 0;
int read;
while ((read = fs.Read(buffer)) > 0) {
ProcessChunk(buffer.Slice(0, read)); // 处理当前块
total += read;
}
写文件时避免 new byte[]：用 ArrayPool + FileStream.Write(ReadOnlySpan)
反复写入大量小数据块（如日志、序列化片段）时，用 ArrayPool<byte>.Shared.Rent()</byte> 租借缓冲区，写完立即归还，比每次 new byte[N] 更省 GC 压力。
-
FileStream.Write(ReadOnlySpan<byte>)</byte>接收栈/池内内存，不触发额外拷贝；但注意：该方法不保证原子写入，多线程写同一文件需自行加锁 - 租借的数组大小建议按常见写入块对齐（如 4KB、64KB），避免频繁 Rent/Return 小碎片
- 忘记
Return()会导致池耗尽，后续 Rent 可能退化为 new —— 必须用try/finally或using（配合IDisposable包装器）确保归还
var pool = ArrayPool<byte>.Shared;
var buffer = pool.Rent(8192);
try {
int len = SerializeToBuffer(data, buffer);
using var fs = new FileStream("out.bin", FileMode.Append, FileAccess.Write, FileShare.None, 4096, FileOptions.None);
fs.Write(buffer, 0, len); // 或 fs.Write(buffer.AsSpan(0, len))
} finally {
pool.Return(buffer);
}
大文件处理：Memory + 异步流才是 Span 的延伸战场
Span<byte></byte> 本身不能跨 await 边界（因栈内存生命周期受限），但 Memory<byte></byte> 可以 —— 它是 Span<byte></byte> 的“可持有”兄弟，背后可指向池数组。这才是真正兼顾零分配与异步 I/O 的组合。
-
FileStream.ReadAsync(Memory<byte>)</byte>和WriteAsync(ReadOnlyMemory<byte>)</byte>是现代推荐路径，尤其在 ASP.NET Core 中处理上传/下载 - 不要把
Memory<byte></byte>当作万能胶水：若底层是ArrayPool租借的，仍需显式 Return；若来自Encoding.UTF8.GetBytes(string)，则仍是堆分配，没节省 - 第三方库（如
System.IO.Pipelines）内部深度使用Memory<byte></byte>和IBufferWriter<byte></byte>，比手写缓冲循环更健壮，适合协议解析等复杂场景
new byte[] 出现在热路径里，才值得动用栈分配或池化 —— 否则只是过早优化。真正的难点是生命周期管理：栈内存不能逃逸，池内存不能泄露，异步上下文里还得选对 Memory 而非 Span。
