你的测试全绿了，但API契约可能已经崩了

7000行测试用例全绿，线上却炸了——这种事儿你遇到过吗？

最近有人在Medusa电商框架的升级里挖到一个经典坑：从v2.13.6升到v2.14.0，所有测试绿灯放行，但API响应里悄悄多出来一个email字段。没人报错，没人预警，直到有人把真实流量录下来对比才发现。

这事儿暴露了一个被忽视的盲区：UI测试通过，不等于背后的API契约没动。

一图看懂问题在哪

常规的测试金字塔长这样：

UI层测的是"用户能不能点"、集成层测的是"数据对不对"，但中间那层"响应结构变没变"经常没人管。具体到这次案例，GET /admin/orders/{id}/preview这个接口在v2.14.0里突然返回了email字段，而v2.13.6没有。

追源码发现，previewOrderChange方法的select数组里多了一个"email"字符串。就这一个token，让响应结构变了形。

更微妙的是：这个字段本来就在订单实体里存在，只是之前这个接口没把它捞出来。现在捞了，但发布说明、变更日志、迁移指南里都没提。

为什么现有测试没逮住

三层防护全失效，各有各的死角：

UI测试只看页面显没显示email，那个页面本来就没展示这个字段，自然不报。

底层测试用了Mock，测的是假数据不是真响应， wire上的变化根本看不见。

集成测试的断言写的是"要有id、要有total、要有items"——只验存在性，不验排他性。多出来的字段？不管。

严格的全量schema检查确实能防，但维护成本高、噪音大，大多数团队不会在每个接口上这么干。结果就是"全绿"成了幻觉。

多加一个字段算破坏吗

这要看谁在消费你的API。

宽松的JSON解析器确实会忽略未知字段，但生成式客户端、严格解码器、移动App、合作伙伴系统、分析任务链可能直接抛异常。对它们来说，"只加不改"也是变。

这次实验用的方法很简单：同一套UI流程跑两遍，录下浏览器产生的API流量，对比JSON响应。不是正式的契约测试，更像是问一句：真实用户走这条路，两个版本的底层通信变了吗？

答案有时是：变了，而且没人知道。