File.Copy()默认8KB缓冲区导致小文件批量复制IO放大，应改用FileStream自定义64KB/128KB缓冲区；SSD/NVMe上禁用WriteThrough避免写放大；Directory.GetFiles+ReadAllText触发三次IO，建议EnumerateFiles+ReadAllBytes；MemoryMappedFile需DelayAllocatePages防预读压力。
File.Copy() 默认缓冲区太小，小文件批量复制时IO放大明显
默认用 File.Copy() 复制大量小文件（比如单个几十KB的日志碎片），实际磁盘读写量可能翻倍甚至更高。它内部用 8KB 缓冲区，频繁触发系统调用和磁盘寻道，尤其在机械盘或高延迟存储上更明显。
实操建议：
- 改用
FileStream手动控制缓冲区，设为 64KB 或 128KB（new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.Read, 65536)） - 对同一目标目录的连续写入，考虑先用
FileOptions.WriteThrough | FileOptions.SequentialScan标志绕过系统缓存干扰测试 - 避免在循环里反复
File.Copy(src, dst)—— 每次都打开/关闭句柄，叠加元数据操作开销
FileStream 构造时没关 WriteThrough，SSD/NVMe 上反而写放大
在 SSD 或 NVMe 上，开启 FileOptions.WriteThrough 会跳过内核页缓存，强制落盘，看似“安全”，实则让原本可合并的随机小写变成多次独立闪存页编程，触发额外磨损和 GC 开销。
常见错误现象：监控看到 WriteFile 调用次数远高于预期，diskio\write bytes/sec 数值波动剧烈但吞吐不高。
实操建议：
- 除非明确需要强持久性（如 WAL 日志），否则不要加
WriteThrough - 写密集场景优先用
FileOptions.None+fs.Flush(false)控制刷盘时机 - 注意
FileStream构造时第三个参数是FileAccess，第四个才是FileShare，错位会导致UnauthorizedAccessException
Directory.GetFiles() + 循环 File.ReadAllText() 触发三次IO放大
典型反模式：var files = Directory.GetFiles("logs", "*.txt"); foreach (var f in files) { var s = File.ReadAllText(f); ... } —— 这段代码每文件至少触发 3 次磁盘访问：一次查目录项、一次读文件长度（为了分配字符串缓冲区）、一次真正读内容。
使用场景：日志聚合、配置扫描等需遍历并读取全部内容的批量任务。
实操建议：
- 改用
Directory.EnumerateFiles()避免一次性加载全路径数组（内存友好，也减少初始目录扫描延迟） - 对已知小文本文件，用
File.ReadAllBytes()+Encoding.UTF8.GetString()省掉一次长度探测 - 如果只是检查文件存在或大小，用
new FileInfo(path).Length比File.ReadAllBytes()便宜得多
MemoryMappedFile 在非共享场景下徒增IO压力
有人以为用 MemoryMappedFile 读大文件就能“零拷贝”，但若只是单进程顺序读，且没设置 MemoryMappedFileOptions.DelayAllocatePages，Windows 会预提交所有页，导致一打开就触发大量磁盘读+页面文件分配。
性能影响：首次访问延迟飙升，任务管理器里看到 System 进程 CPU 占用异常高（页面归零线程在忙）。
实操建议：
- 纯读场景优先用
FileStream+BufferedStream（4MB 缓冲足够覆盖多数顺序读） - 真要用内存映射，必须加
MemoryMappedFileOptions.DelayAllocatePages，且只在需要随机跳读或跨进程共享时才值得引入 -
CreateFromFile()默认不延迟分配；必须显式传参：MemoryMappedFile.CreateFromFile(file, FileMode.Open, null, 0, MemoryMappedFileOptions.DelayAllocatePages)
真正容易被忽略的是：IO放大往往不是某一行代码的问题，而是缓冲区策略、句柄生命周期、系统缓存行为三者叠加的结果。调 perfmon 看 PhysicalDisk\Avg. Disk sec/Read 和 Process\IO Data Bytes/sec 的比值，比看代码更容易定位放大源头。
