最轻量通用的大文件预分配方式是 os.create + file.truncate，它仅修改元数据、不写零、不占物理磁盘，适用于日志/队列/归档等99%场景。
直接用 os.Create + File.Truncate 是最轻量、最通用的大文件预分配方式，它不写零、不占物理磁盘，只改元数据——99% 的日志/队列/归档场景都该这么干。
为什么不用循环写零来“填满”文件
手动循环写入零字节（比如用 io.Copy 向文件写 bytes.Repeat([]byte{0}, size)）看似“实在”，实则严重拖慢初始化速度，还提前耗尽磁盘空间。现代文件系统（ext4、XFS、NTFS）原生支持稀疏文件，Truncate 扩展文件时新增区域逻辑上就是零，读取即得 0x00，但不会立刻分配物理块。
- 10GB 文件用
Truncate耗时 ≈ 0.01ms；用零填充写入 ≈ 数秒甚至分钟（取决于磁盘带宽） - 稀疏文件在
ls -lh中显示为“逻辑大小”，du -h显示为实际占用，两者可差几个数量级 - 某些场景（如容器镜像层、数据库 WAL 预分配）明确要求避免写零，否则触发不必要的 SSD 写放大
os.Create 和 os.OpenFile 的关键区别
别只记 os.Create —— 它等价于 os.OpenFile(name, os.O_CREATE|os.O_WRONLY|os.O_TRUNC, 0666)，会无条件清空已有文件。如果你需要“存在则跳过，不存在才创建”，必须用 os.OpenFile 显式控制 flag：
- 要覆盖并预分配：用
os.Create或os.OpenFile(name, os.O_CREATE|os.O_WRONLY|os.O_TRUNC, 0666) - 要仅新建、失败不覆盖：用
os.OpenFile(name, os.O_CREATE|os.O_EXCL|os.O_WRONLY, 0666)，否则并发调用可能相互覆盖 - 要追加但也要预分配（比如日志轮转后预留空间）：先
os.OpenFile(...os.O_APPEND...)，再f.Truncate—— 注意Truncate不影响当前写位置，需f.Seek(0, io.SeekEnd)手动定位
Truncate 后文件是否真的“可用”
是的，但有边界条件。刚 Truncate 出来的区域是稀疏页，首次写入任意偏移都会触发按页（通常 4KB）分配物理块。但读取未写过的区域，会稳定返回零 —— 这是内核保证的语义，无需担心“读到垃圾值”。
- 若业务要求“物理空间必须立即就位”（例如某些安全审计或存储配额系统），需额外调用
syscall.Fallocate（Linux）或SetFileValidData（Windows），Go 标准库不封装，得走golang.org/x/sys/unix - SSD 上稀疏文件不会影响后续顺序写性能；但机械盘上，如果后续写入高度随机，碎片化可能略增 —— 不过比起实时扩展文件，仍强得多
-
Truncate失败常见原因是磁盘满或权限不足，错误信息是"no space left on device"或"permission denied"，不是 “invalid argument”
真正容易被忽略的是：预分配解决的是“扩容抖动”，不是“写入吞吐”。如果预分配后写入仍慢，问题大概率出在没加 bufio.Writer、缓冲区太小，或者单 goroutine 塞满了磁盘带宽 —— 别盯着 Truncate 本身优化。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
