FileStream写大文件速度慢主因是系统缓存与元数据开销；需启用WriteThrough/NoBuffering、禁用最后访问时间、避免NTFS元数据锁、预分配空间并排除GC干扰才能测出真实磁盘性能。
用 FileStream 写入大文件时为什么速度上不去
默认的 FileStream 同步写入会卡在磁盘 I/O，尤其小块反复写（比如每次 Write 1KB）实际是把 SSD/HDD 当成日志设备在用，吞吐量可能连理论值 10% 都不到。
- 必须显式启用
FileOptions.WriteThrough和FileOptions.NoBuffering（后者要求缓冲区对齐且大小是扇区倍数，通常 4096 字节）才能绕过系统页缓存，测出真实磁盘极限 - 禁用缓存后，
Write调用会真正阻塞到数据落盘，所以要配合Task.Run或异步WriteAsync避免主线程挂死 - Windows 上 NTFS 默认启用了“最后访问时间更新”，每写一次文件都会触发额外元数据修改，加个
SetFileTime禁掉能稳提 5–15% 吞吐
并发写多个文件反而更慢？查查 CreateFile 的 dwFlagsAndAttributes
开 8 个线程各自 new FileStream("test_001.dat", FileMode.Create)，结果总吞吐比单线程还低——大概率是 Windows 默认创建文件时加了 FILE_ATTRIBUTE_NORMAL，导致所有句柄竞争同一个 NTFS 元数据锁。
- 改用
FileOptions.DeleteOnClose+ 临时目录（如%TEMP%），绕过重命名和目录索引更新开销 - 如果必须保留文件，至少加上
FileOptions.SequentialScan告诉内核“我要顺序写”，减少预读干扰 - Linux/macOS 下注意 ext4/xfs 的
chattr +C（写时复制禁用）或xfs_io -c "extsize 1m"预分配，否则碎片会快速拖垮随机写性能
Stopwatch 测出来的时间不准？得扣掉 GC.Collect 和内存映射干扰
跑一轮 10GB 写入，Stopwatch.ElapsedMilliseconds 显示 8200ms，但 perfmon 里看到磁盘队列长度峰值 12——说明有大量时间花在等待上，不是纯写入耗时。
- 测试前手动调用
GC.Collect(GC.MaxGeneration, GCCollectionMode.Forced, blocking: true)，避免测试中途触发 GC 暂停 - 别用
MemoryMappedFile测“纯文件系统”，它走的是虚拟内存路径，受CommitSize和页面错误影响极大，数据根本没进磁盘栈 - 真要测底层，直接用
DeviceIoControl发IOCTL_DISK_PERFORMANCE（需管理员权限），或者用diskspd工具交叉验证
为什么 Directory.CreateDirectory 在压力下频繁抛 IOException
不是权限问题，是 NTFS 目录 B+ 树节点分裂时的短暂排他锁。并发建 100 个子目录，失败率可能超 30%，错误信息通常是 "The directory is not empty" 或 "Access is denied"（实际是锁冲突伪装）。
- 提前批量创建好目录结构，用
Directory.EnumerateDirectories验证存在性，而不是边写边建 - 如果必须动态建，改用
DirectoryInfo.CreateSubdirectory并捕获IOException后退避重试（指数退避，最多 3 次） - 绕过 .NET 封装，P/Invoke
CreateDirectoryW并传SECURITY_ATTRIBUTES避免 ACL 初始化开销
文件系统压力测试真正的难点不在“怎么写快”，而在“怎么让操作系统不偷偷帮你优化、缓存、合并、延迟提交”——一旦漏掉某个标志位或环境配置，测出来的数字就只是内存带宽，不是磁盘能力。
