北京
删掉一个"没用"的字段，测试全绿，部署成功。然后用户的App闪退了。
这不是代码bug。这是边界处的假设崩塌。
服务端视角看，清理customer.email是 harmless 的优化。但客户端可能拿它渲染收据页、驱动导出流水线、甚至作为生成式SDK的必填项。两边都没错，只是沉默地断裂了。
问题出在测试的盲区。我们花了大量精力验证业务逻辑、数据库状态、请求处理——全是服务内部的正确性。但客户端依赖什么？字段存在性、类型稳定性、错误码格式、分页结构、幂等响应行为——这些藏在边界处的契约，传统测试根本碰不到。
契约测试（Contract Testing）就是堵这个口子。它不问你"代码对不对"，只问一件事：我们改没改客户端依赖的东西？
典型的破坏性变更：删字段、改类型、加必填入参、换错误格式。通常安全的：加可选字段。但注意"通常"——真正的系统里，行为比结构更致命。OpenAPI的schema diff能抓结构变化，却抓不到"这个错误码从400变成422导致重试逻辑失效"这种细节。需要的不只是schema，而是带实例的、可执行的预期。
大多数API事故的本质，不是代码失败，是边界假设的失败。契约测试的价值，是让这些假设在发布前显形，从"惊喜"变成"决策"。
内部的小改动，正在外部制造安静的灾难。而安静，是最贵的bug。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
