camelCase 怎么转下划线？14 种命名格式与三个会丢字符的坑

把 camelCase 转成下划线不用手改：贴进大小写转换工具，结果里「蛇形命名（snake_case）」那一行就是 user_login_count，「常量命名（CONSTANT_CASE）」那一行是全大写的 USER_LOGIN_COUNT。反方向也一样，输入 USER_LOGIN_COUNT，驼峰行直接给 userLoginCount。

工具页面写的是「输入任意文本，实时查看 14 种命名风格的转换结果」，下面 14 行结果随输入即时刷新，每行右侧有复制按钮。所有转换都在浏览器本地完成，输入的内容不上传服务器。

本文的每个输出都来自 2026-11-09 14:36 的同一次运行，截图与正文数字同源。

14 种格式各是什么，用在哪

以 userLoginCount 为输入，14 行结果的实测输出如下：

格式（页面标签）	实测输出	常见用处
小写 Lowercase	userlogincount	大小写不敏感的键、邮箱地址
大写 Uppercase	USERLOGINCOUNT	展示文本，不适合做标识符
驼峰 CamelCase	userLoginCount	JS / Java 的变量与对象属性
首字母大写 Capital Case	user Login Count	句子里嵌标识符
常量 CONSTANT_CASE	USER_LOGIN_COUNT	环境变量、配置常量
点分隔 dot.case	user.login.count	properties 这类层级配置项
标题 Header-Case	User-Login-Count	HTTP 头名、部分代码规范
空格分隔 no case	user login count	给人看的展示文本
参数 param-case	user-login-count	URL 参数、CSS 类名
帕斯卡 PascalCase	UserLoginCount	类名、前端组件名
路径 path/case	user/login/count	路由片段、层级路径
句首大写 Sentence case	User login count	标题、句子开头
蛇形 snake_case	user_login_count	Python 变量、数据库字段
交替大小写 aLtErNaTiNg	UsErLoGiNcOuNt	仅作演示

有一点容易看错：首字母大写不是帕斯卡。它的第一个词是小写（user Login Count），只有第二个词往后才首字母大写。要写类名或组件名，用帕斯卡那一行。

下划线转驼峰、常量转驼峰：同一个输入一起给

粘 USER_LOGIN_COUNT 进去，三种最常用的结果同时出现：驼峰 userLoginCount、帕斯卡 UserLoginCount、参数命名 user-login-count，蛇形和常量两行保持原样。所以数据库字段名、环境变量名要转成前端属性名时，一次复制就行，不用来回切。

坑一：全大写缩写被抹平，而且转不回去

输入 userID utf8 HTTPServer，实测结果：

格式	实测输出
驼峰 CamelCase	userIdUtf8Httpserver
帕斯卡 PascalCase	UserIdUtf8Httpserver
常量 CONSTANT_CASE	USER_ID_UTF_8_HTTPSERVER
蛇形 snake_case	user_id_utf_8_httpserver
标题 Header-Case	User-Id-Utf-8-Httpserver

原因在切词规则：它只在「小写字母紧跟大写字母」的位置断开。ID、HTTP 这类全大写连写里没有小写字母，不会被单独切成一个词，于是 HTTPServer 整段被当成一个词，再按「首字母大写、其余小写」处理就成了 Httpserver。

这一步是不可逆的：把 httpserver 再粘回去，任何一行都不会变回 HTTPServer。所以拿它批量改含缩写的标识符要小心——HTTPClient、userID、parseXML 这类名字改完会丢大写信息，得人工过一遍，或者按项目约定先把缩写统一成 Http、Id 这种写法。

坑二：数字会被切开，驼峰与蛇形对不上

同一个 utf8，在两种格式里给出的结果不一样：

• 蛇形：user_id_utf_8_httpserver（utf 与 8 分成两段）
• 驼峰：userIdUtf8Httpserver（utf8 连在一起）

这是切词阶段在字母与数字之间、数字与字母之间插了分隔造成的：utf8 被拆成 utf 和 8，带下划线和点号的格式会把这个分隔显出来，驼峰和帕斯卡因为没有分隔符，又合回去。

后果是接口联调时字段名对不上：后端按蛇形命名导出 utf_8，前端按驼峰取 utf8，两边看着都「转换对了」，实际拼不到一起。凡是带数字的标识符（版本号 v2、base64、sha256 这类），转换后都要核对一遍分段位置，别只看字面像不像。

坑三：中文被当成分隔符，整段丢掉

输入 网站标题 test，14 行结果里 11 行只剩 test：

格式	实测输出
驼峰 CamelCase	test
常量 CONSTANT_CASE	TEST
蛇形 snake_case	test
帕斯卡 PascalCase	Test
小写 Lowercase	网站标题 test
大写 Uppercase	网站标题 TEST
交替大小写	网站标题 tEsT

因为那 11 种格式先按拉丁字母和数字切词，中文不在这个范围内，会被当成分隔符一起丢掉，而不是报错或提示——输出看着正常，字符却少了。

所以这个工具适合处理纯英文标识符，不适合拿来整理中文标题或中英混排的文本。只有小写、大写、交替大小写三行是对整串字符逐个处理，中文会原样保留。

交替大小写不按词处理

其余 13 种格式都是先切词再拼，交替大小写是逐字符处理的：USER_LOGIN_COUNT 得到 UsEr_lOgIn_cOuNt，下划线原样不动，字母每隔一个转大写；userLoginCount 得到 UsErLoGiNcOuNt。它主要用来做效果演示，不适合当命名格式用。

什么情况下别用它

• 改变量名、函数名：用编辑器的重命名重构。这个工具只改字符串，不会改引用，而且缩写信息会丢（见坑一），改完还得人工核对。
• 中文或含非拉丁字符的文本：11 行结果会静默丢字符，别拿它做标题美化。
• 要严格符合某套命名规范：工具给的是形式，缩写怎么写、数字怎么分段，得按项目规范（比如 Python 的 PEP 8 推荐蛇形命名、Java 常量用全大写）人工确认，工具不替你做合规判断。

纯英文、无缩写的标识符，它是最好用的一档：一个输入框，14 种格式同时给全，复制即用。