直接用 os.File.Write 会卡住主线程，因为它是同步阻塞调用，每次写入都触发系统调用并挂起 goroutine；高并发下多协程争抢同一文件句柄导致串行写入、延迟飙升。
为什么直接用 os.File.Write 会卡住主线程
因为它是同步阻塞调用：每次写都触发系统调用，等内核把数据从用户空间拷贝到磁盘（或页缓存），期间 goroutine 被挂起。高并发下几十个协程抢同一个文件句柄，实际变成串行写入，延迟飙升，CPU 却在空等。
常见错误现象：log.Println 在压测时拖慢整个 HTTP handler 响应；日志量一大，qps 直线下降；strace 看到大量 write() 系统调用阻塞在 epoll_wait 后面。
- 别指望操作系统自动“异步”——Go 标准库所有
os.File方法默认都是同步的 -
O_ASYNC标志在 Linux 上对普通文件无效，仅对终端、socket 等少数 fd 生效 - 真正能解耦的只有靠 Go 自己的并发模型：goroutine + channel
用 bufio.Writer 做缓冲写入，但必须配 Flush()
它不解决“异步”，只解决“小写入太碎”。把 100 次 100B 的 Write 合并成 1 次 10KB 的系统调用，吞吐翻几倍很常见。
- 默认缓冲区是 4KB，日志类场景建议设为
32 * 1024或64 * 1024；导出大报表可试256 * 1024 -
w.Flush()才真正落盘，且是**唯一可能返回磁盘错误的地方**（如磁盘满、权限不足） -
defer w.Flush()只在函数 return 时触发，panic 或os.Exit()会跳过它 → 必须在关键路径主动Flush()并检查错误 - 别在循环里每写一行就
Flush()，那等于没缓冲；也别完全不Flush()，程序崩溃时最后一块日志就丢了
用 goroutine + channel 实现真·异步写入
这才是让业务逻辑不等 I/O 的核心。不是把写文件扔进 goroutine 就完事——得设计好生产/消费节奏，否则内存爆掉或丢日志。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- channel 缓冲区要设大小（如
make(chan string, 100)），防止日志突增时生产者被堵死 - 消费者 goroutine 内部要用
bufio.Writer再套一层缓冲，避免每条消息都触发一次系统调用 - 必须处理 channel 关闭：用
for msg := range ch，并在退出前close(ch)，否则消费者永远阻塞 - 程序退出时，需加
sync.WaitGroup等待消费者 flush 完最后一波数据，再os.Exit()
高并发下别自己造轮子，优先复用 sync.Pool 和第三方日志库
自己维护 bufio.Writer 对象池容易出错：忘记 Reset() 导致写到旧文件，或复用后残留缓冲数据。
-
sync.Pool的New函数必须返回新对象，不能返回nil；取出来后必须调用w.Reset(file)绑定新文件句柄 - 高频日志场景（如微服务）直接上
zap或slog（Go 1.21+）：它们内置了异步队列、内存池、分级刷新策略，比手写稳定得多 - 如果必须自研，注意
channel容量和定时 flush 间隔的平衡：100 条 or 100ms 触发一次写入，比单条立刻 flush 更稳
最易忽略的一点：异步写入不是“不关心错误”，而是要把 Flush() 错误通过 channel 或 callback 回传给业务层——否则磁盘写失败了你根本不知道。
