io.writer的write方法必须返回实际写入字节数n和错误err，不可假设len(p)全部写入；部分写入时需循环补写或用io.writestring等封装函数。
io.Writer 是 Go 文件写入的统一入口，所有写操作最终都流向它。你不需要为每种目标写不同逻辑，只要传入符合 io.Writer 接口的值，就能复用同一套写入流程。
为什么必须理解 io.Writer 的 Write 方法签名
Write 方法返回两个值：n int 和 err error，不是“写完就完事”。常见错误是忽略 n，以为 len(p) 一定被全部写入。
- 系统调用（如
write(2)）可能只写入部分字节，尤其在磁盘满、信号中断或网络缓冲区受限时 -
os.File.Write就是这种行为；而bufio.Writer.Write会内部重试，但仍有失败可能 - 正确做法是检查
n ，并手动循环补写，或直接用 <code>io.WriteString/fmt.Fprint等封装好的函数
os.Create 和 os.OpenFile 的权限参数陷阱
os.Create("log.txt") 看似简单，但它等价于 os.OpenFile("log.txt", os.O_CREATE|os.O_WRONLY|os.O_TRUNC, 0666) —— 注意最后那个 0666 是默认权限，但实际生效受 umask 影响。生产环境常因权限过宽（如误设 0777）或过严（如漏设 os.O_CREATE 导致 openat 失败）出问题。
- 显式使用
os.OpenFile更可控：例如os.OpenFile("data.bin", os.O_RDWR|os.O_CREATE, 0600)表示仅用户可读写 -
0644是安全起点：文件所有者可读写，组和其他人只读 - Windows 上权限位被忽略，但保持一致写法可避免跨平台疏忽
什么时候该用 bufio.NewWriter，什么时候不该
直接对 *os.File 调用 Write 每次都触发系统调用，小量高频写（如逐行日志）性能差。但加了 bufio.Writer 后，必须记得 Flush()，否则内容可能滞留在内存中不落盘。
- 适合场景：连续写入大量小数据（如 CSV 行、JSON 对象流）
- 危险场景：写入后立即需要文件内容可见（如配置生成后立刻被其他进程读取），必须
w.Flush() - 更稳妥的替代：用
os.WriteFile一次性写入整个内容，适用于内容确定且不超百 MB 的情况
os.WriteFile 看似简单，但要注意原子性与覆盖语义
os.WriteFile 内部先创建临时文件，写入后再 rename 替换原文件，在大多数文件系统上是原子的。但它总是覆盖，不能追加。
- 想追加？必须用
os.OpenFile(..., os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644) - 想避免覆盖旧文件？得先
os.Stat检查是否存在，再决定是否写入 - 大文件慎用：它把全部内容加载进内存，
os.WriteFile("big.log", data, 0644)可能触发 OOM
os.File.Write），你越要自己处理偏移、截断、flush、错误重试；越靠近高层（如 os.WriteFile 或封装好的 logger），越要清楚它隐含的假设和边界。接口统一，责任没消失，只是转移了。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
