os.OpenFile追加写入必须同时指定O_APPEND、O_WRONLY和O_CREATE，缺一不可；缓冲写入需用bufio.Writer并显式Flush；并发写需Mutex或channel同步；权限、换行符和关闭文件等细节同样关键。
os.OpenFile 必须同时指定 O_APPEND、O_WRONLY 和 O_CREATE
追加写入失败或意外覆盖文件，八成是因为打开模式漏了标志。只写 os.O_APPEND 不行，os.O_WRONLY 也不能省——没有它，Go 会拒绝写入；os.O_CREATE 同样关键，否则文件不存在时直接报 no such file or directory。
常见错误现象：第一次运行正常，第二次却清空重写；或者程序在某些机器上能跑，换一台就 panic。
-
os.O_APPEND是内核级原子追加保证，不带它，哪怕你Seek(io.SeekEnd, 0)也扛不住并发竞争 - Windows 下首次创建文件时，
0644权限可能被忽略，建议显式用0666并确保父目录可写 - 别用
ioutil.WriteFile或os.WriteFile做“追加”，它们内部调os.Create，必然 truncate
bufio.Writer 能提速，但 Flush() 必须显式调用
直接对 *os.File 频繁 WriteString，每条日志都触发一次系统调用；套一层 bufio.NewWriter，能把几百次小写合并成几次落盘，吞吐量常提升 5–10 倍。
但缓冲区是内存里的“暂存站”，不喊它下车，数据就永远卡在那儿。
- 必须在关闭前调
w.Flush()，defer w.Flush()是底线 - 如果用
bufio.NewWriterSize(f, 64*1024)，32KB–64KB 对日志类追加最稳，太小刷盘太勤，太大延迟太高 -
bufio.Writer本身不改变追加语义——只要底层*os.File是用O_APPEND打开的，缓冲写入依然安全 - 别在
Flush()后继续往已关闭的*os.File写，会 panic：write: bad file descriptor
并发写同一个文件末尾，Mutex 或 channel 比锁文件更靠谱
WriteString 不是原子操作，即使底层用了 O_APPEND，Go 运行时仍会先把内容拷进 buffer 再 syscall，goroutine 之间存在微小时间窗，导致乱序或截断。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
别指望靠 os.Chmod 或临时文件重命名来规避——那只是把问题从“写错”变成“写慢”。
- 最简方案：全局一个
sync.Mutex，mu.Lock(); defer mu.Unlock()包住w.WriteString + w.Flush() - 更优方案：用 channel 收集日志条目，单个 goroutine 顺序消费并写入，天然串行且解耦
- 避免用
os.Seed + Write模拟追加，跨平台行为不一致，多进程下完全不可靠 - 第三方日志库（如 zap）底层也是走这套路，不是不用锁，而是把锁封装得看不见
bytes.Buffer 不适合替代文件追加，但可做前置拼接
bytes.Buffer 是内存缓冲，不是文件代理。把它当“临时文件”攒够再全量写回，等于自己造了个竞态陷阱：两次 WriteFile 调用之间，别人可能已经追加了新内容。
但它很适合在写入前做轻量聚合，比如把结构体字段格式化成一行日志字符串。
- 用
buff.Reset()复用底层数组，比每次bytes.NewBuffer(nil)更省内存 -
buff.WriteString和buff.Write都是追加语义，没有“写开头”这种操作，强行前置插入性能崩坏 - 拼好后直接
f.WriteString(buff.String())或w.Write(buff.Bytes())，别绕一圈转成 string 再转回 []byte - 真正要落盘的，永远是那个带
O_APPEND的*os.File，Buffer 只是中间一环
实际落地时，最容易被跳过的其实是权限和换行符：Windows 上用 "\r\n"，服务账户对目录没写权限，或者忘记 defer f.Close() 导致句柄泄漏——这些细节不解决，再好的缓冲策略也白搭。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
