日志需平衡可观测性与开销，按环境分层控制级别；用结构化占位符延迟格式化；敏感字段必须过滤，上下文通过loggeradapter注入；高频场景启用采样与异步写入。
日志不是越多越好，也不是越少越安全；关键是在可观测性与运行开销之间找到平衡点。粒度太粗，问题无从定位；粒度太细，又拖慢响应、撑爆磁盘。设计时要围绕“谁要看、什么时候看、看什么”来决策。
按场景分层控制日志输出
不同环境对日志的需求差异极大，不能一套配置打天下：
- 开发阶段：启用 DEBUG 级别，记录函数入参、中间状态、sql 查询、http 请求/响应体（脱敏后）
- 测试/预发环境：INFO 为主，WARNING 及以上必留，可额外开启关键路径的 DEBUG（如支付流程）
- 生产环境：默认 INFO，Error/CRTICAL 全量捕获；DEBUG 仅对特定模块动态开启（如
Logging.getLogger("myapp.payment").setLevel(logging.DEBUG)）
用结构化占位符代替字符串拼接
写日志时别急着格式化，延迟解析能省下不少 CPU：
- ✅ 推荐：
logger.info("User %s accessed %s in %d ms", user_id, path, duration) - ❌ 避免：
logger.info(f"User {user_id} accessed {path} in {duration} ms")或logger.info("User " + str(user_id) + ...)
前者只在日志实际被输出时才执行变量转换和字符串拼接；后者无论级别是否匹配，都会提前构造完整字符串，浪费资源。
敏感字段必须过滤，上下文信息按需注入
日志里不该出现密码、Token、身份证号等——这不是风格问题，是合规红线：
- 用
Filter类统一拦截含敏感关键词的日志（如"password"、"auth_token"），替换成"***" - 需要 trace_id、request_id、user_id 等上下文时，优先用
LoggerAdapter注入，而不是每次调用都手动传参 - 避免在日志消息中硬编码业务逻辑（如
if debug: logger.debug(...)），应交由 logging 系统自身按 level 控制
异步写入与采样机制降低性能冲击
高频服务（如 API 网关、实时风控）需主动限流日志行为：