场景：某接口原本需要传 abcd4 个参数，后来服务端改了规则，只接收 a 参数，bcd 不需要了。于是我提了 bug 给前端，请其配合修改，遭拒，曰忙不过来。请问各位，如何从技术角度说服其修改？
- 这是不是 bug ？
从楼主的描述来看，是后端改了接口的参数规则。 一般这种修改是属于需求变更，需求变更里应该也要考虑接口调用方的修改。
因此我觉得不属于 bug ，是需求变更。 要么在需求评审的时候提出来，要么在事后提给产品，由他去推动完善他的需求。 - 如果开发不配合修改 bug ，怎么办？
这应该是面试时很大机会问到的老问题吧？ 一般的答案： 按流程沟通，如果不配合，由开发上级或需求沟通决定。 - 现实中的具体问题具体分析
- 后端为什么要修改这个接口？ 会不会现在暂时不接收，以后会重新接收 BCD ？ 从设计角度看，前端是有保留这几个参数的可能的。 毕竟后台改规则相对简单，重新部署就行了； 而前端的规则如果发生改变，需要新增参数，可能会涉及重新出包的流程（如果是 app ）。
- 参数安全性？ 如果涉及敏感信息，就按规定加密；如果只是一个普通信息，可以忽略。
- 要不要刚到底？ 测试人员有原则是好事，但也是要有个度的。 假如 BCD 只是一些无关紧要的信息，说实话暂时不改问题不大，完全没有上升到 “刚” 的层面。 团队需要有一个共同的目的，优先度高的事情是需要先照顾的。
从版本兼容性来看，改的风险比较大。
一般都是只允许加字段，不允许减字段吧？
为功能多传 3 个字段新做一个接口不值得。
多测测版本兼容性，如果没问题，这个我觉得最好不要改。
