Go标准库log包需用log.SetOutput重定向至os.OpenFile打开的文件句柄，推荐模式为os.O_CREATE|os.O_WRONLY|os.O_APPEND，并务必检查错误、复用句柄、避免重复打开。
log.SetOutput 写文件最直接
Go 标准库的 log 包本身不内置文件输出，但通过 log.SetOutput 替换默认的 os.Stderr 就能实现。关键不是“怎么配”，而是“怎么安全地设一个可写文件句柄”。
常见错误是直接传 os.Create("app.log") 后没处理失败，或忽略日志追加（而非覆盖）需求：
- 用
os.OpenFile显式控制打开模式，推荐os.O_CREATE | os.O_WRONLY | os.O_APPEND - 务必检查返回的
*os.File和error，空指针 panic 比日志写不出更糟 - 不要在每次写日志前反复
OpenFile—— 文件句柄应复用，程序启动时初始化一次
file, err := os.OpenFile("app.log", os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644)
if err != nil {
log.Fatal(err) // 或 fallback 到 stderr
}
log.SetOutput(file)
// 后续所有 log.Print/Printf 都会写入该文件
多 goroutine 写同一个文件安全吗
安全，log.Logger 内部已用 mutex 保证写操作串行，即使多个 goroutine 并发调 log.Printf 也不会乱序或丢日志。
但要注意实际磁盘 I/O 不是瓶颈，锁只管格式化和写入缓冲区，真正慢的是系统调用。所以：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 高频日志（如每毫秒一条）仍可能拖慢业务逻辑，建议评估是否需要异步写（例如用 channel + 单独 goroutine 转发）
- 如果用
log.SetOutput指向同一个*os.File，无需额外同步；但若每个 goroutine 自己开个文件句柄写，就变成竞态，且极易打爆文件描述符 - 注意
*os.File是线程安全的，但它的Close()不能随便调 —— 关了之后再写会 panic: "write: bad file descriptor"
log.Println 写文件后为什么没实时看到内容
因为 *os.File 默认带缓冲，尤其在非终端设备上会批量刷写。你调 log.Println，内容可能卡在内存缓冲里几秒才落盘。
解决方法不是关缓冲（性能差），而是主动触发刷新：
- 调
file.Sync()强制刷盘，适合关键日志（如支付完成）后立刻落盘 - 更常用的是用
bufio.NewWriter包一层，自己控制Flush()时机，但标准log不支持直接注入 writer，得自己封装io.Writer实现Write()并在内部调bufio.Writer.Flush() - 简单场景下，可在程序退出前统一
file.Sync()，避免日志丢失
要不要用第三方日志库比如 zap 或 zerolog
如果你只需要按天轮转、JSON 格式、自动压缩，或者日志量超过 1k QPS，标准 log 就不够用了 —— 它不支持轮转，也不支持结构化字段，更不支持 Level 控制（log.Printf 没 debug/info/warn 分级）。
但如果你只是调试阶段、单机小服务、日志量低、格式无所谓，硬上 zap 反而增加依赖和配置复杂度。真实项目中容易被忽略的一点是：
- 轮转文件必须自己监听信号或定时检查，标准库完全不管；而
lumberjack这类辅助包虽小，却要额外维护生命周期（比如Rotate时旧文件句柄没关干净会导致 Windows 下删不了文件） - 很多团队踩过坑：用
log.SetOutput指向一个每天新建的文件，但忘记关闭前一天的句柄，跑一周后报 “too many open files”
文件路径、权限、滚动策略、关闭时机，这些看似边缘的问题，恰恰是线上日志不可靠的主因。
