VSCode代码检查级别_修改Warning与Error的显示样式

如何让 VSCode 把 TypeScript 的未使用变量提示从“警告”变成“错误”

很多开发者都遇到过这个困惑：明明觉得未使用的变量是个严重问题，希望编辑器用刺眼的红色标出，但 VSCode 里却总是温和的黄色警告。其实，这里有个关键点需要厘清：VSCode 本身并不决定规则的严重级别，它只是一个“展示窗口”，真正发号施令的是背后的 TypeScript 语言服务器。

核心操作：修改 TypeScript 配置

想让未使用变量的提示升级为错误，最直接的办法是去源头——tsconfig.json文件里修改配置。具体来说，是在compilerOptions中将noUnusedLocals的值设置为"error"。

{
  "compilerOptions": {
    "noUnusedLocals": "error",
    "noUnusedParameters": "warn",
    "strict": true
  }
}

这里需要注意，它的值必须是字符串，可选"error"、"warn"或"off"，而不是布尔值。

配置改完后，还有至关重要的一步：重启 TypeScript 服务器。否则，旧的配置可能还在缓存中生效。操作很简单，按下Ctrl+Shift+P（或Cmd+Shift+P），输入并执行TypeScript: Restart TS server命令即可。

话说回来，如果你的项目同时配置了 ESLint 来检查 TypeScript，那么实际控制提示的可能是 ESLint 规则。这时候，你就需要去检查.eslintrc.js这类配置文件，找到@typescript-eslint/no-unused-vars这条规则，同样将其级别设置为"error"。

常见陷阱：为什么配置改了却不见效？

有时候，明明按照上述步骤操作了，但 VSCode 里的提示依然是黄色警告。这通常不是配置本身的问题，而是配置没有被正确加载。

首先，确认你的工作区根目录是否正确。如果你在 VSCode 中只打开了项目的一个子文件夹，TypeScript 服务器可能无法定位到根目录下的tsconfig.json，从而回退到使用默认配置。

一个快速的检查方法是看一眼 VSCode 状态栏的右下角。那里通常会显示当前的 TypeScript 版本，旁边可能有一个类似{}的图标或tsconfig.json的路径。点击它，就能确认当前生效的配置文件究竟是哪一个。

此外，在那些结构稍微复杂的项目中，比如使用了多个tsconfig.json（例如tsconfig.app.json、tsconfig.spec.json）或者采用了 monorepo 架构（使用 Nx、Turborepo、pnpm workspaces 等工具），配置的继承和解析很容易出问题。如果怀疑是这类工具干扰，可以尝试临时关闭相关的 VSCode 插件，再观察问题是否解决。

视觉调整：只改变颜色，不改变规则

当然，也存在另一种需求：你并不想提升规则的严重级别，只是觉得黄色的警告不够醒目，希望它在视觉上更突出一些。这完全是界面显示层面的调整，可以通过自定义 VSCode 的颜色主题来实现。

打开 VSCode 设置（Ctrl+,），搜索workbench.colorCustomizations，点击“在 settings.json 中编辑”。然后，你可以添加类似下面的配置：

"workbench.colorCustomizations": {
  "editorWarning.foreground": "#ff0000",
  "editorError.foreground": "#ff0000"
}

不过得提醒一下，editorWarning.foreground会改变所有类型警告的文字颜色。更实用的做法可能是保持颜色区分，但通过设置editorWarning.background为警告文字添加一个醒目的背景色，这样既能引起注意，又不至于和错误混淆。

规则冲突：当 TypeScript 遇上 ESLint

在现代前端项目中，TypeScript 编译器与 ESLint 并存是常态。这就带来了一个新问题：对于“未使用变量”这类两者都覆盖的规则，到底听谁的？你很可能在代码编辑器和问题面板里看到重复甚至矛盾的提示。

默认情况下，如果安装了 ESLint 插件并启用，VSCode 会优先显示 ESLint 的诊断结果。这意味着，即使你在tsconfig.json里把noUnusedLocals设成了"error"，如果 ESLint 的@typescript-eslint/no-unused-vars规则是"warn"，你看到的可能还是警告。

解决冲突的关键在于明确分工。一个清晰的策略是，让其中一方完全接管某项检查。例如，你决定完全由 TypeScript 负责未使用变量的检查，那么就在 ESLint 配置中关闭对应的规则：

rules: {
  "@typescript-eslint/no-unused-vars": "off",
  "no-unused-vars": "off"
}

反之亦然。如果更信任 ESLint 的检查，就在tsconfig.json中将"noUnusedLocals"和"noUnusedParameters"设为"off"，把工作交给 ESLint。

总而言之，TypeScript 的诊断级别由其编译器配置决定。想改变问题的性质（是警告还是错误），就得去修改配置；如果只想改变它的外观，则去调整颜色主题。而在混合工具链的环境中，理清检查工具的主次权责，是避免反复踩坑的不二法门。