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，是两者规则重叠导致的典型冲突。强行禁用某一方规则容易漏检逻辑问题。

chartjs-reporter

此技能用于在用户需要将结构化数据（查询结果、CSV 摘要、JSON 记录或 Python 字典/列表）转换为独立的 HTML 页面时使用。

下载

• 在 .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 的边界比想象中窄得多——这些点不手动验证过，很容易以为插件“不好用”。