Go访问日志中间件必须显式写入*os.File并管理其生命周期，因fmt.Printf默认输出到os.Stdout，后台运行时日志丢失；需用os.OpenFile一次打开、全局复用文件句柄，配合包装ResponseWriter获取真实状态码，并在进程退出时关闭文件。
Go访问日志中间件不能只用fmt.Printf，必须显式写入*os.File并正确处理文件句柄生命周期。
为什么fmt.Printf不能直接写日志文件
它默认输出到os.Stdout，即使你把日志逻辑塞进中间件，内容也只会刷到终端。线上服务看不到文件日志，排查就只能靠猜。
常见错误现象：
- 日志在
go run main.go时能看到，但./myserver后台运行后日志消失 - 用
tail -f access.log始终无输出，ls -l access.log发现文件大小为 0 - 并发请求下日志错乱、行断裂（因多个 goroutine 同时写未加锁的
os.File）
如何用fmt.Fprintf安全写入文件
关键不是“能不能写”，而是“怎么写才不丢、不错、不卡”。核心是三件事：打开文件用追加模式、复用*os.File句柄、避免每次请求都OpenFile。
立即学习“go语言免费学习笔记（深入）”；
- 用
os.OpenFile("access.log", os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644)一次打开，全局复用 - 不要在中间件闭包里调用
os.OpenFile——每请求开一次文件，fd 耗尽后accept: too many open files就来了 -
fmt.Fprintf(file, "%s %s %d %v\n", r.Method, r.URL.Path, statusCode, duration)比log.Printf更可控，不带额外前缀和换行干扰 - 务必在
main()启动前检查file != nil，否则nil指针 panic 会直接崩掉服务
状态码和耗时必须用包装ResponseWriter获取
HTTP 状态码在WriteHeader时才真正确定，r和w参数本身不暴露这个值。不包装就只能记成 200，误报率极高。
- 定义
loggingResponseWriter结构体，嵌入http.ResponseWriter并重写WriteHeader - 在
WriteHeader里存下code到字段，供日志闭包末尾读取 - 别忘了透传
Write和Header方法，否则Set-Cookie或Content-Type会失效 - 示例中
lw.statusCode初始设为http.StatusOK，是因为有些 handler 根本不调WriteHeader（比如直接Write），这时按规范应视为 200
生产环境必须考虑的细节
本地跑通不等于线上可用。真正卡住人的往往不是逻辑，而是边界。
- 日志文件路径建议用绝对路径，避免
chdir或 systemd 工作目录变动导致写入失败 - 大流量下频繁
fsync会拖慢响应，可接受几秒延迟的话，不必每条都file.Sync() - 日志轮转要交给
logrotate或rsyslog，中间件自己做切割容易出竞态 - 如果用
log.SetOutput(file)替代fmt.Fprintf，注意log包内部有锁，吞吐量会下降约 15%～20%
最易被忽略的一点：中间件返回的http.Handler必须确保file.Close()在进程退出时执行，而不是在中间件函数返回时——否则日志写一半就被截断。
