ESLint 的 overrides.files 仅控制规则作用范围，不参与文件发现；必须显式传入文件路径或 glob，无法仅靠配置自动扫描——但可通过 npm 脚本复用 + 参数透传优雅解决路径重复问题。
eslint 的 `overrides.files` 仅控制规则作用范围，不参与文件发现；必须显式传入文件路径或 glob，无法仅靠配置自动扫描——但可通过 npm 脚本复用 + 参数透传优雅解决路径重复问题。
在 ESLint 的设计中，配置文件（如 .eslintrc.json）中的 overrides[].files 字段仅用于声明某组规则应“应用到哪些文件”，它不参与 CLI 的文件发现（file discovery）流程。换句话说：ESLint 启动时首先需要明确“要检查哪些文件”，这个列表必须由命令行参数（如 src/**/*.ts）或 --ext/--ignore-pattern 等选项显式提供；配置里的 files 是后续的“规则路由开关”，而非“文件扫描指令”。
因此，当你运行：
npx eslint -c .eslintrc.json
ESLint 会加载配置，但因未指定任何目标文件，*默认只检查当前目录下的 `.js文件（且不递归）**，不会自动展开overrides.files中定义的src/*/.ts` 等模式。这也是你观察到“无文件被检查”的根本原因。
✅ 正确做法：分离「文件路径」与「配置差异」，通过 npm 脚本复用降低冗余
推荐采用“主脚本定义通用文件集 + 子脚本透传配置参数”的结构，避免多处硬编码路径：
{
"scripts": {
"lint:base": "eslint \"src/**/*.ts\" \"test/**/*.ts\" \"*.ts\" --fix",
"lint:dev": "npm run lint:base -- -c .eslintrc.json",
"lint:prod": "npm run lint:base -- -c .eslintrc.prod.json",
"lint:staged": "npm run lint:base -- -c .eslintrc.json"
}
}? 关键细节说明：
-
双引号包裹 glob：
"src/**/*.ts"是必需的（尤其在 Windows 上），防止 shell 提前展开失败或空格截断；ESLint 官方文档明确要求（CLI 文档）。 -
--语法透传参数：npm run lint:base -- -c ...中的--将其后的所有参数原样传递给eslint进程，确保-c、--fix等生效。 -
路径统一维护：所有文件模式集中于
lint:base，一处修改全局同步，彻底消除lint/lint:prod/lint-staged中的重复。
⚠️ 补充注意事项：
- 若使用 ESLint v9+ 的 Flat Config（
eslint.config.js），同样不支持自动文件发现；仍需显式传入路径，但可结合files字段做更精细的规则分组（如区分.ts与.tsx）。 -
lint-staged配置中，应直接调用npm run lint:base --，并确保其lint-staged.config.js中的files与脚本一致，避免遗漏。 - 对于大型项目，建议启用
--cache加速二次执行："lint:base": "eslint ... --fix --cache"。
通过这种解耦设计，你既遵守了 ESLint 的运行机制，又实现了配置可维护性与跨环境一致性——这才是工程化落地的关键实践。
