标准答案
- ESLint 适合检查 JavaScript、TypeScript、Vue、React 中的语法风险、最佳实践和团队规则。
- Prettier 负责格式化，避免团队在缩进、换行、引号这类问题上争论。
- Stylelint 负责 CSS、SCSS、Less 或样式文件的规则检查。
- Git hooks 可以在 commit 或 push 前运行 lint、format check、typecheck 或测试，但要控制耗时。
- CI 仍然必须跑关键检查，不能只依赖本地 hooks，因为 hooks 可能被跳过。
题目解析
这类规范工具最容易被做成“装了一堆包但没人愿意用”。更合理的方式是让 Prettier 处理格式争议，让 ESLint 关注代码风险，让 Stylelint 关注样式规则，各管一层。
Git hooks 适合把低成本问题挡在提交前，比如格式化、增量 lint、简单单测。耗时很长的 typecheck、build、E2E 更适合放到 push 或 CI，避免开发者为了提交被迫等待几分钟。
真正的门禁仍然应该在 CI。因为本地 hooks 可以被跳过，也可能因为环境不同没有执行；CI 才是团队共享的最后标准。
代码示例
lint-staged 常用于只检查本次提交涉及的文件，降低提交前耗时。
JSON
{
"lint-staged": {
"*.{ts,tsx,vue}": "eslint --fix",
"*.{css,scss,less}": "stylelint --fix",
"*": "prettier --write"
}
}常见误区
- 让 ESLint 和 Prettier 同时管理格式细节，规则互相冲突。
- pre-commit 跑完整构建和全量 E2E，导致提交体验很差。
- 只依赖本地 hooks，不在 CI 里重复关键检查。