必须用带缓冲的chan *AuditLog解耦主流程，缓冲区大小需经压测确定（如峰值800条/秒→设4096），加水位保护防OOM，并用recover包裹消费循环、加超时取日志防goroutine退出丢日志。
审计日志异步写入不能靠 log.Println 或直接 file.WriteString，必须用带缓冲的 chan *AuditLog 解耦主流程，否则高并发下要么丢日志、要么卡住接口、要么 OOM。
channel 缓冲区大小怎么设才不丢不爆
缓冲区不是越大越好。设太小（比如 10），峰值流量一来，select 非阻塞写直接走 default 分支丢日志；设太大（比如 100000），突发日志全堆进内存，GC 压力飙升，可能触发 OOM。
- 先压测：模拟 2–3 倍日常 QPS，记录单秒最大日志条数，乘以 3–5 倍作为基准（例如峰值
800条/秒 → 缓冲设4096） - 加水位保护：写入前判断
len(auditLogChan) > cap(auditLogChan)*0.8，超阈值则降级为同步写，或裁剪非关键字段（如UserAgent） - 别用
make(chan *AuditLog, 0)：无缓冲 channel 会让主流程卡在发送点，等消费者取走才继续
后台 goroutine 怎么防 panic 导致日志全丢
只起一个 go writeAuditLoop() 是典型错误——它一旦 panic，channel 里积压的日志就再也出不去，进程退出时全丢。
- 必须用
recover包裹消费循环体，捕获 panic 后打错、重连文件/ES，再continue，不能让 goroutine 退出 - 每次从 channel 取日志要加超时：
select { case log := ，防长期阻塞导致整个消费者僵死 - 进程退出前，用
sync.WaitGroup等待当前正在写的日志落盘，但加 2 秒 timeout，避免无限等待
写文件要不要 fsync？怎么批量才不毛刺
审计日志必须强持久化。不开 fsync，机器断电或 crash 会丢最后几批；开了每次写都刷盘，QPS 高时毛刺明显（尤其机械盘）。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 打开文件时加
os.O_SYNC，或写完显式调file.Sync()；bufio.Writer.Flush()≠fsync，必须单独调 - 推荐批量写 + 定期 sync：攒够
100条 or 超过100ms就 flush 一次，再统一Write+Sync，减少系统调用次数 - 别多个 goroutine 并发写同一文件：即使都用
os.O_APPEND，ext4 等文件系统仍可能因内核 write 缓存导致日志行错乱
结构体序列化选 json 还是 gob 还是自定义二进制
审计日志首要目标是可查、可读、可人工定位问题，不是极致性能。
- 用
json.Marshal，字段加json:",omitempty"减少空字段；别用map[string]interface{}，反射开销大 -
gob快但不跨语言、升级字段易出错，不适合审计场景 - 自定义二进制最省空间，但调试成本高、字段变更难维护，除非日志量极大且已稳定多年
- 日志内容建议提前拼好
string再发进 channel：避免后台 goroutine 里重复做time.Now().Format，引入时间误差或锁竞争
真正难的不是写对代码，而是压测出真实峰值、监控 len(auditLogChan) 水位、定期校验落地日志完整性——这些没做，缓冲区再大、fsync 再勤，也挡不住某次部署后突然涌进来的 10 倍日志洪峰。
