TypeScript 的 tsconfig.json 会直接影响 VSCode 错误提示范围，因为 VSCode 内置的 TS 语言服务强制依赖该配置；若 include/files 范围过宽或启用严格选项，会导致 node_modules 等非源码文件被检查而产生误报。
为什么 TypeScript 的 tsconfig.json 会影响 VSCode 错误提示范围
VSCode 默认用内置的 TypeScript 语言服务做 JS/TS 文件的语义检查，而该服务完全依赖项目根目录下的 tsconfig.json 配置。如果配置中 "include" 或 "files" 没有精确限定检查范围，或者启用了 "skipLibCheck": false、"noImplicitAny": true 等严格选项，就会把 node_modules、测试文件甚至构建产物都纳入检查，导致大量误报。
- 检查当前工作区是否真有
tsconfig.json：没有的话，TS 服务会 fallback 到默认宽松配置，但一旦存在，就**强制按它执行** - 确认
"include"只包含源码路径，例如：["src/**/*", "types/**/*.d.ts"]
，避免写成["**/*"] - 若项目含大量第三方类型（如
@types/react），设"skipLibCheck": true可显著减少来自声明文件的干扰错误
如何临时禁用某行 / 某文件的 TS 类型检查
不是所有红波浪线都需要修复——尤其当你明确知道某处是动态行为（如 eval、require 字符串拼接）、或使用了未导出的私有 API 时，硬改代码反而破坏意图。这时应选择性忽略，而非关掉整个检查器。
- 忽略单行：在行尾加
// @ts-ignore（下一行必须有错误才会生效）或更安全的// @ts-expect-error（要求下一行确实报错，防止误删后失效） - 忽略整个文件：在文件顶部第一行加
// @ts-nocheck - 注意：
// @ts-ignore不会抑制语法错误（如括号不匹配），只跳过类型检查；而// @ts-nocheck连语法也不查，慎用
ESLint 和 TypeScript 插件冲突导致重复报错
当同时启用 eslint-plugin-react、@typescript-eslint 和 VSCode 内置 TS 检查时，同一问题（比如 undefined 访问）可能被 TS 和 ESLint 各报一次，视觉上错误密度翻倍，实际却只是冗余。
- 优先保留 TypeScript 的类型级检查（它更底层、更准），在
.eslintrc.cjs中关闭重复规则：rules: { 'no-undef': 'off', '@typescript-eslint/no-explicit-any': 'off', // 若已由 TS 的 `noImplicitAny` 覆盖 } - 确保 ESLint 使用的是
@typescript-eslint/parser，且parserOptions.project指向正确的tsconfig.json，否则它无法理解类型信息，容易误判 - VSCode 设置里关掉
eslint.enable并不可取——建议保留，但通过规则对齐来消除重叠
插件太多时，哪些该禁用以降低误报率
某些插件会主动注入自己的诊断逻辑，和 TS/ESLint 叠加后加剧混乱。最常踩坑的是那些“自动补全增强”或“AI 辅助”类插件，它们常在未保存时就抛出推测性错误。
- 禁用非必要语言服务器插件：如
Auto Import（它不报错，但其“未解析导入”提示易与 TS 的Cannot find module混淆）、JavaScript Booster - 保留核心三项：
ESLint、TypeScript and JavaScript Language Features（VSCode 自带，勿卸载）、Prettier（仅格式化，不参与诊断） - 打开命令面板（
Ctrl+Shift+P），运行Developer: Toggle Developer Tools，在 Console 里搜diagnostic或validation，可看到哪些扩展正在往编辑器推送错误消息
tsc --noEmit 中复现的红色波浪线——它们大概率来自某个插件的独立诊断通道，得靠关闭插件 + 清除 ~/.vscode/extensions 缓存来定位。 
