幂等日志需基于异常类全限定名、标准化堆栈首三帧、关键业务上下文哈希及确定性状态快照生成唯一指纹，配合内存缓存去重、日志级别降级与聚合计数实现；须规避字符串全量哈希、日志端去重等陷阱。
在循环重试逻辑中，同一异常反复触发、反复记录堆栈日志，会导致日志爆炸、干扰问题定位，还可能掩盖真实异常模式。关键不是“不记日志”，而是让日志具备幂等性——相同异常上下文只产生一条有代表性的日志，后续重试不再重复输出。
识别“同一异常”的核心依据
不能仅靠异常类型（如 NullPointerException）或消息字符串判断是否重复。需组合以下维度生成唯一指纹：
-
异常类全限定名 + 标准化堆栈首三帧：提取异常构造位置（
getStackTrace()[0]）、最外层业务入口方法、以及首次抛出该异常的原始调用点（排除通用工具类、AOP代理层） - 关键业务上下文哈希：如订单ID、请求TraceID、用户ID等稳定标识字段；避免包含时间戳、随机数、临时对象引用
- 异常发生时的确定性状态快照：例如重试次数、当前重试间隔毫秒数、上游返回码（若为HTTP调用）
实现幂等日志的典型策略
无需引入外部存储，轻量级方案即可落地：
-
内存缓存+短时效去重：使用
ConcurrentHashMap缓存指纹 → 时间戳映射，TTL设为30–60秒。重试前先计算指纹，命中则跳过日志；未命中则记录并写入缓存 - 日志级别降级：首次记录用 ERROR 级别并输出完整堆栈；后续同指纹异常降为 WARN，仅输出“重试第N次，异常指纹：xxx”
-
聚合计数字段：在首次日志中增加
retryCount=1字段；后续同指纹日志不新建条目，而是原子更新该字段（如通过日志框架的MDC或自定义Appender支持）
需要规避的常见陷阱
看似合理但实际破坏幂等性的做法：
- 仅用
exception.toString()做哈希：堆栈中含行号、临时变量值、线程名等易变内容，每次都不一致 - 把整个堆栈转成字符串再哈希：性能差，且不同JVM版本/优化级别可能导致帧顺序微调
- 依赖日志系统端去重（如ELK的dedot插件）：延迟高、配置复杂，无法解决本地调试和磁盘打爆问题
- 在catch块里简单加个静态布尔标记：多线程下失效，且无法区分不同业务场景的同一异常类型
配合重试机制的设计建议
日志幂等性需与重试行为对齐：
- 明确区分“可重试异常”与“不可重试异常”：后者必须每次记录，前者才启用幂等逻辑
- 重试间隔递增时（如指数退避），在指纹中纳入“当前退避时长”作为因子，避免因等待时间不同被误判为新异常
- 若重试跨线程（如提交到线程池），需确保指纹生成逻辑线程安全，且上下文标识（如TraceID）能正确透传
