FileStream 的 BufferSize 参数仅控制内部缓冲区大小，无法支持零拷贝、内存复用或底层I/O直通等精细控制需求。
为什么 FileStream 的 BufferSize 参数不能解决所有缓冲问题
因为 FileStream 构造时传入的 BufferSize 仅控制其内部读写缓冲区大小（默认 4096），它不暴露底层缓冲区地址，也不允许你复用或直接操作该缓冲区。当你需要精细控制——比如避免重复内存分配、对接非托管 I/O、或实现零拷贝解析时，这个参数就完全不够用了。
常见错误现象：FileStream.Read(buffer, 0, buffer.Length) 看似在“手动用缓冲区”，其实只是把数据从 FileStream 内部缓冲再拷贝一次到你的 buffer，中间多了一次 memcpy。
- 真正手动管理缓冲区 = 绕过
FileStream默认缓冲逻辑，直接调用ReadFile/WriteFile（Windows）或read/write（Unix），并自己维护缓冲区生命周期 - 若仍想用托管 API，
Span<byte></byte>+MemoryStream或Pipe是更可控的替代路径，但它们不等于“手动管理文件缓冲区” -
FileStream的WriteAsync在 .NET 6+ 默认启用 I/O completion port 缓冲优化，此时你传入的byte[]可能被池化复用——但这由运行时控制，不可干预
用 SafeFileHandle + NativeOverlapped 实现真正的缓冲区直通（Windows）
这是最接近 C/C++ 中 FILE* + 自定义 setvbuf 的方式，适用于高性能日志、实时音视频流等场景。核心是跳过 FileStream，用 Kernel32.ReadFile 直接读入你预分配的 byte[]，且该数组需固定（GCHandle.Alloc(..., GCHandleType.Pinned)）。
示例关键步骤：
- 用
CreateFile获取SafeFileHandle，注意传入FILE_FLAG_NO_BUFFERING（此时要求缓冲区地址和大小均按磁盘扇区对齐，通常 512 或 4096 字节） - 分配缓冲区：
byte[] buf = new byte[4096];→GCHandle h = GCHandle.Alloc(buf, GCHandleType.Pinned);→h.AddrOfPinnedObject()得到指针 - 调用
ReadFile时传入该指针和长度，返回后需检查lpNumberOfBytesRead，不能依赖返回值判断成功（异步模式下常返回 false，靠GetOverlappedResult） - 用完后必须调用
h.Free()，否则内存泄漏
.NET 6+ 的 Pipe 和 ReadOnlySequence<byte></byte> 是更安全的手动缓冲替代方案
如果你的真实需求是“减少 GC 压力”或“流式解析大文件而不全加载”，Pipe 比裸 Win32 调用更推荐——它内部使用 MemoryPool<byte>.Shared</byte> 管理缓冲区，支持租借/归还，且天然适配异步管道模型。
典型用法：
- 创建
Pipe时指定PipeOptions，如new PipeOptions(pool: MemoryPool<byte>.Shared, minimumSegmentSize: 8192)</byte> - 用
pipe.Writer.AsStream()包装FileStream，或直接await pipe.Reader.ReadAsync()获取ReadOnlySequence<byte></byte> - 解析时用
sequence.Slice(start, length)避免复制，用sequence.CopyTo(buffer)显式触发拷贝（仅当必须写入固定数组时） - 注意：每次
ReadAsync后必须调用reader.AdvanceTo(consumed, examined)，否则缓冲区不会释放
容易被忽略的关键约束
手动管理缓冲区不是加个 byte[] 就行的事，以下限制实际项目中常导致数据错乱或崩溃：
-
FILE_FLAG_NO_BUFFERING要求：缓冲区地址必须页对齐（Marshal.AllocHGlobal或NativeMemory.AlignedAlloc），大小必须是扇区大小整数倍，文件偏移也必须对齐——错一个就ERROR_INVALID_PARAMETER - Linux 下对应的是
O_DIRECT，但 .NET 运行时未公开封装，需用Interop.Sys.Read+NativeMemory，且 glibc 版本和内核需支持 - 即使不用无缓冲 I/O，只要用了
Span<byte></byte>或Memory<byte></byte>，就要警惕跨 async 方法传递——async方法可能被挂起，而Span不能逃逸栈帧 -
FileStream的LeaveOpen参数只影响流关闭行为，对缓冲区无任何影响；别指望它帮你“保留缓冲区状态”
