高并发日志需用带缓冲的 chan *LogEntry 配合 sync.Pool 和非阻塞写入；结构体指针通道避免锁争用与 GC 抖动，预计算字段（如 Time）并设合理容量（如 4096），select+default 防主流程卡死。
直接用 log.Printf 或 file.WriteString 在高并发下必然卡顿，不是日志量大，而是每次调用都触发阻塞式系统调用，goroutine 堆积在 I/O 上。真正有效的队列方案必须满足三点：生产不阻塞、消费单线程、落盘可控。
为什么带缓冲的 chan *LogEntry 比 chan string 更稳
字符串通道看似简单，但高频写入时会暴露 runtime 层面的锁争用瓶颈；而结构体指针通道能复用内存、规避 GC 抖动，且天然支持字段扩展（如 level、reqID、traceID）。
-
chan string在 8+ goroutine 持续写入时，pprof 明显看到runtime.chansend占用大量 CPU —— channel 底层锁成了瓶颈 -
chan *LogEntry配合sync.Pool复用结构体，避免每条日志都 new 分配，GC 压力下降 60%+ - 结构体字段可预计算：比如
Time字段在入队前就time.Now()，避免消费端再调用，减少时钟系统调用 - 务必设容量：
make(chan *LogEntry, 4096)，太小丢日志，太大吃内存；从 2048 起压测，观察len(logChan)峰值
select + default 实现非阻塞写入防卡死
业务 goroutine 绝不能因日志队列满而阻塞。用 select 配合 default 是唯一安全写法，否则突发流量会拖垮主流程。
- 错误写法：
logChan —— 队列满时 goroutine 永久挂起 - 正确写法：
select { case logChan <- entry: // 成功入队 default: // 队列满，降级处理：打印到 stderr 或丢弃 fmt.Fprintln(os.Stderr, "[WARN] log dropped: queue full") } - 别在
default里重试或 sleep —— 这会放大延迟，且无法缓解根本压力 - 如果允许丢日志，
default中直接 return；如果关键日志不能丢，改用环形缓冲（如github.com/Workiva/go-datastructures/ring）覆盖最老条目
批量 flush 必须绕过 bufio.Writer 的隐式 flush 陷阱
bufio.NewWriter 默认只缓存、不保证落盘，程序崩溃前未 Flush() 就全丢；而盲目加 file.Sync() 又拖慢吞吐。平衡点在于“双触发”：数量阈值 + 时间窗口。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 初始化用
bufio.NewWriterSize(file, 16*1024)（16KB），比默认 4KB 更省系统调用 - flush 触发条件必须同时监控两个信号：
- 缓冲区中日志条目 ≥ 128 条（不是字节数！避免长日志挤压短日志）
- 距离上次 flush ≥ 50ms（用
time.Timer或time.AfterFunc）
- 每次
w.Flush()后，对 ERROR 级别日志额外调用file.Sync()，确保磁盘落盘；INFO/WARN 可跳过，靠定时 flush 保障最终一致性 - 别依赖
defer w.Flush()—— panic 或os.Exit()时不会执行，必须在Close()方法里显式 flush + sync
环形缓冲 vs channel：什么场景该换
当 QPS 稳定超过 5000，或 p99 延迟开始跳变（比如从 0.2ms 飙到 5ms），说明 channel 已成瓶颈，该切环形缓冲。但切换不是换包那么简单。
- 环形缓冲容量必须是 2 的幂（如 4096、8192），否则位运算索引错乱，静默覆盖数据
- 写入必须用 CAS 重试：
atomic.CompareAndSwapUint64(&rb.writeIndex, old, new)，不能用atomic.AddUint64—— 否则多 goroutine 并发递增导致 slot 冲突 - 底层字节数组要一次性分配、绑定生命周期，避免 GC 提前回收；字符串写入前转
[]byte时，用unsafe.String+unsafe.Slice防逃逸（Go 1.20+） - 环形缓冲只解决“暂存+丢弃”，不解决 fsync 阻塞；仍需单 goroutine 消费 + 批量 write + 条件 sync
最容易被忽略的是：缓冲区大小和 flush 时机必须一起调优。设了 8192 容量却用 5s 才 flush 一次，等于把内存当磁盘用；反过来，128 条就 flush 却配了 16KB 缓冲，浪费了批量优势。真实压测时，盯住 runtime.ReadMemStats 的 PauseNs 和 WriteSyscall 耗时，比看 QPS 更准。
