大小写与命名规范：camelCase 怎么转

一、十种口径，同一个概念

命名法就是「多个单词如何拼成一个标识符」的约定。以 hello world font-size 为例，十种转换实测：

命名法	结果	典型用途
camelCase	helloWorldFontSize	JavaScript、Java 变量与方法
PascalCase	HelloWorldFontSize	类名、React 组件、C# 方法
snake_case	hello_world_font_size	Python、Ruby、数据库字段
kebab-case	hello-world-font-size	CSS 类名、URL 路径、HTML 属性
CONSTANT_CASE	HELLO_WORLD_FONT_SIZE	常量、环境变量
Title Case	Hello World_font-size	标题
sentence case	Hello world_font-size	句子
UPPER / lower	全大写 / 全小写	规范化、比对
toggle	大小写互换	快速翻转

转换的原理是「先按分隔符与大小写边界切词，再按目标规则拼接」：world_font-size 里的下划线与连字符都会被当作分隔符处理。

二、各语言为什么约定不同

不是审美问题，而是语法限制与历史惯例：

• CSS 类名与 URL 不能用驼峰以外的方式表达空格：URL 大小写敏感但习惯小写，CSS 选择器历史上也偏好连字符，所以 kebab-case 成了标准；
• Python 用 snake_case：PEP 8 的明确规定，变量与函数小写下划线、类名 PascalCase；
• Java/JavaScript 用 camelCase：变量小写开头、类名大写开头，靠首字母区分实例与类型；
• 常量全大写：视觉上一眼区分「不可变的值」。

跨语言移植代码时命名转换是最机械也最容易出错的环节——手动改 20 个字段名，漏一个就是运行时错误。批量转换工具的价值就在这里。

三、转换的边界：工具猜不了的部分

实测一个细节：hello world_font-size 转 Title Case 得到 Hello World_font-size——下划线与连字符后的内容没有被拆开。

原因：工具无法确定 world_font 里的下划线是分隔符还是内容本身（文件名 my_file_v2.txt 里就不是）。规则是「空格肯定断词，其他分隔符保守处理」。

所以批量转换后必须抽样检查，尤其是：

• 缩写词：parseHTMLString 转 snake_case 可能变成 parse_h_t_m_l_string；
• 连续数字：v2User 的 2 会不会独立成词；
• 已有分隔符：font-size 里的连字符是保留还是并入。

四、不只是变量名：这些场景都用得上

1. 数据库字段对接：接口返回 camelCase，数据库是 snake_case，写转换层时批量处理；
2. CSS 与 JS 联动：JS 里 element.style.backgroundColor（camelCase）对应 CSS 的 background-color（kebab-case）——这是前端最经典的命名转换需求；
3. 环境变量与配置：DATABASE_URL（常量式）对应代码里的 databaseUrl；
4. 文档标题规范化：批量把标题转成 sentence case 或 Title Case。

五、转换前后的文本检查

批量转换前建议先做两件事：

• 统计文本结构（字符数、汉字数、行数、段落），确认输入完整——转换工具通常不会替你发现「粘贴时少了半段」；
• 统一换行符：CRLF 与 LF 混合会让逐行处理的工具把同一行判成两行。

处理完之后再跑一遍字数统计对比前后是否一致——字符数变了就说明有内容被吞了。

六、直接算

→ 大小写与命名转换：十种命名法互转，含 camel/snake/kebab/constant

→ 文本处理工具：转换前后的文本整理与统计

→ 文本差异对比：批量改名后对比前后差异