FileStream默认缓冲区大小是4096字节，仅适合小文件读写；大文件或高吞吐场景应设为64KB–256KB，需配合异步选项、正确释放及数据模式匹配。
FileStream 默认缓冲区大小是多少？为什么不能直接用默认值
默认是 4096 字节（4KB），但这个值只对“典型小文件读写”友好。实际中，如果你在做日志追加、大文件复制或网络流中转，4096 会频繁触发系统调用，成为瓶颈。Windows 上一次 ReadFile 或 WriteFile 调用的开销远高于内存拷贝，缓冲区太小 = 操作系统跑腿次数太多。
实操建议：
- 批量处理 >1MB 的文件时，把缓冲区设为
65536（64KB）或131072（128KB）更稳； - SSD 或高速 NVMe 上，可试
262144（256KB），但别盲目往上堆——超过系统页大小（通常 4KB）太多，反而增加 GC 压力； - 不要设成
0（禁用缓冲），那等于裸调Read/Write，性能断崖式下跌。
如何安全地设置 FileStream 缓冲区大小
关键不是“能不能设”，而是“在哪设、谁负责释放”。最常见错误是：手动 new FileStream 时传了缓冲区大小，却忘了用 using 包裹，导致句柄泄漏；或者在异步场景下误用同步构造函数。
实操建议：
- 优先用带
bufferSize参数的构造函数：new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.Read, bufferSize: 65536)； - 异步操作必须配
FileOptions.Asynchronous，否则即使传了大缓冲区，ReadAsync仍可能退化为同步 I/O； - 避免在
MemoryStream或加密流（如CryptoStream）上游直接套大缓冲FileStream——中间层可能切碎数据，让大缓冲失效。
Buffer size 和 CopyTo 性能的关系
CopyTo 方法内部其实会创建一个临时缓冲区，默认也是 81920（80KB），但它**不复用**你传给 FileStream 的缓冲区。也就是说，你给 FileStream 设了 131072，CopyTo 还是按自己的节奏搬数据。
实操建议：
- 要最大化
CopyTo效率，直接传自定义缓冲区：source.CopyTo(destination, bufferSize: 262144)； - 如果源/目标都是
FileStream，且都支持Span<byte></byte>（.NET 5+），改用CopyToAsync+MemoryPool<byte>.Shared.Rent()</byte>手动管理缓冲区，吞吐能再提 10%–15%； - 别在
CopyTo后立刻Flush()——它本身已保证数据落盘，多此一举反而阻塞线程。
哪些场景反而该用小缓冲区
不是所有情况都要“越大越好”。比如实时日志采集、串口通信模拟、或需要低延迟响应的传感器数据流，大缓冲会引入不可控延迟——数据卡在缓冲区里没及时写出，监控就断档。
实操建议：
- 日志类写入（尤其带时间戳的单行记录），用
4096甚至1024更合适； - 配合
AutoFlush = true使用小缓冲时，注意每写一次就触发一次磁盘 I/O，适合小流量、高确定性场景； - 调试时若发现
FileStream.Write返回字节数小于预期，先检查是否缓冲区溢出被截断——小缓冲 + 大数据块容易静默丢数据。
缓冲区不是调参游戏，它和你的数据模式、硬件路径、I/O 模式绑在一起。设错一个值，可能让吞吐掉一半，也可能让延迟毛刺翻倍。真正难的不是知道该设多少，而是想清楚“我这次读写的节奏和边界在哪里”。
