从PHP数组到前端对象，字段命名风格如何统一

一场由下划线引发的血案

背景无需赘述，每个全栈工程师都经历过这种时刻：点开接口，一堆 user_name、created_at 扑面而来；切到前端，满屏 userName、createdAt 婀娜招展。你复制一个字段，一会儿粘到前端驼峰，一会儿粘到后端蛇形，来回拉扯。

有人觉得这是小事，但真正被字段命名风格折腾过的人都懂——它就像鞋里的一粒沙子，不致命，但走远了真疼。

问题根源：两种生态的基因差异

命名风格之争，本质上是两个不同世界的文化冲突。

PHP 世界，尤其以 Laravel 为代表的框架，数据库列名约定俗成用蛇形命名法（snake_case）。这背后有历史原因：MySQL 在 Unix 系统上对大小写敏感，为了少踩坑，大家干脆统一小写加下划线；同时加了下划线也方便肉眼分隔长字段名，is_verified_user 比 isVerifiedUser 在 SQL 里读起来清晰得多。

而 JavaScript 生态，受 Java/C# 影响深远，驼峰命名法（camelCase）几乎是统治级风格。ESLint 的 camelcase 规则默认开启，interface、类型定义不写驼峰就会收到满屏警告。

两个生态各自自洽，偏偏在 HTTP 层撞上了。

方案一：后端改成驼峰交付

很多团队采纳的思路是：后端在返回时统一格式化，把数据层的蛇形命名字段转换为驼峰交付。

听起来优雅，但落地时全是坑。PHP 里写 $userName 去对应数据库 user_name 列，Eloquent 的 $fillable 和 $casts 得拆开维护，ORM 的自动属性映射也会闹别扭。每加一个字段，你得在两边分别命名，心智负担不是一点点。

更麻烦的是，当 PHP 代码里既有数据库列名 user_name，又有响应字段 userName 时，代码检索容易产生误判。你搜 user_name，发现一半是查询语句，一半是数组转换逻辑，改起来晕头转向。

方案二：前端消费层做软转换

跟前端说“接口就是 snake_case，你们自己转”，这是最常见的现实主义解法。

前端有两种做法。一种是写一个通用的 key 转换器，递归解析 JSON，把 snake_case 统一转成 camelCase 再交给业务组件；另一种是在 model 层做映射，把接口字段逐一映射到前端类型系统的字段上。

软转换的优点是前后端切割干净、互不越界；缺点是踩坑的往往是前端——debug 时打开 Network 面板看原始响应是 snake_case，代码里断点却是 camelCase，每层都要做一次心算映射。TypeScript 类型由于需要定义接口原始类型和转换后的类型，代码开始出现“双份字段定义”的臃肿感。

方案三：干脆全链路 snake_case

也有些团队选择“以毒攻毒”——前端也彻底使用 snake_case。TypeScript interface 里写 user_name: string,组件里用 tableData.user_name,Vue 模板里也直接 user_name。

这种方案和 eslint 默认规则直接冲突，你需要关掉整个项目的 camelcase 规则。团队里的新前端接手时会感到极度别扭——毕竟 JS 社区几乎所有库、组件、示例代码都在用驼峰，你的 schema 长着 PHP 的脸，毫无亲切感。

但你不得不承认，这种方式在前后端都由同一个人维护时的全栈小团队里效率极高：从 SQL 到 PHP 数组到 JSON 到 TS 类型，唯一命名，零转换，搜索字段名时全文命中。

方案四：其实这是整个数据链路的架构问题

写到这里会发现，命名统一不只是一个风格问题，更是整个数据链路的一致性问题。

如果把视野放得更开，下游还有 redis 缓存键、消息队列字段、日志系统、数据分析脚本……这些地方同样存在着字段命名割裂。user_name 走了一遍 userName 再降回 user_name 存到 Redis，就是一次无意义的熵增。

有的团队在 API Gateway 层统一做协议转换，让后端和前端各自保留自己的原生风格，把“翻译”职责集中收口到网关服务。这不失为大型团队的最小心智损耗方案，但对大多数中小体量项目来说，引入一个新服务只为了转字段名，性价比很低。

务实建议：用场景决定策略

如果让我给出一个比较中庸的行之有效的组合拳：

• 数据库字段永远是 snake_case，这是底层约定，不应该被撼动
• 后端响应给前端的接口数据统一转为 camelCase
• 后端的转换代码集中在一个 Resource 或者 Transformer 层，不要让格式转换散落各处
• 前端拿到数据后立刻赋给 typed 变量，不再维护“原始响应体”的中间态
• 不要关 eslint 的 camelcase 规则，让工具帮你堵住漏网之鱼

有些资深前辈还会建议：如果你用的是 PostgreSQL，可以在建表时直接使用 camelCase 加引号，让整套体系从头到尾全部驼峰。但除非你的团队从 DBA 到后端到前端全是一条心，否则不推荐尝试——这等于放弃了整个生态的默认工具链支持。

归根结底，无论选哪条路，最怕的是没有规则。那种“既是 snake_case 又是 camelCase”的项目，通常不是命名风格之争的产物，而是根本没有做过命名决策。

选择一个方向，然后在代码审查里守住它。风格统一本身的收益，远比选哪个风格更重要。