缓冲区大小需权衡丢日志与OOM风险：先压测得峰值日志量，乘3–5倍设基准（如800条/秒→4096），并加水位保护；消费者须recover防panic退出、加超时防阻塞、退出前等待落盘；审计日志强持久化需fsync，推荐批量写+定期Sync；序列化优先json（易调试），性能敏感可选gob或纯文本；最终靠水位监控、健康检查、落地校验兜底。
auditLogChan 用多大缓冲才不丢日志又不爆内存
缓冲区不是越大越好，得看日志峰值和消费速度。设太小（比如 10），高并发时 select 写入失败直接丢日志；设太大（比如 100000），突发流量把日志全塞进内存，GC 压力陡增，还可能 OOM。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先压测：模拟 2–3 倍日常 QPS，观察单秒最大日志条数，乘以 3–5 倍作为缓冲基准（例如峰值 800 条/秒 → 缓冲设
4096） - 加保护逻辑：写入前用
len(auditLogChan) > cap(auditLogChan)*0.8判断是否快满，超阈值则降级为同步写或丢弃非关键字段（如userAgent） - 避免用
make(chan *AuditLog, 0)（无缓冲），主流程会卡在auditLogChan 上，等消费者取走才继续
消费者 goroutine 怎么保证 crash 后不丢日志
只起一个 go writeAuditLoop() 是常见错误——它 panic 了，后续所有日志就积在 channel 里，程序退出时全丢。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
recover包裹循环体，捕获 panic 后打错、重连文件/ES、再 continue，别让 goroutine 退出 - 加超时控制：每次从
取日志设 <code>select+time.After(5 * time.Second)，防 channel 长期阻塞导致整个消费者僵死 - 进程退出前，用
sync.WaitGroup等待当前正在写的日志落盘（但别等太久，加 2 秒 timeout）
写文件时 fsync 要不要开？什么时候开
不开 fsync，日志写进内核 buffer 就返回，机器断电或 crash 会丢最后几批；开了，每次写都刷盘，QPS 高时毛刺明显（尤其机械盘）。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 审计日志必须强持久化：用
os.O_SYNC打开文件，或写完调file.Sync() - 折中方案：批量写 + 定期 sync —— 把
收集到切片（比如每 100 条或 100ms flush 一次），再一次性 <code>Write+Sync，减少系统调用次数 - 注意：
bufio.Writer的Flush()不等于fsync，必须显式调file.Sync()
结构体字段序列化选 json 还是 gob 还是自定义二进制
json 最易调试但慢且占空间；gob 快但不跨语言、升级字段易出错；自定义二进制最省但维护成本高。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 审计日志要查、要人工看：用
json.Marshal，加json:",omitempty"减少空字段，别用map[string]interface{}（反射开销大） - 纯内部服务+性能敏感：用
gob，但必须固定 struct tag（如gob:"1"），升级字段只能追加，不能删改序号 - 字段极少（如只有
time,uid,action）：直接fmt.Fprintf(file, "%d,%s,%s\n", log.Time.UnixMilli(), log.UID, log.Action)，最快最稳
真正难的不是怎么异步，是当磁盘满、权限错、网络挂时，channel 里那几百条日志还在不在——得靠缓冲水位监控、消费者健康检查、落地前校验这三件事兜底。
