FileStream.Write不等于物理连续写入，因操作系统和文件系统仅保证逻辑顺序；预分配文件长度再顺序写入是最接近连续写的方式，但磁盘碎片严重时仍可能失败。
为什么 FileStream 的 Write 不等于“物理连续写入”
你调用 FileStream.Write 写完一串数据，文件在磁盘上大概率还是碎片化的——操作系统和 NTFS（或 exFAT）只保证逻辑顺序，不承诺物理扇区连续。这不是 C# 的问题，是文件系统层的默认行为。真正影响重写连续性的，是写入模式、缓冲控制和底层卷管理。
- 直接覆盖小块旧文件（
FileMode.Open+FileAccess.Write）几乎从不合并碎片，只是原地改数据 - 新建文件再复制（
FileMode.Create）更可能获得连续空间，但取决于当前磁盘空闲区大小和碎片程度 -
FileStream默认启用内核缓冲，实际落盘时机不可控，可能拆成多次小写入
用 FileOptions.NoBuffering 强制对齐写入（但有硬性限制）
这个标志能让 .NET 跳过系统缓存，直接向磁盘提交数据，前提是每次读写都必须按扇区对齐（通常是 512B 或 4KB），且内存地址也需对齐。它不保证连续，但能避免因缓存导致的隐式拆分。
- 只对
FileStream构造时生效，且仅 Windows 支持（Linux/macOS 会忽略） - 缓冲区长度、偏移量、内存地址三者都必须是扇区大小的整数倍，否则抛
IOException - 适合已知目标大小、能预分配内存的大块写入，比如拼接后一次性刷出
byte[]
var buffer = Marshal.AllocHGlobal(4096 * 1024); // 对齐分配
// ... 填充数据 ...
using var fs = new FileStream("out.bin", FileMode.Create, FileAccess.Write,
FileShare.None, 4096, FileOptions.NoBuffering);
fs.Write(buffer, 0, 4096 * 1024); // 长度必须是 4096 倍数真正可控的连续写：先 SetEndOfFile 预分配，再 Seek 填空
Windows API 的 SetEndOfFile（.NET 中通过 FileStream.SetLength 调用）可瞬间扩展文件并预留连续空间——只要磁盘有足够大的空闲簇链。这是最接近“申请连续块”的方式。
-
FileStream.SetLength会触发 NTFS 的“稀疏文件”或“簇预分配”机制，比逐块写快得多 - 预分配后用
fs.Seek(offset, SeekOrigin.Begin)定位，再Write，数据就落在你指定的连续区域里 - 失败时通常报
IOException：“请求的操作无法在使用用户映射区域打开的文件上执行”，说明磁盘碎片太严重，没找到大块空闲空间
别依赖 Defrag 工具，C# 里没法直接调用整理接口
Windows 的 defrag.exe 或 WMI Win32_Volume 的 Defrag 方法需要管理员权限，且是异步全盘操作，不能指定单个文件。C# 没有安全、稳定的 API 让你“立刻把 A.txt 变成连续块”。
- 试图用
MoveFileEx带MOVEFILE_DELAY_UNTIL_REBOOT标志绕过？无效，那是为删除/替换设计的 - 第三方库如
Microsoft.Diagnostics.Tracing也不暴露底层簇映射，查不到文件当前是否连续 - 唯一可靠路径：预分配 + 顺序写入 + 接受“仍可能碎片”的现实——尤其在 SSD 上，物理连续性早已不是性能瓶颈
真正卡住的往往不是“怎么写连续”，而是误以为连续=更快。NTFS 元数据查找速度远高于物理寻道，除非你在做音视频流式写入或嵌入式 FAT32 设备，否则花力气强求连续，不如检查是不是 StreamWriter 自动换行、编码 BOM、或日志轮转策略本身就在制造小文件。
