有些故障是监控先知道的有些是用户先知道的。这次是客户在群里问了第三遍注册页面转完圈账号在哪里我们才反应过来注册功能已经坏了若干天而后端日志里一条报错都没有。复盘下来这不是某一行代码写错了而是前后端的字段契约在多轮迭代里慢慢漂移漂到某一天对不上了中间没有任何人收到通知。这篇文章把整条漂移链摊开讲它是怎么一步步漂过去的为什么监控和测试都没拦住以及怎么用低成本的手段把契约重新钉死。## 现象提交返回正常账号没有出现客户的操作流程完全正常输入手机号收验证码点提交页面提示注册成功。然后问题来了——用这套凭据登录提示账号不存在。自己复现了一遍抓包看注册请求响应状态码是 200响应体也没有报错结构但翻数据库新行没有出现。也就是说服务端成功地什么都没做。这类200 但没落库是排查里最难受的形态因为常见的错误监控全部失明没有异常堆栈没有 5xx没有超时只有一条普通的成功响应和一个没发生的写入。## 根因一前端删掉的字段后端还当它是必填先把服务端注册入口的代码翻出来答案就在那里。这套系统的账号体系早期是用户名加密码后来产品上决定手机号即账号简化注册流程。前端很干脆把用户名输入框删掉了服务端的注册接口却还留着老校验用户名必填长度三到三十二个字符。新用户提交的请求体里没有用户名服务端校验直接拒绝。更隐蔽的是拒绝的方式这个接口的历史习惯是把业务错误包在 200 响应体里返回前端只在特定错误码上弹提示这类校验失败的错误码恰好不在渲染清单里。于是三个环节各自看起来都没坏——前端正常提交服务端正常校验前端正常不提示——拼在一起就是一条完整的断路。为什么测试环境没抓到翻用例才发现注册模块的老用例还是按用户名加密码的表单写的填齐所有字段走老路径全绿。不带用户名的新路径一个用例都没有。用例是跟着界面走的界面删了字段用例没删测试就保护了一个已经不存在的世界。## 根因二同一个概念两套字段名排查期间顺手又抓到一桩同类问题邀请码。产品有邀请注册机制前端在注册请求里带上邀请参数字段名叫 ref服务端读的字段名叫 referralCode。两个字段名都对各自团队有意义拼在一起就是永不对上。这个问题的后果比注册坏掉轻但性质更值得警惕邀请关系从功能上线起就没有建立过被邀请来的新用户几乎全部被记成了自然流量。它存活的时间比注册问题长得多因为邀请字段是可选的缺了不报错没有任何失败路径会暴露它。可选字段的静默失配可以活几个月它不出错只是悄悄地什么都不做。## 根因三注释里的可选是假的继续顺着账号链路往下查还有一层。某个云端同步接口对一个标识字段做了字符白名单校验代码注释写着该字段可选。但真正的同步消费路径把这个字段当必填用缺了它下次登录时静默失败。于是整体呈现变成注册得了下次登不上——这比注册不了更糟用户会把两次问题叠在一起算总账。这件事的教训写在备注里注释不是契约。一个字段是不是可选不由生产它的那端声明由消费它的那条路径决定。谁在运行时读这个字段、缺了会不会挂谁的定义才是真的。## 修法把契约钉进测试里修复本身不复杂复杂的是让同类问题不再有藏身处。字段对齐先做掉手机号必填写成显式规则用户名降级为可选的显示名缺省时取手机号后四位生成邀请参数两端收敛成同一个名字那个假可选的标识字段按消费路径的真实要求改成注册时必生成。然后用例补上真实路径端到端用例按新用户零历史状态走——不带任何遗留字段提交注册然后立刻用同一套凭据登录中间不重放、不共享会话。注册和登录拆成两个独立用例是抓不住这类漂移的因为断点恰好落在两次请求之间。再加一道对账观测注册漏斗上放两个计数器提交数和落库数。两个数的差超过阈值就告警。200 但不落库这类事靠状态码监控永远发现不了靠对账一抓一个准。## 泛化契约漂移的三个高发位复盘完这一串值得把契约漂移常发位置记下来。一端改名另一端没跟多发生在重构和字段语义升级时可选与必填的不对称两端对缺省的理解不一致各自都觉得自己没义务处理注释当文档字段的真实语义在消费端代码里注释只是某个时刻的心情。对应的三道保险也都不贵接口字段定义单源化两端从同一份定义生成改名必须动源头端到端用例覆盖零配置新用户的完整旅程关键漏斗放提交数对落库数的差值告警。## 小结契约漂移这类故障有个共同的长相不报错只产生看起来能用的假象。抓它的手段不是异常监控而是对账思维——提交了多少落库了多少客户端在调什么服务端有什么几组数字和清单互相一对裂痕自己就露出来了。字段单源、真实旅程用例、漏斗差值告警三样加起来不到一天的工作量换来的是这类静默断路从几个月的存活期压缩到一次构建的时长。## 参考文章- 微信自动回复软件怎么配置从零到接客的完整步骤- 微客AI 入门指南注册到接客的路径