camelCase 怎么转？小驼峰的规则与四个常见坑

小驼峰（lowerCamelCase）第一个词小写，后面每个词首字母大写，中间不留分隔符。它是 JavaScript 变量和多数 JSON 字段的默认写法，也是把接口字段对齐时最常改的一层。

什么时候需要批量转成小驼峰

后端返回 user_name，前端要用 userName；设计稿的字段叫 User Name，接口文档写 userName，三处写法各不相同。改三五个字段手敲没问题，几十个字段连着手改，漏一个就会在运行时报 undefined，而且很难一眼看出来。

另一种场景是从表格生成代码：Excel 表头、CSV 列名、数据库注释里的中文或英文短语，要变成一批变量名或接口字段。先统一转成小驼峰，再人工过一遍缩写和数字，比逐个手敲稳定得多。

规则只有两步：整段先转小写，然后把「连续的非字母数字字符加紧跟的一个字符」替换成大写。空格、短横线、下划线、点号、括号都属于非字母数字，会被直接吃掉。所以 user profile、user-profile、user_profile 三种写法都会得到 userProfile。

坑在于它不识别驼峰边界。输入本来就是 userProfile，转小写后没有任何分隔符可依，结果会被压平成 userprofile。同理 userID 会变成 userid，APIKey 变成 apikey，缩写的大小写信息全部丢失，需要转完再手动改回来。

规则只有两步：整段先转小写，再把「连续的非字母数字字符加紧跟的一个字符」替换成大写。空格、短横线、下划线、点号、括号都会被直接吃掉，所以 user profile、user-profile、user_profile 三种写法都得到 userProfile。

所以工具给的只是候选名，最终以项目里的 lint 规则为准，例如 ESLint 的 camelcase 规则或 PEP 8。同一个项目里两种风格混用，比选错一种更难维护。它也不会替你决定 getHTTPResponse 还是 getHttpResponse，这类缩写约定通常写在团队规范里。

camelCase 和 PascalCase 有什么区别？

camelCase 首字母小写，如 userName；PascalCase 每个词都大写，如 UserName。JavaScript 的变量和方法多用前者，类、组件和类型多用后者，选择取决于语言和团队规范，两者没有对错之分。

为什么我的 userProfile 转换后变成了 userprofile？

因为转换先把整段转成小写，再按非字母数字字符断词，而 userProfile 里没有这类分隔符，驼峰边界不被识别，于是整串被当成一个词。想保留分词，请先写成 user profile 或 user_profile 再转换。

JSON 字段为什么有时是 camelCase 有时是 snake_case？

这是各语言和各家接口的历史约定不同。JavaScript 生态习惯 camelCase，Python 和 Ruby 生态、以及 Stripe 等接口习惯 snake_case。对接时按对方文档来，不要在一套接口里混用两种写法。