缓冲流通过减少系统调用提升吞吐量，但仅在大数据量、顺序读写、合理缓冲区及正确释放时有效；小数据或随机访问反降性能；需按场景调优缓冲区大小并显式Flush/Dispose。
缓冲流本身不加快单次读写速度，它通过减少系统调用次数来提升整体吞吐量。真正起效的前提是：数据量大、访问模式为顺序读写、缓冲区大小合理，且资源释放到位。
只在合适场景下启用缓冲
小数据量或随机访问时加 Buffer 反而更慢——比如逐字节解析日志、频繁 seek 定位、每次只读 1–10 字节。此时系统调用没减少，还多出缓冲管理开销。真正受益的场景是：
- 大文件顺序复制（如备份、归档）
- 批量导入导出二进制数据（如图片流、音频帧）
- 底层流本身无缓冲（如 NetworkStream、PipeStream）且需稳定吞吐
设对缓冲区大小比“加不加”更重要
默认 8192 字节（8KB）够用，但不是最优。关键看目标设备和访问方式：
- 磁盘顺序读写：推荐 64KB（65536），能较好对齐 NTFS 簇、SSD 页、RAID 条带
- 网络传输：匹配 MSS（常见 1448 或 4096），避免 TCP 分段
- 内存受限环境：可降至 4KB，避免 GC 压力
- 不确定时，别盲目调大；超过 128KB 收益递减，还可能拖慢响应
必须显式处理落盘与释放
BufferedStream 的写操作默认只写到内存缓冲区。若不 Flush 或 Dispose，末尾数据会丢失：
- 实时性要求高（如日志）：每条关键记录后调 Flush()
- 写入完成时：用 using 包裹，或手动调 Dispose()（它会自动 Flush 并关闭底层流，除非构造时指定 leaveOpen: true）
- 错误示范：
var bs = new BufferedStream(fs); bs.Write(data); // 缺少 Flush/Dispose → 数据静默丢失
多数时候，直接用更高层封装更省心
业务代码中，很少需要手写 BufferedStream。.NET 已提供语义更清晰、默认已优化的替代方案：
- 文本处理：用 StreamReader / StreamWriter（自带缓冲 + 编码处理 + BOM 支持）
- 二进制序列化：用 BinaryReader / BinaryWriter（类型安全 + 内置缓冲）
- 文件复制：用 Stream.CopyTo()（.NET 4.0+，自动适配块大小，比手写循环更稳）
