一、五种常见风格
| 风格 | 示例 | 常见场景 |
|---|---|---|
| camelCase（小驼峰） | userName | JS/Java 变量、方法名 |
| PascalCase（大驼峰） | UserName | 类名、React 组件名 |
| snake_case | user_name | Python 变量、数据库字段 |
| kebab-case | user-name | CSS 类名、URL、HTML 属性 |
| SCREAMING_SNAKE | MAX_RETRY_COUNT | 常量、环境变量 |
命名风格本身没有优劣，重要的是同一层内保持一致。混乱的命名比「选错了风格」更麻烦。
二、语言与生态的默认习惯
- JavaScript/TypeScript：变量和方法用 camelCase，类和组件用 PascalCase，常量用 SCREAMING_SNAKE。
- Python：变量和函数用 snake_case，类用 PascalCase，常量用 SCREAMING_SNAKE（PEP 8）。
- Java：变量和方法 camelCase，类 PascalCase，常量 SCREAMING_SNAKE。
- Go：导出用 PascalCase，非导出用 camelCase，缩写在命名中保持全大写（
HTTPServer）。 - SQL：表名和字段 snake_case 最常见（也有团队用 PascalCase）。
- CSS：kebab-case，BEM 风格如
block__element--modifier。
三、缩写的处理最容易乱
user id 转驼峰，是 userId 还是 userID？常见约定：
- 普通风格：
userId、htmlParser、httpClient（缩写当普通单词）。 - Go 风格：
UserID、HTMLParser、HTTPClient（缩写全大写）。 - Java 老代码：
userID也常见，但新规范倾向userId。
转换工具通常按「每个单词首字母大写」处理，得到 UserId，而不是 UserID。跨语言对接时这类差异会导致字段名对不上，需要在映射层显式处理。
四、数字与连续大写
user2name→user2Name（数字后视为新词）parseHTMLString→parse_html_string（连续大写要拆开）XMLHttpRequest→xml_http_request
拆分连续大写是转换的难点：HTTPServer 应拆成 HTTP + Server，而不是 H + T + T + P + Server。手工转换容易出错，批量处理建议用成熟库（如 lodash 的 camelCase、Python 的 inflection）。
五、前后端字段映射
最常见的实际需求：数据库 user_name ↔ 前端 userName。
三种做法：
- 手动映射：每个 DTO 写
@JsonProperty("user_name")，明确但繁琐。 - 全局策略：Jackson 配
PropertyNamingStrategies.SNAKE_CASE，Spring Boot 里一行配置搞定。 - 约定统一：接口全部用 snake_case，前端在请求层统一转换。这样后端不用改，前端只写一次转换逻辑。
推荐第 2 或第 3 种，避免每个字段都手写。但要确认所有消费方都遵守同一约定——移动端、第三方接入方往往是漏网之鱼。
六、URL 与文件命名
- URL 路径用 kebab-case：
/user-profile、/json-format.html。 - 文件名同理：
user-profile.html比userProfile.html对搜索引擎更友好（词边界清晰）。 - 不要用空格和中文（会被 URL 编码成一长串
%E4%B8%AD）。 - 大小写敏感：Linux 服务器上
User.html与user.html是两个文件，本地 Mac（默认不区分）能跑、上线 404，是经典事故。
七、批量转换的注意
- 先小样本验证，尤其是含缩写、数字、连续大写的名字。
- 保留原值备份，转换不可逆（
userName无法判断原本是user_name还是username）。 - 注意冲突：
user_name和userName转换后可能撞名。 - 别改外部契约：已经发布的 API 字段名不要随意改，会影响所有调用方。
八、工具
单次转换用 命名风格转换工具，支持驼峰、下划线、短横线、常量多种格式互转；批量整理代码时配合 代码格式化。
小结
变量驼峰、类大驼峰、数据库下划线、CSS 短横线、常量全大写；缩写处理要团队约定；前后端字段映射用全局策略而不是逐字段注解；URL 和文件名用 kebab-case 且全小写。