代码规范工具：外包老兵的血泪避坑指南
上周五晚上十一点半，我正一边啃着冷掉的黄焖鸡，一边在 VSCode 里疯狂 Ctrl+Z。起因是产品经理临时加了个需求：“这个表单字段的命名能不能统一成小驼峰？明天上线前必须改完。” 我心里一万只羊驼奔腾而过——项目跑了三年，八百多个文件，谁记得哪个字段叫 user_name、哪个叫 userName？
更离谱的是，这活儿还不能手动改。为啥？因为测试那边已经写好了自动化脚本，字段名一变，全挂。运维也发话了：“别动生产配置，出事你背锅。” 得，只能靠代码规范工具自动修复。
说起来，我在这家外包公司干了快四年，从 Vue 2 写到 Vue 3，从 Webpack 3 升到 Vite 4，见过了太多因为“代码风格不统一”导致的线上事故。最惨的一次是去年双11，前端同事手误把 == 写成了 =，结果用户购物车清空，客户直接打电话骂到我们总监那儿。
也就是从那以后，我们团队开始认真搞起了代码规范工具链。今天这篇文章，就结合我这几年踩过的坑、熬过的夜、被领导 push 的经历，聊聊怎么把 ESLint、Prettier、Stylelint 这些玩意儿真正用起来，而不是装个插件摆设。
为什么外包公司特别需要代码规范？
很多人觉得：“我一个人写项目，爱咋写咋写。” 但外包不一样。一个项目可能今年你在做，明年换给另一个团队；也可能三个不同外包组同时维护同一个系统。代码风格不统一？轻则 review 看得眼瞎，重则合并冲突到想删库跑路。
而且外包有个残酷现实：你写的代码，大概率不是你维护。我见过实习生离职后留下的“神级缩进”，也见过外包转正的老哥用 Tab 混合 Space 写 React，提交记录里全是 fix: format，根本看不出业务改动。
所以对我们这种“流水线码农”来说，代码规范不是可选项，是生存技能。尤其现在我想跳槽，简历上写“熟悉工程化规范”总比“会写页面”听起来高级点吧？
别再让 ESLint 变成摆设
很多团队以为装了 ESLint 就万事大吉。结果呢？.eslintrc.js 里一堆 "off"，CI 流程里 ESLint 根本没跑，PR 里全是 “// eslint-disable-next-line” 的注释。
我之前接手的一个政府项目就是典型。ESLint 配置文件里写着 "semi": ["error", "always"]，但实际代码里分号时有时无。问老员工，人家说：“以前跑不过，就关了。” 好家伙，规范工具变成许愿池了？
正确姿势：强制 + 自动修复
我的建议是：本地开发自动 fix，CI 流程严格校验。
比如在 package.json 里加个脚本：
{
"scripts": {
"lint": "eslint src --ext .js,.vue",
"lint:fix": "eslint src --ext .js,.vue --fix"
}
}
然后配合 VSCode 插件 ESLint 和 Format on Save，保存时自动格式化。这样你写 if (a==b)，它立马给你改成 if (a === b)，连思考都不用。
但光这样还不够。必须在 Git 提交前拦住不规范的代码。这时候就轮到 Husky + lint-staged 上场了：
# 安装
npm install husky lint-staged --save-dev
npx husky install
npx husky add .husky/pre-commit "npx lint-staged"
然后配置 lint-staged.config.js：
module.exports = {
"*.{js,vue}": ["eslint --fix", "prettier --write"],
"*.css": ["stylelint --fix", "prettier --write"]
};
这样一来，只要有人试图提交不符合规范的代码，Git 直接拒绝。别说实习生，就算总监来了也得守规矩（当然，他可能会找你开白名单，但那是另一个故事了）。
Prettier：别让它和 ESLint 打架
新手常犯的错误是：同时启用 ESLint 的格式规则和 Prettier，结果俩工具互相覆盖。你刚让 Prettier 把引号改成双引号，ESLint 又给你改回单引号，最后文件变红，人也变疯。
解决办法很简单：让 Prettier 负责“格式”，ESLint 只管“逻辑错误”。
具体操作是安装 eslint-config-prettier，它会自动关闭所有和 Prettier 冲突的 ESLint 规则：
npm install eslint-config-prettier --save-dev
然后在 .eslintrc.js 里加上：
module.exports = {
extends: [
"eslint:recommended",
"plugin:vue/vue3-recommended",
"prettier" // 必须放在最后！
]
};
记住：prettier 这一项一定要放 extends 数组的最后，这样才能覆盖前面的格式规则。
顺便吐槽一句：有些老项目用的是 standard 风格，死活不用分号。我每次看到都手痒想加，但为了团队和谐，只能忍。所以跳槽前，我一定先问清楚目标公司的代码风格——毕竟谁也不想天天和自己的 coding 习惯打架。
Stylelint：CSS 也能卷起来
很多人觉得 CSS 不需要规范，反正浏览器能跑就行。但当你在一个 500 行的 SCSS 文件里找一个 margin: 10px 是谁写的，而发现有人用 px、有人用 rem、还有人混用 !important 时，你就知道痛了。
我们团队之前有个 UI 组件库，因为颜色值写法不统一（#fff、white、rgba(255,255,255,1) 全都有），设计师直接崩溃：“这根本没法做设计系统！”
于是我们上了 Stylelint，配合 stylelint-config-standard 和 stylelint-order 插件，强制：
- 颜色统一用十六进制（小写）
- 属性按布局、盒模型、排版顺序排列
- 禁止使用
!important
配置示例：
// stylelint.config.js
module.exports = {
extends: ["stylelint-config-standard", "stylelint-order"],
plugins: ["stylelint-scss"],
rules: {
"color-hex-case": "lower",
"declaration-block-single-line-max-declarations": 1,
"order/order": [
"custom-properties",
"dollar-variables",
"declarations",
"rules",
"at-rules"
]
}
};
效果立竿见影。现在新来的实习生写 CSS，都不敢乱用魔法数字，生怕被 pre-commit hook 拦下来。
综合：一套配置打天下？
理想很丰满，现实很骨感。不存在“通用”的规范配置。Vue 项目和 React 项目规则不同，老 IE 兼容项目和现代 SPA 的要求也天差地别。
我现在的做法是：基础规则共享，框架规则分离。
比如建一个 eslint-config-base 包，里面放通用规则（变量命名、禁止 console、no-var 等），然后 eslint-config-vue 和 eslint-config-react 分别继承它，再加各自生态的插件。
这样做的好处是：
- 新项目初始化快
- 团队风格统一
- 跳槽时可以直接带走配置（别笑，真有用）
下面是我整理的一个对比表，方便大家选型：
| 工具 | 主要作用 | 是否支持自动修复 | 推荐插件/配置 |
|---|---|---|---|
| ESLint | JS/TS 逻辑 & 风格 | ✅（部分） | @typescript-eslint, eslint-plugin-vue |
| Prettier | 纯格式化 | ✅ | 无需插件，配合编辑器即可 |
| Stylelint | CSS/SCSS/Less 规范 | ✅（部分） | stylelint-order, stylelint-scss |
| Commitlint | Git 提交信息规范 | ❌ | @commitlint/cli, conventional-changelog |
求职加分项：你会配置工程化规范吗？
最近面试了几家，发现一个趋势：大厂越来越看重工程化能力。不再是“你会不会写 React Hook”，而是“你怎么保证团队代码质量”。
有一次面试官直接问：“如果让你从零搭建一个前端项目，怎么集成代码规范？” 我当场打开 VSCode，三分钟演示了 ESLint + Prettier + Husky 的配置流程。面试官眼睛一亮：“你这经验很实战啊。”
其实哪有什么天赋，都是被外包项目逼出来的。Deadline 前修 Bug、交接时看不懂前任代码、客户投诉样式错乱……这些血泪教训，最后都变成了简历上的“熟悉前端工程化体系建设”。
最后一点真心话
代码规范工具不是银弹，但它能让你少背几次锅。尤其是在外包这种“交付即分手”的环境里，一份清晰、一致、自动化的代码，是你留给下一位接盘侠最大的善意。
我现在每天打开 VSCode，看着那一堆插件图标（ESLint、Prettier、Volar、Auto Rename Tag……），心里反而踏实。至少我知道，不管今天写得多烂，保存那一刻，代码都会变得“体面”。
如果你也在考虑跳槽，不妨花一天时间，把自己的规范配置整理成模板。面试时甩出来，比说一百句“我注重代码质量”都管用。
毕竟，在这个卷成麻花的行业里，能让自己和同事少加班的工具，才是真·生产力。
（写完这篇，我准备把公司那套配置抽出来，开源到 GitHub。名字都想好了：eslint-config-outsider —— 外包人的倔强。）
评论 0