平时对接接口我们都默认前端传过来的字段是唯一的、干净的。解析参数、绑定实体、执行业务逻辑整个过程不会做任何重复字段校验。绝大多数开发压根不会考虑同一个请求里会出现两次一模一样的参数字段。这属于认知盲区框架默认帮我们处理了久而久之没人在意这种边界情况。但线上真实场景里这种异常请求确实存在而且会引发非常诡异的数据错乱。之前线上遇到过几次无厘头的参数赋值错误前端说只传了一个值后端接收出来的数据完全不对两边核对日志耗时很久最后才查到根源是参数重复传入导致的解析异常。不同请求格式重复参数的处理逻辑完全不一样。最坑的是JSON请求体。很多人以为JSON天然不允许重复key实际线上通过篡改请求报文、特殊工具发包完全可以构造出重复字段的JSON结构体。主流解析框架在遇到重复key时不会抛错、不会告警默认直接覆盖原值。大部分情况下是后传的值覆盖前面极少数版本会反向覆盖完全没有统一标准。这就导致一种随机Bug同样的接口、同样的参数偶尔赋值正确、偶尔数据被篡改没有任何规律可言。这种问题本地极难复现。正常前端打包、接口调试工具都会自动过滤重复字段不会生成非法请求报文。只有线上恶意请求、老旧客户端、第三方异常回调才会触发这类问题。很多项目因此出现过少量用户数据异常、状态莫名变更、表单提交内容错乱的问题最后都不了了之没人定位到是参数重复解析导致。还有一个很隐蔽的场景参数大小写混写叠加重复字段。部分客户端传参不规范同一字段大小写交替出现同时存在多个相似key。框架解析时区分大小写会同时读取多个字段赋值错乱导致最终参数拼接完全偏离预期。业务代码本身没有任何问题所有逻辑都是按正常参数执行输入数据本身被污染最终输出结果自然出错。更麻烦的是日志记录的盲区。很多项目的请求日志是解析完成后打印的参数并不是原始报文。即便原始请求存在大量重复字段日志里也只会展示最终解析完毕的有效值。这就导致排查问题时日志参数完全正常根本看不出原始请求存在异常彻底断掉排查线索只能盲猜问题。经历过这类问题之后才发现我们平时依赖的框架自动解析本身存在很多隐性容错逻辑。框架为了保证请求不报错默默兼容了各种非法参数、重复字段、异常格式表面上服务平稳运行实则悄悄篡改了输入数据。很多看似无解的线上偶现Bug不是代码逻辑漏洞而是过度兼容带来的副作用。现在做接口校验除了常规的非空、长度、格式校验我会针对性做参数唯一性校验。对核心业务接口直接拦截非法重复参数宁可拒绝请求也不接受框架自动兼容的脏数据。接口稳定性很多时候就是靠这些没人关注的微小边界细节堆出来的。