企业查询数据中台上线前，我给它做了一轮专项审计，修了 15 个问题。其中最让我后怕的不是会报错的那些，而是下面这 5 个——它们不报错，只是安静地给出错误的结论。
1. 把“猜测”存成了“答案”
按企业名称模糊搜索时，系统取候选列表的第一条，并把“搜索词 → 企业”的对应关系写进了别名表。之后再用同一个词查询，会直接命中缓存，返回那家企业，而且永远不再向上游核实。
一个猜测就这样被包装成了确定答案。修复很简单：只有精确类接口才允许写别名，模糊搜索一律不写。
2. 自己拦掉的请求，算成了上游的失败
上游失败率的统计口径是“没命中缓存且调用失败”。但被我们自己的风控拦掉的请求，恰好也满足这两个条件。
结果是：某个子公司一轮超频调用，就能把“上游失败率”顶到 100%，触发虚假的故障告警，甚至误熔断一个完全健康的数据源。统计时必须把鉴权失败和限流排除出去。
3. 没配置通知渠道，界面却显示“已发送”
告警发送函数在渠道未配置时返回了一段提示文字，而判断是否成功的逻辑只检查这段文字里有没有“失败”两个字。于是界面显示“已发送”，实际上一条都没推出去。
修复后改成结构化的三种状态（示意代码）：
// 之前：字符串里没有“失败”就当成功
const allOk = !result.includes('失败');
// 之后：明确区分三态
// sent 已发送
// failed 发送失败
// undelivered 未送达（未配置渠道）4. 重试了两次，配额只扣了一次
配额在重试循环外面只扣一次，但循环里每次重试都会真实地再调一次官方接口。长期下来，中台记录的用量比实际少，真到上限时是上游先报错，看板上却显示还没用完。
正确做法是 按真实的外部调用次数逐次扣减，全部失败时再全额退回。
5. 监控本身成了成本
最初我想给上游做真实探活。后来意识到：每一次探活都是一次计费调用，监控做得越勤，花的钱越多。
最后的方案是上游只做配置态检查，健康状况由真实业务调用的成功率来反映。
小结
这几个问题都通不过一条朴素的检验：把几个口径加起来，对不对得上总数？ 缓存、穿透、拦截三态之和必须等于总调用量；中台记的用量必须等于上游账单。写自动化测试时，我后来专门加了这类“对账”用例。