eslint插件报错不标红,需检查三处:项目根目录有合法配置文件(如.eslintrc.js)、vscode中"eslint.enable":true已启用、typescript/react等需对应插件及正确extends配置。

ESLint 插件报错但不标红?检查这三处配置
VSCode 里 ESLint 安装了却没反应,大概率是插件没真正激活或规则没生效。不是“装了就完事”,它依赖明确的项目级配置和编辑器行为协同。
-
eslint必须在项目根目录有配置文件(.eslintrc.js、.eslintrc.json或package.json中的eslintConfig字段),否则默认只启用极少数基础规则 - VSCode 设置里要确认启用了
"eslint.enable": true(默认开启,但团队共享 settings.json 时可能被覆盖) - 如果用 TypeScript,确保已安装
eslint-plugin-react、@typescript-eslint/eslint-plugin等对应插件,并在extends中正确引用,否则React.FC或泛型类型检查会静默失效
Prettier 和 ESLint 冲突时怎么选?别硬拼,用 eslint-config-prettier
保存后代码被 Prettier 格式化,但 ESLint 又报 semi 或 quotes 错误——这不是 bug,是两者规则重叠导致的典型冲突。强行禁用某一方规则容易漏检逻辑问题。
- 在
.eslintrc.js的extends数组末尾加入'prettier',它会自动关闭所有与 Prettier 重复的格式类规则(如indent、comma-dangle) - 不要手动在
rules里逐条关掉格式规则,维护成本高且易遗漏 - VSCode 的
editor.formatOnSave应设为true,但必须指定editor.defaultFormatter为esbenp.prettier-vscode,否则 ESLint 的--fix可能抢在 Prettier 前执行
为什么 auto-fix 不修复 no-unused-vars?它根本不能自动修
ESLint 的 --fix 能力有限,不是所有规则都支持自动修复。像 no-unused-vars、no-console、react-hooks/exhaustive-deps 这类语义/逻辑类规则,只能报错,无法安全地自动删变量或加依赖。
- 这类规则的作用是“提醒你检查”,而不是“替你决策”;自动删变量可能破坏闭包或副作用,编辑器不敢越界
- 若想减少手动清理,可配合
unused-imports/no-unused-imports(需额外安装插件),它对未使用的 import 提供Fix快捷操作 - 开发中建议把
no-unused-vars设为warn而非error,避免保存即中断,留出人工判断余地
Path Intellisense 补全路径却找不到 alias?jsconfig.json 配置不对
写了 import Button from '@/components/Button',但 Path Intellisense 不提示 @/ 开头的路径——问题不在插件本身,而在 TypeScript/JS 的路径解析配置缺失。
- 必须在项目根目录创建
jsconfig.json(JS 项目)或tsconfig.json(TS 项目),仅靠webpack.alias或vite.resolve.alias不足以让 VSCode 识别 -
jsconfig.json至少要包含:"compilerOptions": { "baseUrl": ".", "paths": { "@/*": ["src/*"] } } - 改完配置后需重启 VSCode 或运行命令
Developer: Restart Language Server,否则缓存会导致补全仍不生效
ESLint 和 Prettier 的协同不是开箱即用,而是需要对齐配置粒度;路径补全依赖语言服务而非构建工具;auto-fix 的边界比想象中窄得多——这些点不手动验证过,很容易以为插件“不好用”。











