1. 先装"自动格式化"，再谈风格
不要指望人工遵守规则。项目根目录必装三个文件：
.editorconfig：统一换行符和缩进（让 Windows 和 Mac 不打架）Prettier：负责代码美观（分号、引号、换行长度）ESLint或Biome：负责代码质量（未使用变量、潜在 Bug）
配置一次后，开启编辑器的 "Format On Save"，让机器吵架，别让人吵架。
2. 用 git hooks 兜底
在 .husky/pre-commit 里加一行：
npx lint-staged这样提交代码时会自动修复格式问题。如果 CI 报红，本地肯定也红，避免"我本地好好的"这种扯皮。
3. 规则从简，拒绝"圣经式"配置
不要复制网上几百行的 ESLint 配置。起步三条足够：
- 单引号还是双引号（团队投票，少数服从多数）
- 行宽 80 或 100（看你们显示器尺寸）
- 结尾分号（要或不要，别争论哪个更优雅）
其他规则遇到再说，先跑起来比完美重要。
4. 老项目改造：只改变动的文件
存量代码千万别全量格式化，会毁掉 git blame。用 lint-staged 配置只检查本次修改的文件：
"lint-staged": {
"*.{js,ts}": "eslint --fix"
}历史代码保持原样，新代码逐渐替换。
5. 把配置放进版本控制.prettierrc、.eslintrc 必须提交到 Git。不要依赖全局配置，否则新人拉代码后格式全乱。
6. 定期"静默修复"
每月选一次低峰期，让 CI 自动跑 prettier --write 全量格式化并提交。前提是团队提前约定好"那天不开发新功能"，避免合并冲突地狱。
避坑提醒：
- 不要为
i++还是i += 1开半小时会，用默认规则。 - 如果某条规则一周内被 Disable 超过三次，直接删掉这条规则，说明它不适合你们。
- 代码风格检查失败时，错误信息要友好（配个 emoji 或简短说明），别让开发者对着满屏红字骂娘。