WriteFile需手动扇区对齐，因NTFS以4096字节扇区组织I/O；非对齐写入触发读-改-写，降低性能；启用FILE_FLAG_NO_BUFFERING时要求缓冲区地址、偏移量、长度均4096对齐且内存页对齐，否则失败。
WriteFile 时为什么需要手动处理扇区对齐
Windows 文件系统（NTFS）底层以扇区为单位组织磁盘 I/O，常见物理扇区大小是 4096 字节（4K），而 .NET 的 FileStream.Write 默认不保证写入起始位置或长度与扇区边界对齐。一旦写入偏移量不是 4096 的整数倍，或写入长度不能被 4096 整除，系统可能触发“读-改-写”（read-modify-write）流程——先读取整个扇区，修改其中部分字节，再写回。这会显著拖慢顺序写入，尤其在 SSD 或高 IOPS 场景下更明显。
这不是 .NET 的 bug，而是 Win32 层面的 I/O 行为；FileStream 默认走缓存路径（FILE_FLAG_SEQUENTIAL_SCAN 等标志不生效），无法绕过系统页缓存对齐约束。
- 典型错误现象：
WriteFile返回成功，但性能监控显示大量非对齐 I/O（PerfMon 中PhysicalDiskSplit IO/Sec高企） - 适用场景：日志批量刷盘、二进制序列化导出、内存映射文件预填充等对吞吐敏感的写入
- 关键前提：目标磁盘必须支持查询对齐信息——调用
DeviceIoControl获取IOCTL_STORAGE_QUERY_PROPERTY，确认AlignmentMask值（通常为4095，即对齐粒度4096）
C# 中绕过 FileStream 缓存直写对齐数据
要真正控制对齐，必须跳过 FileStream 的缓冲层，使用 Win32 CreateFile + WriteFile，并传入 FILE_FLAG_NO_BUFFERING 标志。该标志强制要求：所有写入地址必须是扇区对齐的，且长度必须是扇区大小的整数倍——否则 WriteFile 直接返回 false，GetLastError() 返回 ERROR_INVALID_PARAMETER。
- 缓冲区必须页对齐（
VirtualAlloc分配，不可用普通byte[]）：因为FILE_FLAG_NO_BUFFERING要求内核直接 DMA，内存地址需满足硬件访问约束 - 写入偏移量必须是扇区大小的整数倍：例如用
SetFilePointerEx将文件指针移到4096 * N处 - 每次写入长度必须是扇区大小的整数倍：若原始数据长
12345字节，需补零到12800（4096 * 3 = 12288不够，得上取整到4096 * 4 = 16384） - 示例关键检查逻辑：
if ((long)bufferPtr % 4096 != 0 || writeSize % 4096 != 0) { throw new InvalidOperationException("Buffer address or size not sector-aligned"); }
FILE_FLAG_NO_BUFFERING 的代价和兼容性陷阱
启用 FILE_FLAG_NO_BUFFERING 后，你失去操作系统缓存带来的预读、延迟写、合并小写等优化，所有 I/O 都变成真实磁盘操作。这意味着：单次小写入（如写 4096 字节）的延迟会升高，但连续大块写入的吞吐反而更稳定——前提是你的数据本身已对齐且足够大。
- 不兼容网络路径（UNC）：尝试对
\servershare ile.bin使用该标志会直接失败，GetLastError()返回ERROR_NOT_SUPPORTED - NTFS 压缩/加密属性失效：带
FILE_ATTRIBUTE_COMPRESSED或ENCRYPTED的文件无法用此标志打开 - 必须关闭句柄前显式刷新：即使写入完成，也要调用
FlushFileBuffers，否则数据可能滞留在磁盘控制器缓存中（尤其 RAID 卡） - 不要混用缓存与非缓存 I/O：同一个文件句柄不能先用
FileStream写一段，再用WriteFile接着写——元数据状态不同步，易引发数据损坏
实际项目中更可行的折中方案
纯 FILE_FLAG_NO_BUFFERING 在多数业务代码里过于沉重。更现实的做法是：保持 FileStream，但通过预分配 + 对齐写入策略降低非对齐概率。比如日志文件按 4096 对齐切片，每条日志记录头预留 8 字节对齐填充字段，写入前用 Seek 跳到下一个 4096 边界——这样既避免 Win32 P/Invoke 复杂性，又压制了大部分 split IO。
真正的难点不在代码怎么写，而在于你怎么确认对齐生效：别只看自己写的逻辑，用 Windows Performance Recorder (WPR) 录制磁盘 I/O，过滤 Microsoft-Windows-Storage ETW 事件，查 IO_READ/IO_WRITE 的 Offset 和 Size 字段是否都是 4096 的倍数。没验证过对齐，就等于没对齐。
