教程：配置你的“代码管家”，告别乱糟糟的代码
一场由“代码风格”引发的战争
想象一下这个场景：
你加入了一个新项目，团队里有三个成员：
- 张三，习惯用
Tab键进行代码缩进。 - 李四，坚信 2 个空格的缩进才是宇宙的真理。
- 你，习惯在每行代码的末尾加上分号
;。
结果就是，同一个文件，你今天打开是这个样子，明天李四提交后，又变成了另一个样子。代码在 Tab 和空格之间反复横跳，充满了不必要的文件变更，Code Review（代码审查）时简直是一场灾难。
如果有一个“代码管家”，能让每个人的代码在保存和提交时，都自动统一成同一种风格，那该多好？
这个“代码管家”，就是一套由 Prettier (格式化) + ESLint (检查) + Husky (自动化) 组合而成的现代化前端工作流。ArenaPro 脚手架已经为你内置了这一切，你只需理解它，并按需调整即可。
第一步：认识你的两位核心“仆人”
你的“代码管家”主要由两位核心“仆人”构成：
仆人一：Prettier (首席造型师)
- 职责：只负责代码的外观。比如，是该用单引号还是双引号？缩进用几个空格？一行代码超过多长要自动换行？
- 特点：它非常“霸道”，不关心你的代码逻辑对不对，只关心它好不好看。
- 配置文件：
.prettierrc
仆人二：ESLint (质量总监)
- 职责：负责代码的质量和规范。比如，你是不是定义了一个变量却从来没用过？你是不是写了一些可能导致 Bug 的低级错误？
- 特点：它像个严谨的老师，时刻检查你的代码有没有“坏味道”。
- 配置文件：
eslint.config.mjs
在 ArenaPro 项目中，我们已经让这两位“仆人”达成了合作：ESLint 在检查代码质量时，也会采纳 Prettier 的外观标准。你无需为它们之间的冲突而烦恼。
第二步：配置你的“仆人” (VS Code 篇)
为了让他们在你写代码时就能为你服务，我们强烈推荐在 VS Code 中安装两个插件：
安装后，请打开 VS Code 的设置 (Ctrl + , 或 Cmd + ,)，确保以下配置是开启的。这会让“管家”在你每次按下 Ctrl + S 保存文件时，自动开始工作。
// .vscode/settings.json
{
// 1. 每次保存时，自动格式化代码
"editor.formatOnSave": true,
// 2. 指定 Prettier 为默认的格式化工具
"editor.defaultFormatter": "esbenp.prettier-vscode",
// 3. 每次保存时，也让 ESLint 自动修复它能修复的问题
"editor.codeActionsOnSave": {
"source.fixAll.eslint": "explicit"
}
}配置完成后，当你保存一个格式混乱的文件时，代码会瞬间变得整齐漂亮，潜在的低级错误也会被自动修复。
第三步：雇佣一位“保安” (Husky)
现在，你的代码在本地写起来很舒服了。但如何保证团队里那些“不自觉”的成员（比如，没有装 VS Code 插件的李四）也必须遵守规范呢？
这时候，我们就需要雇佣一位“保安”—— Husky。
- 职责：守在代码仓库的“大门口”。每当有人想要
git commit（提交代码）时，它会把代码拦下来，交给“仆人”们检查。 - 规则：只有通过了 Prettier 的格式检查和 ESLint 的质量检查的代码，才允许被提交。不合格的代码，一律打回！
这个过程是全自动的。只要项目配置好了，无论团队成员用什么编辑器，都无法将不规范的代码提交到仓库中。这就从根本上保证了整个项目的代码质量。
如何检查“保安”是否在岗？
这个“保安系统”由 .husky/ 文件夹和 .lintstagedrc 文件共同配置。ArenaPro 项目已为你默认配置好。
如果你想测试它，可以故意在一个文件里写一些不符合 ESLint 规范的代码（比如 let a; 这种未使用的变量），然后尝试 git commit。你会发现，提交会被 Husky 拦截，并提示你代码中存在的问题。
初始化提示 如果你是第一次拉取项目，可能会发现 Husky 不工作。请在项目根目录运行一次
npm run prepare命令来激活它。
总结
通过这套“代码管家”体系，你的团队实现了：
- 风格统一：所有人的代码格式都由 Prettier 自动统一。
- 质量保障：所有代码都经过 ESLint 的检查，规避了低级错误。
- 流程自动化：所有检查都在提交代码时由 Husky 自动触发，无需人为监督。
这套工作流将极大提升你的开发体验和团队的协作效率。