ESLint 本身不支持仅靠配置文件（如 .eslintrc.json 中的 overrides.files）自动推导待检查文件路径；files 字段仅用于规则作用域匹配，而非 CLI 扫描入口。必须显式传入文件/目录参数，但可通过 npm 脚本复用与 glob 引号规范实现高效管理。
eslint 本身不支持仅靠配置文件（如 .eslintrc.json 中的 overrides.files）自动推导待检查文件路径；files 字段仅用于规则作用域匹配，而非 cli 扫描入口。必须显式传入文件/目录参数，但可通过 npm 脚本复用与 glob 引号规范实现高效管理。
在 ESLint 的命令行设计中，overrides[].files 的语义是「当某个文件被 CLI 显式纳入检查范围后，该 override 是否对其生效」，它不参与文件发现（file discovery）阶段。换言之：ESLint 不会读取配置中的 files 字段去主动查找并加载匹配的文件——这与 Webpack 的 entry 或 Jest 的 testMatch 逻辑有本质区别。
因此，你遇到的现象完全符合预期：
npx eslint -c .eslintrc.json # ❌ 无输出：未指定任何文件，ESLint 默认不扫描任何内容 npx eslint -c .eslintrc.json src/**/*.ts # ✅ 正常执行：CLI 明确告知需检查哪些路径
✅ 正确实践：通过 npm 脚本解耦「路径」与「配置」
为避免在多个脚本（如 lint、lint:prod、lint-staged）中重复书写冗长的 glob 模式，推荐采用 “主脚本 + 参数透传” 模式：
{
"scripts": {
"lint:base": "eslint \"src/**/*.ts\" \"test/**/*.ts\" \"*.ts\" --fix",
"lint": "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.staged.json"
}
}? 关键细节说明：
- 使用双引号包裹每个 glob（如
"src/**/*.ts"），确保 Windows、macOS、Linux 下 shell 行为一致（单引号在 Windows CMD/PowerShell 中无效）；--是 npm 的参数分隔符，其后所有内容将透传给被调用的脚本（即lint:base）；lint:base专注定义统一的文件集和通用选项（如--fix），其他脚本只负责切换配置，职责清晰、零重复。
⚠️ 注意事项与常见陷阱
-
Flat Config（
eslint.config.js）用户注意：新版配置中files仍不触发自动扫描，且languageOptions.files仅用于解析器作用域控制，CLI 文件输入逻辑未改变； -
.eslintignore优先级更高：即使overrides.files匹配某文件，若其同时匹配.eslintignore中的规则，仍将被跳过； -
避免全局安装干扰：VSCode 或 CI 中应始终使用
npx eslint或本地node_modules/.bin/eslint，防止因全局 ESLint 版本与配置格式不兼容导致静默失败； -
性能提示：对大型项目，建议添加
--cache参数启用缓存（如"lint:base": "eslint ... --fix --cache"），可显著提升二次执行速度。
✅ 总结
ESLint 的设计理念是「显式优于隐式」——文件输入必须由用户明确声明，配置仅负责「如何检查」而非「检查什么」。这种分离让工具链更可预测、更易调试。通过合理的 npm 脚本抽象，你既能消除路径重复，又能保持配置与执行逻辑的正交性，是工程化落地的最佳实践。
