最安全的日志文件打开方式是os.O_CREATE | os.O_WRONLY | os.O_APPEND，缺一不可；必须用bufio.Writer缓冲写入并显式Flush；多goroutine写需加锁；创建前须确保目录存在且权限正确。
os.OpenFile 的 flag 参数怎么选才不覆盖或追加错
写日志最常踩的坑就是用 os.O_CREATE | os.O_WRONLY 打开文件，结果每次运行都清空旧内容——因为缺了 os.O_APPEND。但光加 O_APPEND 也不够：如果还带 os.O_TRUNC，照样会先截断再追加，等于白加。
真实日志场景只该用这组组合：
-
os.O_CREATE | os.O_WRONLY | os.O_APPEND：文件不存在就创建，存在就追加，安全可靠 - 绝对避免
os.O_TRUNC，除非你真想轮转时手动删旧文件 - 如果要支持“存在则失败”，加
os.O_EXCL（配合O_CREATE），但日志一般不需要
为什么直接用 os.OpenFile 写日志容易丢数据
因为 os.File.Write 是系统调用，不带缓冲；每次写都触发一次 syscall，高频日志下性能差，更危险的是：进程崩溃或断电时，内核缓冲区里还没刷盘的数据就丢了。
正确做法是包一层 bufio.Writer：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
bufio.NewWriterSize(file, 4096)创建带缓冲的写入器，大小建议 4KB（页大小） - 记得在程序退出前调用
writer.Flush()，否则最后一段日志可能卡在缓冲区 - 别用
log.SetOutput(file)直接塞*os.File，它没缓冲，也不自动 flush
多 goroutine 写同一个日志文件要不要加锁
要。Go 的 os.File.Write 虽然内部有文件描述符级别锁，但那是系统级的，只保单次 write 原子性，不保多行日志的边界。比如两个 goroutine 同时写 "[INFO] a\n" 和 "[ERROR] b\n"，可能混成 "[INFO] a[ERROR] b\n\n"，日志完全不可读。
简单有效的方式：
- 用
sync.Mutex包住writer.Write()+writer.Flush()（如果需要实时刷盘） - 或者直接用
log.Logger自带的l.SetOutput()配合锁封装的 writer，它内部已做同步 - 不要依赖
os.File自身线程安全——它不是为高并发日志设计的
文件权限和路径错误导致 open failed 怎么快速定位
常见报错 open /var/log/app.log: permission denied 或 no such file or directory，往往不是代码问题，而是运行时环境没配好。
检查顺序很关键：
- 确认目录存在：
os.MkdirAll(filepath.Dir(logPath), 0755)必须在os.OpenFile前调用 - 权限位别写死
0644：Linux 下如果父目录无写权限，文件还是创建不了；os.OpenFile的 perm 参数只影响新建文件，不影响目录 - 用绝对路径，避免工作目录不一致；调试时先
fmt.Println("writing to:", logPath)看看到底写了哪
真正麻烦的是权限继承问题：systemd 服务默认 umask 是 0022，但某些容器或用户环境下 umask 更严，导致文件创建后连自己都写不了。这时候得在 os.OpenFile 后立刻 os.Chmod 补权限，而不是指望 perm 一次到位。
