VSCode插件不直接优化JS代码，真正起作用的是背后配置的工具链（ESLint、Prettier、TypeScript）；关键在于选对、配准、用稳，避免盲目安装插件干扰开发节奏。
VSCode 插件本身不优化 JS 代码，真正起作用的是插件背后配置的工具链（如 ESLint、Prettier、TypeScript）；盲目装一堆插件反而干扰开发节奏，关键在选对、配准、用稳。
ESLint + TypeScript 配合时，eslint-plugin-react 和 @typescript-eslint/eslint-plugin 冲突怎么办
常见错误现象：eslint 报 React is not defined 或 no-unused-vars 对 TS 类型参数误报。根本原因是两类规则重叠且优先级没理清。
- 把
@typescript-eslint/eslint-plugin的规则设为高优先级，禁用原生eslint:recommended中与类型相关的规则（如no-unused-vars） - 在
.eslintrc.cjs中明确启用plugin:react/recommended后，立即用overrides为**/*.tsx单独配置@typescript-eslint规则集 - 避免同时开启
react/jsx-uses-react和@typescript-eslint/no-unused-vars—— 前者已无必要（TSX 下 React 不再需要显式导入）
保存时自动修复但破坏代码逻辑？关掉 editor.codeActionsOnSave 的默认 source.fixAll
使用场景：团队用 ESLint 做 CI 检查，本地只做提示；或项目含大量历史代码，自动 fix 容易引入隐式 bug（比如把 == 改成 === 导致宽松比较逻辑失效）。
- 在
settings.json中改用细粒度控制："editor.codeActionsOnSave": { "source.fixAll.eslint": true }，而非笼统的source.fixAll - 配合
eslint.options指定--fix-type problem,suggestion（只修明确错误和建议项，跳过可能影响行为的layout类格式化） - 对
node_modules、dist、build目录加"eslint.options": { "ignorePath": ".eslintignore" }，防止误扫
prettier-vscode 和 eslint-plugin-prettier 到底谁该管格式
性能与兼容性影响：两者都开会导致保存时两次格式化（Prettier 先跑，ESLint 再调 Prettier），慢且容易规则打架（比如单引号 vs 双引号）。
立即学习“前端免费学习笔记（深入）”；
- 只保留
eslint-plugin-prettier，把它作为 ESLint 的一个规则插件来用 —— 这样所有格式问题统一走 ESLint 流程，codeActionsOnSave一次搞定 - 删掉
prettier-vscode插件，同时移除prettier.*开头的 VSCode 设置项（如prettier.semi），全部交由.prettierrc控制 - 确保
eslint-config-prettier在 extends 数组末尾，它会关闭所有与 Prettier 冲突的 ESLint 规则
TypeScript 编译选项 skipLibCheck 开还是关
容易踩的坑：本地开发开着它很爽，但 CI 构建失败、或依赖升级后突然报 duplicate identifier —— 因为跳过了 node_modules 里 .d.ts 的类型检查。
- 开发阶段可开：
"skipLibCheck": true加速tsc --noEmit类型检查（尤其大项目） - CI/PR 检查必须关：
"skipLibCheck": false，否则无法发现第三方库类型定义冲突或版本不兼容 - 若关掉后报错集中在某个包（如
@types/react），优先升级该包，而不是回退开关；必要时用"typeRoots"显式指定路径，避开污染
最常被忽略的其实是 tsconfig.json 里的 include 范围 —— 写成 ["src/**/*"] 看似稳妥，但一旦 src 下混入构建产物或测试 mock 文件，TS 就会去解析它们，拖慢检查、甚至导致类型推导错误。手动列明入口目录，比通配更可控。
