VSCode插件无法直接配置自定义规则，因其仅作为调度器调用本地node_modules/.bin/eslint执行检查；自定义规则必须发布为npm包（如@myorg/eslint-plugin-foo），在项目中devDependencies安装，并在.eslintrc.cjs中显式声明plugins和rules。
VSCode 插件市场本身不提供“自定义规则配置”能力——所有可配置的规则都来自你项目本地安装并注册的 ESLint / Flow 等工具，插件只是界面层调度器。 试图在插件市场里找一个能直接编辑规则逻辑的“团队规范检查插件”，注定失败。
为什么 VSCode 插件无法直接配置自定义规则
ESLint、Flow、TypeScript 等工具的规则是运行时动态加载的 JavaScript/TypeScript 函数，必须由 Node.js 执行。VSCode 插件（如 dbaeumer.vscode-eslint）只做三件事：监听文件变化、调用本地 node_modules/.bin/eslint、把诊断结果渲染成波浪线和 Problems 面板。它不解析、不编译、不执行你的规则代码。
- 你在插件市场看到的“ESLint 插件”或“Prettier 插件”，本质是客户端桥接器，不是规则引擎
- 所有自定义规则（比如
@myorg/eslint-plugin-foo/no-bare-strings）必须作为 npm 包发布，并在项目中npm install --save-dev @myorg/eslint-plugin-foo - 插件不会自动发现你写在
src/rules/下的 JS 文件——除非你把它打包进一个符合 ESLint 插件规范的包，并在.eslintrc.cjs中显式声明plugins: ['@myorg/foo']
真正生效的自定义规则必须走 npm 包流程
团队想复用自定义规则，唯一可靠路径是发布为 npm 包（私有 registry 或 GitHub Packages 均可），而非在每个项目里复制粘贴 JS 文件。否则会出现：Cannot find module '@myorg/eslint-plugin-foo'、规则静默跳过、CI 和本地行为不一致等问题。
- 包结构需含
index.js导出rules对象，且每条规则函数接收context并调用context.report() -
package.json中必须有"main": "index.js"和"eslintPlugin": true字段（非必需但推荐） - 项目中启用时，
.eslintrc.cjs的plugins字段写['@myorg/foo']，rules中写'@myorg/foo/rule-name': 'error' - 若用 pnpm，注意
node_modules/@myorg/eslint-plugin-foo是否真实存在——hoist 可能导致路径解析失败，此时需在.pnpmfile.cjs中显式保留
VSCode 设置里哪些项会影响自定义规则可见性
即使规则包已正确安装并配置，VSCode 仍可能不显示错误，常见卡点如下：
-
eslint.enable必须为true（默认是 true，但可能被用户级设置覆盖） - VSCode 必须打开的是含
package.json和.eslintrc.cjs的根目录，打开子文件夹会导致插件找不到配置和node_modules - 状态栏右下角 ESLint 图标若显示
Disabled，点击后选Enable for Workspace -
eslint.validate必须包含当前文件类型，例如['javascript', 'typescript', 'vue']；对.tsx文件漏掉typescript就会跳过检查 - 若规则依赖特定 parser（如
@typescript-eslint/parser），而.eslintrc.cjs中未设置parser或parserOptions.project，则整个文件会被跳过，不报错也不提示
最易被忽略的一点：自定义规则的报错位置、修复建议、甚至是否触发，高度依赖它所绑定的 AST 节点类型和上下文环境。比如一个针对 fetch 调用的规则，在 async 函数外写 fetch() 可能根本不会进入该规则的 CallExpression 处理分支——这不是配置问题，是规则逻辑本身没覆盖该场景。
