标准log包因全局sync.mutex导致高并发锁竞争，qps超500即延迟上升；异步日志需缓冲channel、单写协程、bufio.writer批量flush，并支持结构化、上下文注入、崩溃恢复与背压控制。
为什么标准log包在高并发下会拖慢服务
Go 标准 log 包用全局 sync.Mutex 保护写入，所有 goroutine 争抢同一把锁。QPS 超过 500 后，日志延迟就开始明显上升；到 2000+ 时，锁竞争毛刺会让 P99 延迟翻倍。这不是磁盘慢，是锁卡住了业务逻辑。
异步日志必须带缓冲 channel + 单写协程 + bufio.Writer
只用 go func() { file.WriteString() }() 或无缓冲 chan string 是典型错误——它既不缓冲、也不批量、更无背压控制，结果就是日志错乱、进程退出丢日志、突发流量 OOM。
-
logChan := make(chan *LogEntry, 1024)：缓冲大小不能为 0，1024 是安全起点；再大需按峰值日志量预估，避免内存溢出 - 后台只启 1 个 writer goroutine，用
bufio.NewWriterSize(file, 16*1024)显式设 buffer 大小（默认 4KB 太小） - 必须调
w.Flush()+file.Sync()：前者刷到内核 buffer，后者强制落盘（ERROR/PANIC 级别不可省） - 批量 flush：按条数（如 ≥100）或定时（如
time.Ticker(50 * time.Millisecond)）触发，减少系统调用次数
结构体设计要支持字段扩展和上下文传递
纯字符串日志难解析，结构化才是生产标配。字段不能硬编码进格式化字符串，而应通过 map 或结构体携带。
- 定义
LogEntry时包含Time、Level、Message和Fields map[string]interface{} - 关键字段如
trace_id、user_id应从context.Context提取并注入Fields，避免每层手动传参 - 输出格式优先 JSON：便于 Loki/ELK 解析；若需文本，用固定分隔符（如
\t），别依赖空格对齐
别忽略崩溃恢复与满载丢弃策略
异步日志不是“扔进 channel 就完事”。进程意外退出时，channel 里未消费的日志会丢失；缓冲区打满又没限流，会卡死整个业务。
- 主程序退出前必须
close(logChan)，并在 writer 中用for entry := range logChan消费完剩余日志 - 写入失败（如磁盘满）时，不能 panic，应降级为
stderr输出，并记录自身错误 - 缓冲区满时，
select配合default分支做非阻塞写入：成功则发，失败则丢弃或走保底同步直写（仅限 ERROR/FATAL） - 滚动切割、压缩、过期清理这些功能，不要自己造轮子——zap/zapcore 或 zerolog 已内置稳定实现
真正难的不是启动一个 goroutine，而是让日志在十万级 QPS 下不丢、不错、不拖慢、不崩盘。缓冲大小、批量阈值、落盘时机、满载策略，每个参数都要结合压测数据调，而不是抄示例代码就上线。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
