os.file.writeat 是并发写入大文件的正确起点，因其调用 pwrite64(2) 绕过内核文件偏移量锁，但需手动精确管理互不重叠的字节范围、预分配空间、共享同一 *os.file 实例，并校验返回值与最终文件大小。
os.File.WriteAt 是并发写入大文件的正确起点
直接用 os.File.Write 多 goroutine 写同一文件，必然出现数据错乱或性能断崖——这不是 Go 的 bug，而是 Linux 内核对非 O_APPEND 文件写入的串行化约束（lseek + write 共享 fd 偏移量锁）。而 os.File.WriteAt 绕过了这个锁，因为它底层调用的是 pwrite64(2) 系统调用，不依赖当前文件偏移量，只认你传入的 off int64 参数。
但注意：WriteAt 不是万能银弹。它要求你**自己精确管理每个 goroutine 要写的字节范围**，且必须确保各段互不重叠、覆盖完整文件。典型场景是分块下载器、WAL 日志批量刷盘、或预分配后填充的大文件生成。
- 必须提前用
os.Truncate或os.WriteAt预占空间（如f.WriteAt([]byte{0}, size-1)），否则部分系统（如 ext4）可能产生稀疏文件，读取时返回零值 - 所有 goroutine 必须共享同一个
*os.File实例，不能各自OpenFile，否则无法保证原子性写入同一物理文件 -
WriteAt返回的n int是实际写入字节数，需校验是否等于预期长度，否则说明磁盘满或权限不足
为什么不能用 bufio.Writer + O_APPEND 替代 WriteAt
如果目标是「追加写」（如日志聚合），O_APPEND 确实更轻量：内核保证每次 write(2) 原子更新偏移量，无需用户态协调。但它的语义是「总在末尾追加」，无法实现「写入指定位置」——这正是大文件分片并行写入的核心需求。
常见误用是打开文件时加了 os.O_APPEND，又试图用 WriteAt 写中间位置，结果被忽略或报 ESPIPE 错误。二者互斥：
-
O_APPEND→ 只能用Write，适合日志、指标流等天然有序追加场景 - 无
O_APPEND→ 必须用WriteAt，适合分块下载、内存映射替代、预分配填充等需要随机定位的场景 - 别混用：
os.OpenFile(path, os.O_WRONLY|os.O_CREATE|os.O_APPEND, 0644)后调WriteAt会失败
分块写入时如何安全计算和传递偏移量
偏移量不是靠 f.Seek(0, io.SeekCurrent) 动态读取的——那在并发下毫无意义，因为其他 goroutine 可能刚写完一截，你的 Seek 结果立刻过期。必须由主协程预先划分好区间，通过参数或 channel 显式传递。
例如下载一个 100MB 文件，开 4 个 goroutine：
chunkSize := (fileSize + int64(workers) - 1) / int64(workers)
for i := 0; i fileSize {
end = fileSize
}
go downloadChunk(url, f, start, end-start)
}
关键点：
- 用整除向上取整避免最后一块过小：
(fileSize + n - 1) / n -
end - start是本次要写的字节数，不是绝对偏移；WriteAt的off参数必须是start - 若某块下载失败，重试时仍用相同
start，不会覆盖其他块
WriteAt 的错误处理和完成校验不能省略
WriteAt 成功只代表系统调用没出错，不代表数据已落盘或文件完整。尤其在断电、进程崩溃时，未 Sync() 的写入可能丢失。
推荐做法：
- 每块写完检查
n == expectedLen，否则记录错误并退出（不要静默跳过） - 全部 goroutine 完成后，调用
f.Sync()强制刷盘，确保所有块持久化 - 最终用
os.Stat校验文件大小是否等于预期fileSize，这是最廉价的完整性兜底 - 若业务要求更高（如下载器），应在写入前计算每块哈希，写完后比对；不要依赖
WriteAt自带校验——它没有
最容易被忽略的是预分配环节：没 Truncate 就直接 WriteAt 超出当前文件大小的位置，在某些文件系统上会静默失败或创建稀疏区域。务必先 f.Truncate(fileSize) 或至少确认文件已存在且足够大。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
