必须显式调用 os.file.close() 才能确保内容落盘，因其内部触发 fsync；漏掉则文件可能为空或截断，尤其在短生命周期程序中。
写文件时程序没报错但内容没落盘？检查 os.File.Close() 是否被忽略
Go 的 os.Create()、os.OpenFile() 返回的 *os.File 是带缓冲的，Write() 或 WriteString() 只写入内核缓冲区，不保证立即刷到磁盘。常见现象是程序退出后文件为空或内容截断。
必须显式调用 Close() —— 它内部会触发 fsync()（Linux/macOS）或等效刷新操作。漏掉这一步，尤其在短生命周期命令行工具里，几乎必现问题。
- 别依赖 defer 闭包「一定来得及」：如果
main()提前 panic 或 os.Exit()，defer 不执行 - 写完立刻需要可见性（如日志轮转），用
file.Sync()主动刷盘，比等 Close 更可控 -
ioutil.WriteFile()（Go 1.16+ 已弃用，改用os.WriteFile()）是原子写入，内部自动处理 Close 和权限，适合小文件一次性写入
追加写入总覆盖旧内容？确认 os.O_APPEND 和 os.O_CREATE 同时传入
os.OpenFile(path, os.O_WRONLY|os.O_APPEND, 0644) 看似正确，但如果文件不存在，会返回 open /path: no such file or directory 错误——因为 O_APPEND 本身不创建文件。
追加写入需两个 flag 缺一不可：存在时追加，不存在时创建。少一个就会失败或误行为。
立即学习“go语言免费学习笔记（深入）”；
- 正确写法：
os.OpenFile(path, os.O_WRONLY|os.O_CREATE|os.O_APPEND, 0644) - 不要用
O_TRUNC：它会清空文件，和追加完全相反 - 注意权限参数（第三个参数）：即使文件已存在，
0644也不会修改已有权限；只对新建文件生效
文件权限在 Linux/macOS 生效但在 Windows 无感？理解 Go 的权限参数实际作用范围
os.Create() 或 os.OpenFile() 的权限参数（如 0644）在 Windows 上被完全忽略——WinAPI 不支持基于 chmod 的细粒度权限控制。它只影响 Unix-like 系统（Linux、macOS、BSD）。
更隐蔽的问题是：即使在 Linux，若 umask 设置为 0022，传入 0644 实际创建的文件权限是 0644 &^ 0022 = 0644（即 644），但若 umask 是 0002，结果就是 0642（组写权限被抹掉）。
- 跨平台程序别依赖该参数控制 Windows 权限，可改用
os.Chmod()补充（但 Win 下仅支持只读标志） - 生产环境部署时，检查运行用户的 umask，避免权限比预期更严格
- 容器中运行时，基础镜像的 umask 可能和本地开发机不同，导致权限不一致
大文件写入卡住或 OOM？避免一次性 os.WriteFile()，改用流式写入
os.WriteFile(path, []byte(largeData), 0644) 会把整个内容加载进内存再写入，100MB 字符串 ≈ 100MB 内存占用。对日志、导出、上传临时文件等场景极易触发 GC 压力或直接 OOM。
真实业务中，应优先选择带缓冲的流式写入，让数据边生成边落盘。
- 用
bufio.NewWriter(file)包装*os.File，写完调w.Flush() - 从
io.Reader（如 HTTP body、数据库 rows）直接io.Copy(writer, reader)，零拷贝且内存恒定 - 避免
fmt.Fprintf(file, "%s", hugeString)：它仍会先格式化进内存，再写入
权限、追加、刷盘、内存——每个点单独看都不难，但混在一起时，一个疏忽就让文件写入变成定时炸弹。尤其是 Close 和 Sync 的时机，还有 umask 这种藏在系统层面的变量，最容易在线上突然冒出来。
