前端开发中那些让人头疼的命名规范实战经验分享
设计师娜娜命名这事儿，真不是随便起个名就完事
我写前端写了快十年，踩过的坑里，有一大半和命名有关。变量叫 a、函数叫 handle、组件叫 Box……改代码时自己都认不出是谁写的。后来团队规模大了，协作多了，命名混乱直接导致沟通成本飙升。所以这几年我对命名规范特别敏感，也试过好几种主流方案。今天就来聊聊几个常见套路，说说我为啥最后选了其中一种，以及你可能也会踩的坑。
驼峰（camelCase）：老熟人，但容易“驼”过头
这是最经典的 JavaScript 风格，React 项目里满地都是。比如：
const userProfile = fetchUserProfile();
function handleButtonClick() { /* ... */ }优点很明显：JS 原生支持，IDE 自动补全友好，读起来也顺。我早期几乎全用它，尤其是写业务逻辑时，感觉很自然。
但问题出在“边界模糊”。比如组件名该用驼峰还是帕斯卡？状态字段呢？API 返回的字段又是下划线（因为后端用 Python/PHP），这时候就得手动转换：
// 后端返回 { user_name: "张三" }
const { user_name } = response.data;
// 我们想用 camelCase
const userName = user_name;或者用工具批量转换，但一不小心就漏了，调试时发现某个字段是 user_name 而其他是 userName，心态直接崩。更别说团队新人如果没统一规范，有的写 getUserInfo，有的写 fetch_user_info，代码库像打补丁的裤子。
短横线（kebab-case）：CSS 的亲儿子，JS 里却是个“残疾”
HTML 和 CSS 里，kebab-case 是王道：user-profile、main-container。语义清晰，还能直接当 class 名用。
<div class="user-profile-card"></div>.user-profile-card {
border: 1px solid #ccc;
}但一到 JS 里就麻烦了——对象属性不能直接用短横线（除非加引号），比如：
// 报错！Invalid left-hand side in assignment
const user-profile = { name: "张三" };
// 只能这样，但丑死了
const user = { "user-profile": { name: "张三" } };所以 kebab-case 在 JS 逻辑层基本没法用，顶多在模板或配置文件里露个脸。如果你的项目重度依赖自定义属性（比如 Web Components），可能会用到，但对普通 React/Vue 项目来说，纯属添乱。我试过一次强行统一用 kebab，结果三天后就放弃了——光是写属性访问就得不停加引号，累得慌。
下划线（snake_case）：后端的遗产，前端的“异乡人”
很多后端语言（Python、Ruby、PHP）默认用 snake_case，所以 API 返回的数据经常是这种风格：
{
"order_id": 123,
"created_at": "2023-01-01"
}前端如果直接用，会显得和本地代码风格割裂。但我见过有些团队为了“和后端一致”，硬是在 JS 里也用下划线：
const order_id = getOrder().order_id;
function calculate_total_price() { /* ... */ }说实话，看着别扭。JS 社区几十年形成的习惯就是驼峰，强行改反而增加认知负担。而且 ESLint 默认规则也会报错（比如 camelcase 规则）。除非你整个技术栈都用 Python（比如 Django + HTMX），否则真没必要在前端搞这一套。我以前在一个全栈 Python 项目里妥协过，结果每次写 JS 都得切换思维，效率低还容易出错。
我的选型逻辑：驼峰为主，局部妥协
折腾了这么多，我现在基本定型了：**JS/TS 逻辑层一律 camelCase，CSS/HTML 用 kebab-case，API 数据单独处理**。
具体怎么操作？核心原则是“分层隔离”：
- 组件/函数/变量名：严格 camelCase 或 PascalCase（组件名）
- CSS 类名/ID：kebab-case，和 HTML 保持一致
- API 数据：进前端前统一转成 camelCase
比如用 Axios 拦截器自动转换：
// utils/api.js
import axios from 'axios';
import { snakeToCamel } from './helpers';
const api = axios.create({
baseURL: 'https://jztheme.com/api'
});
api.interceptors.response.use(response => {
// 递归把所有 snake_case 转成 camelCase
response.data = snakeToCamel(response.data);
return response;
});配套的转换函数（处理对象和数组）：
// helpers/snakeToCamel.js
export function snakeToCamel(obj) {
if (Array.isArray(obj)) {
return obj.map(snakeToCamel);
}
if (obj !== null && typeof obj === 'object') {
const newObj = {};
for (const key in obj) {
const newKey = key.replace(/_([a-z])/g, (_, letter) => letter.toUpperCase());
newObj[newKey] = snakeToCamel(obj[key]);
}
return newObj;
}
return obj;
}这样，业务代码里永远只看到 orderId、createdAt，不用再纠结数据来源。虽然多了层转换，但一劳永逸，团队新人上手也快。
至于 CSS，我坚决不用 JS 风格。比如一个按钮，类名就叫 primary-button，而不是 primaryButton。因为 CSS 不是 JS，它的命名应该面向语义和设计系统，而不是编程习惯。Tailwind 用户可能觉得无所谓，但如果你写原生 CSS，kebab-case 的可读性真的强太多。
踩坑提醒：这三点一定注意
第一，**别在 JSX 属性里混用风格**。比如：
// 别这么干！
<MyComponent user-name={name} />
// 正确：JSX 属性用 camelCase
<MyComponent userName={name} />第二，**环境变量和配置项要统一**。比如 REACT_APP_API_BASE_URL 这种，虽然带下划线，但属于构建工具约定，别试图改成驼峰，会出问题。
第三，**别为了“完美统一”牺牲可维护性**。我见过有人写脚本自动重命名整个代码库的变量，结果 Git 历史全乱了，diff 看不出改了啥。命名规范是手段，不是目的——只要团队能高效协作，稍微不一致也比频繁重构强。
总结：没有银弹，但有“够用就好”
说到底，命名规范不是技术问题，是协作问题。驼峰在 JS 里赢了，不是因为它多优雅，而是社区共识。我现在的方案可能不是理论上最优的，但实测下来，团队沟通成本最低，新人上手最快，这就够了。
以上是我个人对命名规范的完整踩坑总结，有更优的实现方式欢迎评论区交流。这个技巧的拓展用法还有很多（比如如何自动化校验命名），后续会继续分享这类博客。
