单测里 mock 外部依赖的边界到底画在哪：纯 mock 派、Testcontainers 派、影子流量派，你们的线上事故有没有一半是 mock 和真实行为错位埋的？

【背景】 我做了 5 年测试开发，最近一次复盘让我很不安：一个下单链路单测全绿，mock 的支付回调服务返回 200 + 标准 JSON，测试里「支付成功 → 扣库存 → 发券」三步断言全部通过。但线上那次事故是——支付网关在一次发布后，对部分请求返回 200 但 body 是空串（网关侧一个未捕获异常被吞了），我们的 client 对空 body 的解析路径从来没被任何测试覆盖过，直接 NPE 吃掉整批订单，靠对账 T+1 才发现。

复盘会上有句话让我很扎心：「我们 mock 了一个不存在的服务。」mock 不是把外部依赖替掉，而是把一个我们想象中的依赖替掉了——这两件事的差别，可能就是测试绿了、线上炸了的根因。

【常见分歧（我看到的三种做法）】

1. 纯 mock 派：CI 只跑 mock 单测，外部依赖一律 Mockito / WireMock 挡板，追求 1 分钟级反馈；集成测试只在预发手工点。优点是快、稳定、不受环境波动影响；代价是上面那种「mock 行为 ≠ 真实行为」的缝隙，比如超时、空 body、并发竞态、TLS 握手、连接池复用，全都不在 mock 视野里。
2. Testcontainers 派：CI 里起真实的 MySQL/Redis/Kafka 容器，走真实协议。确实抓到了不少 mock 漏掉的边界（SQL 方言、事务隔离级别、消息顺序）；但 CI 时长从 1 分钟涨到 15-20 分钟，flaky 率也上来了，容器网络抖一下整条流水线红一片，工程师开始「先重跑三次」，测试的可信度反而被稀释了。
3. 影子/真实流量派：回放生产流量或做影子链路，最贴近真实，但门槛高（脱敏、环境成本、回放框架），很多团队卡在「想搞但排不上」。

【我的倾向与理由】 我倾向「默认纯 mock + 白名单集成」：不是所有外部调用都值得起真容器，按风险分层——

• 对「数据正确性敏感」的依赖（DB 写、消息发出、外部计费）：必须有至少一条 Testcontainers 级集成测试，覆盖真实协议路径；
• 对「行为敏感」的依赖（会超时、会半成功、会乱序的三方 API）：mock 时必须显式 mock 三种失败形态——超时、非 2xx、2xx+空/畸形 body，这是我现在给团队的硬规约，空 body 那个坑就是这条；
• 其余只读、幂等、无副作用的依赖：纯 mock 够用，别为「真实」付 CI 时长。

还有一个我觉得被低估的点：mock 的「契约」本身要被测试。我们的 WireMock stub 文件是手工维护的，和真实网关的 OpenAPI 之间没有任何对账机制，漂移是时间问题。契约测试（consumer-driven contract）听起来重，但比「出了事再补 case」便宜。

【想听大家】

1. 你们 CI 里 Testcontainers 的占比大概多少？flaky 率有没有量化过？怎么决定一个 flaky case 是「修」还是「降级成手动」？
2. mock 三方服务时，你们有没有「必须覆盖 N 种失败形态」的硬规约？空 body / 超时 / 半成功，哪几种是你们的血泪教训？
3. 纯 mock 和真实集成之间，你们有没有一条清晰的「升级判据」——什么特征的外部依赖，必须从 mock 升级成真容器？
4. 契约测试在你们团队落地过吗？卡在哪（工具、组织、维护成本）？

欢迎把你们的事故案例甩过来，尤其是「测试全绿但线上炸了」的那类——这类帖子我看得比方案帖多得多，因为方案好抄，坑才值钱。