团队需建立可复现、可继承的 eslint+prettier+.editorconfig+husky 配置闭环，缺一不可；否则规则不生效、格式混乱、新人无法开箱即用。
直接给结论：团队要用的不是“纠错规则模板”，而是可复现、可继承、不依赖个人设置的配置闭环。单独配几条 ESLint 规则没用，必须和 .editorconfig、prettier、husky 一起跑起来，否则保存时没反应、提交时还报错、新人 clone 下来第一行代码就格式错乱。
为什么你配的 ESLint 规则总不生效？
常见现象：No ESLint configuration found、保存后无任何修复、VS Code 右下角显示“ESLint is disabled for this workspace”。
- 没在项目根目录放
.eslintrc.js或.eslintrc.cjs，只装了插件但没配置文件 → ESLint 根本不启动 -
eslint.validate没配语言列表，比如漏了"typescript"，TS 文件就完全不检查 - 没开
"editor.codeActionsOnSave": { "source.fixAll.eslint": true }，只开formatOnSave是调 Prettier，不是修 ESLint 错误 - 用了
plugin:prettier/recommended却没装eslint-plugin-prettier，导致规则加载失败，整个 ESLint 静默退出
真正能落地的 JavaScript/TypeScript 规则组合
不是堆规则数量，而是选高拦截率 + 低误报 + 可自动修复的几条核心项。以下配置经多个中台项目验证（2026 年仍在稳定运行）：
-
"no-unused-vars": ["error", { "argsIgnorePattern": "^_" }]：报未使用变量，但忽略_开头的占位符（如(_, res) => {}） -
"eqeqeq": ["error", "always", { "null": "ignore" }]：强制===，但允许== null判空（兼容历史逻辑） -
"no-console": ["warn", { "allow": ["warn", "error", "info"] }]：禁止console.log，但保留调试级输出 -
"@typescript-eslint/no-explicit-any": "error"：TypeScript 项目必开，堵住类型逃逸口 -
"@typescript-eslint/explicit-function-return-type": ["warn", { "allowExpressions": true }]：函数显式写返回类型，但允许箭头函数简写（如map(x => x.id)）
注意：@typescript-eslint 规则需额外安装 @typescript-eslint/eslint-plugin 和 @typescript-eslint/parser，且 parser 必须设为该解析器，否则规则全失效。
别忘了 .editorconfig 是所有格式的起点
很多团队把精力全花在 ESLint 上，结果 git diff 里全是 ^M 和空格/Tab 混用 —— 这些根本不是 ESLint 能管的，得靠 .editorconfig。
-
root = true必须写，否则 VS Code 会往上找父目录的.editorconfig，可能套错缩进规则 -
[*.js]和[*.ts]分开写，避免 JS 项目被 TS 规则干扰；[*.md]单独关掉trim_trailing_whitespace，不然 README 里空行会被删 -
end_of_line = lf统一换行符，Windows 用户也得接受，Git 默认会把 CRLF 自动转 LF，但本地编辑器若不设，就会反复触发修改 - 别信“全局设置就够了”，
.vscode/settings.json必须存在且含"editor.defaultFormatter": "esbenp.prettier-vscode"，否则新成员打开项目，连保存都不格式化
最常被跳过的环节是 husky + lint-staged。没有它，等于只在本地修 bug，别人 push 的脏代码照样进主干。哪怕只加一条 "pre-commit": "lint-staged" 和 "lint-staged": { "*.js": ["eslint --fix", "prettier --write"] }，就能卡住 80% 的低级格式错误。别等 Code Review 时再提——那时候改，已经晚了。
