go标准库log包不支持采样和动态调级，因其无分级、全同步、不可配置；zap通过samplingconfig和atomiclevel原生支持二者，但需注意采样在级别过滤后生效、惰性求值避坑及压测验证参数。
为什么直接用 log 包做不到采样和动态调级
Go 标准库的 log 包是同步、无缓冲、不可配置日志器，既不支持按概率丢弃日志（采样），也无法在运行时修改输出级别。它连 Debug/Info 这种基本分级都没有——只有 Print、Panic、Fatal 三类行为，且全部默认输出。真要实现采样或动态调级，必须换日志库或自己封装。
用 zap 实现带采样的结构化日志
zap 是 Go 生态最主流的高性能结构化日志库，原生支持采样（SamplingConfig）和多级别控制。关键不是“开了采样就万事大吉”，而是采样策略必须匹配真实负载场景：
- 高频低价值日志（如 HTTP 请求 trace ID 打点）适合固定速率采样，例如每 100 条留 1 条：
SamplingConfig{Initial: 100, Thereafter: 100} - 错误日志绝不应采样，需单独绕过采样器：用
Check(zapcore.ErrorLevel, msg)判断后再写，或把 error 级别日志发到独立Core - 采样只影响日志记录动作，不影响字段构造——如果
zap.String("user_id", heavyCalcUserID())写在采样前，函数仍会被执行。务必用惰性求值：zap.Stringer("user_id", lazyUserGetter)
示例片段：
cfg := zap.NewProductionConfig()
cfg.Sampling = &zap.SamplingConfig{
Initial: 50,
Thereafter: 500,
}
logger, _ := cfg.Build()
logger.Info("request received", zap.String("path", r.URL.Path)) // 可能被丢弃
logger.Error("db timeout", zap.String("query", q)) // 不受采样影响（ErrorLevel 被采样器豁免）
如何让日志级别在运行时生效
动态调级的核心是：日志器必须持有可变的 AtomicLevel，且所有日志调用都通过该原子变量判断是否输出。不能靠重启或 reload 配置文件——那是运维手段，不是程序内动态。
- 初始化时用
zap.NewAtomicLevelAt(zap.InfoLevel)创建可变级别 - 把该原子变量传给
zap.Config的Level字段，或手动构造Core - 提供 HTTP handler 或信号监听（如
syscall.SIGUSR1）来调用level.SetLevel(zap.DebugLevel) - 注意：级别变更立即生效，但正在执行的
logger.Info(...)调用已进入 pipeline，不受影响；下一条才会检查新级别
常见误操作：在 handler 里重新 Build() 一个新 logger 并覆盖全局变量——这会导致旧 logger 的 goroutine 泄漏，且无法保证所有模块及时切换。
采样 + 动态调级组合使用的坑
两者叠加时，采样器是在 level 判断之后才介入的。也就是说，如果当前 level 是 Warn，而你写了 logger.Info(...)，这条日志根本不会进采样器——先被 level 挡掉了。所以采样配置里的 Tick 和 Initial 只对「通过 level 筛选的日志」生效。
- 不要假设 “设了 Info 级别 + 采样，就能看到部分 Info 日志” —— 如果业务代码大量混用
Info和Debug，又只开放Info级别，那Debug日志一条都不会采样，更不会输出 - 采样统计本身也需日志：建议用独立的
zap.AtomicLevel控制采样器内部日志（如 “dropped N logs”），避免形成递归采样 - 动态调级后，若立刻收到突发流量，采样器的计数器（
initial计数）不会重置——它按绝对条数滑动，不是按时间窗口。高并发下可能瞬间耗尽 initial 配额，导致后续日志全被降频
真正难的不是写通这两个功能，而是让采样率、初始配额、级别阈值和业务日志分布四者对齐。线上调参前，一定用真实请求流量做压测验证，而不是只看单条日志是否被采样。
