为什么命名很重要
写过接口的人都知道，一个字段叫 user_name 还是 userName，可能直接决定前端同事下班后要不要找你聊聊人生。JSON 作为前后端交换数据的通用格式，字段命名不只是风格问题，它关系到协作效率、维护成本，甚至后期扩展。
想象一下，你接手一个老项目，看到字段里混着 camelCase、snake_case，还有全大写的 ID、Id、id，查文档像破案，这种体验谁都不想要。
常见的命名风格
目前主流有三种写法：
- camelCase（小驼峰）：首字母小写，后续单词首字母大写，比如
firstName、createTime - PascalCase（大驼峰）：每个单词首字母都大写，常用于类或对象名，比如
UserInfo、OrderDetail - snake_case（蛇形命名）：全部小写，用下划线连接，比如
user_name、create_time
在 JSON 中，最常见的是小驼峰和蛇形命名。
JavaScript 偏爱小驼峰
前端开发大多用 JavaScript，而 JS 的变量命名习惯就是小驼峰。如果你返回的数据是 first_name，前端拿到后通常要转换成 firstName 才方便使用，多一步处理就多一个出错可能。
所以很多前后端分离的项目，约定用小驼峰：
{
"userId": 123,
"userName": "张三",
"lastLoginTime": "2024-03-15T10:30:00Z"
}Python 和数据库常用蛇形
后端如果是 Python、Ruby 或 PHP，很多人习惯蛇形命名。数据库字段也普遍用下划线，比如 user_id、
例子：
{
"user_id": 123,
"user_name": "李四",
"created_at": "2024-03-15T10:30:00Z"
}但如果前端是 JS，就得做一层映射，不然代码里出现 data.user_name 就显得格格不入。
统一比风格更重要
与其争论哪种更好，不如团队先定个规矩。哪怕选了个“不太完美”的风格，只要一致，就能减少沟通成本。
建议在项目初期就写进接口文档规范，比如：
- 所有响应字段使用小驼峰
- 布尔值字段以
is、has、can开头，如isEnabled、hasChildren - 时间字段统一用
createTime、updateTime，避免混用time、at
避开这些坑
有些命名看着没问题，实际用起来容易踩雷：
- 别用关键字：比如
class、function，在 JS 里当属性名虽然能用，但解析时可能出问题 - 别用缩写：
usr、cnt这种，别人看不懂，三个月后的你自己也看不懂 - 别大小写混用随意：比如
UserID和userId同时出现，看起来像两个字段
还有，ID 到底写成 id 还是 ID？推荐写成 id 或 itemId，而不是 iD 或 Id，后者在小驼峰里特别别扭。
工具帮你守规矩
人工检查难免出错，可以用工具自动转换。比如后端用 snake_case 存数据，通过序列化库（如 Python 的 Pydantic）自动转成 camelCase 输出；或者前端用 Axios 拦截器统一做字段映射。
这样两边各守其规，数据也能对上。
实际场景怎么选
如果团队主攻前端，或者用 React/Vue 这类框架，优先用小驼峰。如果后端是 Python + Django 或 Ruby on Rails，且接口也供内部服务调用，蛇形也没问题。
关键是：别让同一个系统里同时存在两种风格。看到一会儿 user_name，一会儿 phoneNumber，就像看到一行字一半宋体一半黑体，难受。