BufferedStream 不提升单次IO效率，仅减少系统调用次数；小数据量时因额外开销反而更慢，大块顺序读写且缓冲区合理（如64KB）才有收益，必须Flush/Dispose确保落盘，多数场景应优先选用StreamReader等高层封装。
BufferedStream 本身不提升单次 IO 效率，它只减少系统调用次数；盲目套用反而可能降低小数据量场景的性能。
为什么 BufferedStream 有时比直接 FileStream 还慢
每次 Read() 或 Write() 调用 BufferedStream，它内部会先检查缓冲区是否够用——不够就触发一次底层 FileStream.Read() 系统调用，把一批数据拉进内存缓冲区（默认 8192 字节）。如果每次只读 1 字节，它仍得反复填缓冲区、取字节、再填……实际系统调用次数没降，还多了一层内存拷贝和边界判断开销。
- 小块随机读写（如逐字符解析）：优先用
StreamReader/StreamWriter，它们自带缓冲且针对文本做了优化 - 大块顺序读写（如复制文件）：
BufferedStream才有收益，但要注意缓冲区大小是否匹配硬件扇区或网络 MSS - 已开启操作系统级缓存（如 NTFS 的 cache manager）时，.NET 层缓冲可能冗余
BufferedStream 的缓冲区大小怎么设才合理
构造函数第二个参数是缓冲区大小，不是越大越好。设为 0 会退化为无缓冲；设得太大会浪费内存且增加 GC 压力；设得太小则频繁换页。
- 磁盘顺序读写：4KB–64KB 是常见选择，
new BufferedStream(fs, 65536)能较好对齐 NTFS 簇和 SSD 页大小 - 网络流（如
NetworkStream）：建议匹配 MTU 或 TCP MSS（通常 1448–8192），避免拆包 - 不确定场景：保持默认 8192，比瞎调更稳妥
必须配合 Flush() 和 Dispose() 才能保证数据落盘
BufferedStream 的写操作默认只写到内存缓冲区，不立刻发到底层流。如果只调 Write() 就结束，最后几 KB 数据可能永远卡在缓冲区里。
- 写入中途需要确保数据已提交（如日志实时刷盘）：显式调
Flush() - 写入完成必须释放资源：用
using包裹，或手动调Dispose()—— 它会自动Flush()并关闭底层流（除非构造时传leaveOpen: true） - 错误示例：
var bs = new BufferedStream(fs); bs.Write(data); // 忘了 Flush/Dispose → 数据丢失
替代方案比 BufferStream 更常用
绝大多数业务场景，直接用更高层封装更安全、更高效：
- 文本处理：用
StreamReader/StreamWriter，它们内部用了BufferedStream但还处理了编码、换行符、BOM 等细节 - 二进制序列化：用
BinaryReader/BinaryWriter，缓冲逻辑已内建，且类型读写更精准 - 大文件复制：用
Stream.CopyTo()（.NET 4.0+），它内部做了缓冲块大小自适应，比手写BufferedStream+ 循环更可靠
真正需要 BufferedStream 的情况其实很少：比如你正在封装一个通用流代理、要插在两个自定义流中间做透明缓冲，或者调试底层 IO 行为。其他时候，它只是个容易用错的“高级开关”。
