f.truncate(size)是go中创建稀疏文件最快最轻量的方式，仅更新元数据、不写入数据，在ext4/xfs/ntfs/apfs等文件系统上自动生成空洞，毫秒级完成百gb文件创建，避免循环写零的性能与空间开销。
用 Truncate 创建稀疏文件是最快方式
直接调用 f.Truncate(size) 是 Go 中创建大空洞文件（即逻辑大小远大于物理占用）最轻量、最通用的做法。它不写入任何实际字节，只更新文件元数据，内核在支持稀疏语义的文件系统（ext4、XFS、NTFS、APFS）上会自动标记扩展区域为“未分配”，形成稀疏文件。
常见错误现象：手动循环写零（如 io.CopyN(f, zeros, size)）会导致 10GB 文件耗时数秒甚至分钟，且立即占满磁盘；而 Truncate 创建 100GB 文件通常在毫秒级完成。
-
os.Create后必须调用Truncate，不能只靠Create自身——它只生成 0 字节文件 - 文件句柄需保持打开状态再调用
Truncate，关闭后再 reopen 并不能复用稀疏属性 - 若目标路径已存在非空文件，
os.Create会先清空内容，但Truncate仍可安全执行
为什么 Seek + Write 不如 Truncate
有人尝试用 f.Seek(size-1, 0) 再 f.Write([]byte{0}) 来“撑开”文件，这也能产生稀疏效果，但有明显缺陷：
- 必须确保写入至少 1 字节，否则某些旧版文件系统（如早期 ext3）可能不识别稀疏语义
-
Seek到末尾前位置再写，会触发内核隐式填充中间区域（取决于具体实现），失去稀疏性保障 - 当
size超过int64最大值一半（约 9TB）时，Seek可能因偏移计算溢出出错，而Truncate接收int64参数更直接可靠
Truncate 生成的文件是否真“空”？
逻辑上是空的（读任意未写位置返回 \x00），但物理上不占空间——这点可通过 du -h filename 和 ls -ls filename 验证：前者显示实际磁盘用量（常为 0 或几 KB），后者显示 Size 字段（即 Truncate 设定值）。
容易踩的坑：
- 误用
stat.Size()判断“是否写满”——它返回的是逻辑大小，不是物理占用 - 在 NFS 或某些容器卷（如 overlayfs）上，稀疏行为可能被禁用或降级为实分配，需实测验证
- 部分备份工具（如 rsync 默认）会把稀疏文件当作普通文件全量传输，导致带宽和存储浪费
需要实分配时怎么办？
如果业务强依赖物理空间已就位（例如避免运行时扩容抖动、或对接要求预刷盘的硬件），Truncate 就不够用了。此时应调用底层 syscall.Fallocate（仅 Linux）：
它通过 FALLOC_FL_ZERO_RANGE 标志强制分配并归零指定区间，比用户态反复 Write 更高效；但跨平台兼容性差，Windows/macOS 需 fallback 到分块写零（如每 1MB 用 bytes.Repeat 写一次）。
关键提醒：稀疏文件的“空洞”对应用透明，但一旦你用 WriteAt 往中间写入，或用 Sync 刷盘，内核可能按需分配对应块——这个过程不可控，也不可预测。真正稳定的预分配，永远要靠 fallocate 或等价系统调用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
