你有没有遇到过这种情况：同一个公司里，三个团队开发的 API 返回的数据长的完全不一样？一个用 camelCase，一个偏爱 snake_case，还有一个干脆全小写带中划线。前端同事拿到数据第一件事不是写逻辑，而是先写个转换函数——这哪是调接口，简直是做语言翻译。
不统一格式的代价，比你想象的大
看起来只是字段命名风格不同，但这种“自由发挥”会在项目扩大时带来真实成本。新来的开发者光看返回结构都得琢磨半天：这个接口的错误码在 error 字段，下一个却藏在 code 里，第三个干脆用 HTTP 状态码加正文混合判断。调试时间翻倍，文档写得再全也挡不住实际使用时的混乱。
更别说前后端联调时，因为某个字段是 user_name 还是 userName 争执不下，最后靠截图聊天记录来确认。这种低级问题消耗的是整个团队的协作效率。
统一格式不是搞“一刀切”，而是建立共识
统一格式不等于死板。你可以规定：所有响应体外层结构保持一致，比如：
{
"code": 0,
"message": "success",
"data": {
"userId": 123,
"userName": "zhangsan"
}
}这样无论哪个接口，前端都能用同一套逻辑处理成功和失败。即使业务数据不同，外壳结构稳定了，消费方就能写出通用的拦截器和错误提示机制。
命名风格也可以投票决定。选 camelCase 就全都用 camelCase，选 snake_case 就坚持到底。关键是别今天一个样，明天又换一套。
例外情况怎么办？留点弹性空间
有些场景确实需要特殊处理。比如对接第三方支付，对方返回的就是全大写下划线，这时候硬转成小驼峰反而容易出错。这种可以直接透传，但要在文档里明确标注“此接口为外部映射，格式不同”。
内部系统之间，哪怕技术栈不同（Java 后端、Go 微服务、Python 数据分析），只要对外暴露的 API 都遵循同一套格式规范，协作就会顺畅很多。就像城市里的路牌，就算建筑风格各异，但指示系统统一，就不会迷路。
见过太多项目初期图省事，觉得“能跑就行”，结果半年后光是维护接口兼容性就占了三成开发量。统一格式一开始多花十分钟定规则，后期能省下几十个小时的沟通和返工时间。