os.writefile适合一次性写入整个[]byte，原子、简洁、自带权限控制，是go 1.16+标准写法；需显式传fs.filemode（如0644），不自动创建父目录，不支持追加，大文件慎用。
直接用 os.WriteFile 就够了，95% 的场景不需要手动管理文件句柄。 它原子、简洁、自带权限控制，且自 Go 1.16 起就是标准写法；老教程里满屏的 os.Create + defer file.Close() + file.Write() 已属冗余，除非你有流式写入、追加、偏移写入等明确需求。
什么时候该用 os.WriteFile
适合一次性把整个 []byte 写进磁盘：配置生成、模板渲染结果保存、小体积二进制 dump、API 响应缓存落盘等。
- 它自动处理文件创建或覆盖，不关心目标是否存在
- 权限参数
fs.FileMode必须显式传，比如0644（等价于0o644），漏传会默认为0000—— 文件不可读不可写，这是最常踩的坑 - 底层是原子写入：先写临时文件，再
rename，避免写到一半崩溃导致脏数据 - 不适合大文件（如 >100MB）：全部内容需驻留内存，可能触发 GC 压力或 OOM
为什么 os.Create + Write 还没被淘汰
当你需要多次写入、控制写入位置、或复用同一文件句柄时，就得回到传统流程。比如日志轮转中追加内容、视频分片拼接、数据库 WAL 日志写入。
-
os.OpenFile(filename, os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644)是追加的标准写法；只用os.Create会清空原文件 -
file.WriteAt(data, offset)可在指定偏移写入，用于 patch 场景（如修复 ZIP 中某段 header） - 必须配
defer file.Close()，否则 fd 泄漏 —— 在长期运行服务中，几十个未关闭文件就可能 hit ulimit - 写完别忘了
file.Sync()，尤其对可靠性要求高的场景（如金融交易日志），否则数据可能还卡在 OS page cache 里
bufio.Writer 真的能提速吗
能，但只在高频小写入（比如每秒写几百次短日志）时明显；对单次几 KB 以上的写入，它反而因多一层缓冲带来开销。
- 典型模式：
w := bufio.NewWriter(file); w.WriteString("..."); w.Flush() -
Flush()必须显式调用，否则内容可能滞留缓冲区，程序退出也不保证落盘 - 缓冲区大小默认 4KB，可通过
bufio.NewWriterSize(file, 64*1024)调整，但别盲目设大 —— 延迟增加，且仍受限于 OS write 系统调用粒度 - 注意：
bufio.Writer不改变权限、不处理原子性，它只是套在*os.File上的一层包装
真正容易被忽略的是错误传播路径：os.WriteFile 的 error 是最终结果；而流式写入中，file.Write 可能成功，file.Close() 却失败（比如磁盘满），所以 err = file.Close() 这一行不能省 —— 很多人只检查 Write 错误，结果数据看似写入成功，实则根本没刷到磁盘。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
