核心要点
当故障不产生任何报错（静默失败）时，不再执着于"找报错日志"，转而核查"成功本该留下的痕迹是否存在"——用记录的缺席作为证据定位故障环节。
一句话记忆：不找报错，找"缺席的成功"。
落地四步
- 适用前提：功能不工作，但日志里没有对应报错。常见于授权类、回调类、配置静默失效、定时任务未执行。
- 思维翻转：
传统问法：日志里有没有报错？ → 没有 → 误判"这块没问题" ❌
本方法 ：成功时应该留下什么痕迹？ → 一条都没有 → 该环节从未成功 ✅- 为什么有效：报错是"系统知道自己错了"，而静默失败是"系统根本没走到那一步"。后者不会留下错误，只会留下空白。
- 铁律：任何"成功"都必须留下不可磨灭的痕迹。 没有成功日志的功能 = 没有可观测性，故障只能靠猜。
应用场景
| 步 | 动作 | 输出 |
|---|---|---|
| 1 | 画链路：要跑通，必须经过哪几个环节 | 环节清单（含第三方/回调） |
| 2 | 问"成功长什么样"：每个环节正常时，日志或数据里应留下什么 | 每环节的"成功痕迹"定义 |
| 3 | 查痕迹是否存在：不是找报错，是找缺席的成功记录 | 逐环节 ✅/❌ |
| 4 | 谁缺席，谁是嫌疑点——哪怕它"一直没报过错" | 定位结论 |
实战案例（美团核销，2026-09）
- 场景1：第三方授权/鉴权类功能失效（本次美团核销授权）
- 场景2：回调接口从未被调用（支付回调、消息推送）
- 场景3：定时任务/消息消费"看着在跑"实际没执行
- 场景4：改完配置仍不恢复——怀疑存在第二个独立故障时
常见误区
| 环节 | 应有的成功痕迹 | 实际 | 结论 |
|---|---|---|---|
| Redis 连接 | 连接成功日志 | ❌ AuthenticationFailure | 明确故障 |
| 美团授权 | 授权调用日志 | ❌ 一条都没有 | 从未成功（潜伏缺陷） |
前 6 天一直在 Redis 方向找"报错"，第 7 天靠"授权日志空集"破局。完整过程见 美团核销失败故障复盘-20260901。
关联概念
→ 正确做法：没报错只说明它没报错；要确认它有"成功记录"才算过
→ 正确做法：*"改对了却没好，八成不止一个错"*——明摆着的根因修好后仍失败，立即怀疑第二个独立故障
→ 正确做法：链路每一跳都要能取证，尤其是外部回调
- 误区1：日志没报错 = 这个环节没问题
- 误区2：只在当前怀疑的方向上深挖
- 误区3：只查应用日志，忽略网关/服务端/第三方侧记录
排查指引
- 美团核销失败故障复盘-20260901：本方法的来源案例（双故障叠加）
- 美团券核销Session异常处理：方法的应用点（查授权调用日志）
- 抖音券核销失败排查：同类第三方券核销，方法可复用
- 馈赠活动赠券中断排查：同类"POS有流水、后台无记录"的痕迹比对思路
- 功能报错自愈与应用程序池回收：同为"改完没好"场景
可观测性改进（治本）
- 症状：功能不工作，但找不到任何报错
- 画链路，列出全部环节
- 逐环节定义"成功痕迹"
- 查痕迹是否存在 → 缺席者即嫌疑点
- 修复后，确认成功痕迹已产生（而不是"不报错了"就算好）
变更日志
对排查中发现的"无痕迹环节"，补上成功日志/拨测/告警，使下次同类故障自动暴露而非人工发现。
正文
- 2026-09-07：自 美团核销失败故障复盘-20260901 提炼为通用方法卡