自定义VSCode代码高亮可通过主题选择、settings.json中editor.tokenColorCustomizations和editor.semanticTokenColorCustomizations配置，以及扩展插件实现；正确使用可提升可读性与开发效率，需注意避免过度定制、处理TextMate与语义高亮冲突，并可通过项目级配置确保团队一致性。
VSCode的代码高亮功能，远不止是换个主题那么简单。它允许你通过深入的配置，精细到每一个语法元素的颜色、字体样式，从而真正打造出符合个人阅读习惯和审美偏好的代码视觉体验。这不仅仅是为了好看，对我来说，更是为了提升代码的可读性和减少长时间阅读的视觉疲劳，毕竟我们盯着屏幕的时间太长了。
解决方案
要深入自定义VSCode的代码高亮，主要有几个途径，它们层层递进，可以组合使用。
首先，最直观的当然是主题（Themes）。VSCode内置了一些主题，但更多人会从Extensions Marketplace安装第三方主题。这通常是第一步，选择一个你觉得基础色调和整体风格都比较舒服的主题。比如我个人偏爱那些对比度适中，颜色不至于过于鲜艳或过于灰暗的主题，这样既能区分元素，又不会让眼睛感到刺激。
但如果某个主题的某个特定颜色让你不满意，或者你就是想让某个特定类型的变量、函数或者关键字以你独特的颜色呈现，那就需要动用
settings.json
里的
editor.tokenColorCustomizations
了。这是自定义的核心。
打开
settings.json
（可以通过
Ctrl/Cmd + Shift + P
然后输入”Preferences: Open User Settings (JSON)”），你会看到一个JSON对象。在其中添加
editor.tokenColorCustomizations
字段。这个字段可以针对当前主题或者所有主题进行定制。
{ "editor.tokenColorCustomizations": { // 可以针对所有主题进行定制 // "textMateRules": [ // { // "scope": "comment", // 针对注释 // "settings": { // "foreground": "#6A9955", // 更深的绿色 // "fontStyle": "italic" // 斜体 // } // }, // { // "scope": ["variable.other", "variable.parameter"], // 针对变量和参数 // "settings": { // "foreground": "#9CDCFE" // 亮蓝色 // } // } // ], // 也可以针对特定主题进行定制，比如 "Default Dark+" "[Default Dark+]": { "textMateRules": [ { "scope": "comment", "settings": { "foreground": "#5C8B4C", // 我个人觉得这个绿色更舒服 "fontStyle": "italic" } }, { "scope": "keyword", // 关键字，比如 `const`, `let`, `function` "settings": { "foreground": "#C586C0", // 默认紫色，我喜欢稍微深一点 "fontStyle": "bold" // 让关键字更醒目 } }, { "scope": "string", // 字符串 "settings": { "foreground": "#CE9178" // 默认橙色，但我想让它更偏红一点 } }, { "scope": "entity.name.function", // 函数名 "settings": { "foreground": "#DCDCAA", // 默认黄色，我喜欢更亮一点的黄 "fontStyle": "underline" // 给函数名加下划线，一眼识别 } }, { "scope": "support.class", // 比如 React 组件名 "settings": { "foreground": "#4EC9B0" // 青色，我发现它在我的主题里不够突出 } } ] } } }
这里面最关键的是
scope
。
scope
定义了你要定制的语法元素的类型。VSCode使用TextMate语法作用域系统来识别代码中的不同部分。要找到某个特定代码元素的准确
scope
名称，你可以使用VSCode的“Developer: Inspect Editor Tokens and Scopes”命令（同样通过
Ctrl/Cmd + Shift + P
搜索）。当你执行这个命令后，点击代码中的任何一个词，VSCode就会弹出一个窗口，显示这个词的所有TextMate作用域。通常，最具体的那个作用域（最长的那个）就是你想要定制的。比如，一个函数调用可能是
meta.function-call.js
和
entity.name.function.js
。
除了
textMateRules
，还有
editor.semanticTokenColorCustomizations
，这是基于语言服务器协议（LSP）的语义高亮。它比TextMate更智能，能理解代码的实际含义，比如区分局部变量和全局变量。如果你发现某些语言（尤其是TypeScript、go等强类型语言）的某些元素高亮不符合预期，可能是语义高亮在起作用。你也可以在这里进行定制，或者干脆禁用特定元素的语义高亮，让TextMate规则发挥作用。
{ "editor.semanticTokenColorCustomizations": { "[Default Dark+]": { "enumMember": { "foreground": "#B5CEA8", // 枚举成员，给它一个独特的颜色 "fontStyle": "bold" }, "variable.readonly": { // 只读变量 "foreground": "#9CDCFE", "fontStyle": "italic" } } } }
最后，一些扩展（Extensions）也能增强高亮。比如一些特定语言的扩展会提供更准确的语法解析和高亮。还有一些像Bracket Pair Colorizer 2这样的扩展，可以给匹配的括号着色，极大提升了嵌套代码的可读性。
为什么默认的代码高亮总让我感觉差点意思？
这个问题我深有体会，每次新装VSCode，我做的第一件事就是调整主题和高亮。默认的高亮方案，对我来说，往往是“能用但不够好”。这背后其实有几个原因：
首先是个人偏好。每个人的视觉敏感度和对颜色的感知都不同。有人喜欢高对比度，觉得这样能一眼区分；有人则偏爱柔和的色调，认为长时间盯着不刺眼。默认主题为了普适性，往往采取一种中庸之道，但这种“中庸”恰好可能不适合任何一个极端。我个人就对某些默认的紫色、蓝色饱和度感到不适，总觉得它们在我的屏幕上显得有点“脏”。
其次是认知效率。代码高亮的终极目标是提高代码的可读性和理解速度。默认高亮可能在区分不同元素上做得不错，但它不一定能高效地突出“重要信息”或“我最关心的信息”。比如，我可能希望函数名比变量名更醒目，或者某个特定类型的常量有独特的颜色，这样我扫一眼就能定位到关键逻辑。默认高亮往往没有这种细致的优先级区分。
再者，语言特性也是一个因素。一个为JavaScript设计的主题，可能在Python或C#中表现不佳。不同语言有不同的关键字、数据类型和语法结构，它们对高亮的需求是不同的。默认高亮通常是基于一个广泛的语法规则集，无法完全适应所有语言的细微差别。
还有一点，我觉得是现代前端和后端开发的复杂性。现在的项目，各种框架、库、DSL层出不穷。默认高亮可能无法很好地识别并突出这些特定语境下的元素。例如，JSX中的HTML标签和JavaScript表达式，或者Vue单文件组件中的
<template>
、
<script>
、
<style>
块，我希望它们能有明确的视觉边界，而默认主题往往处理得比较粗糙。
最后，审美疲劳。长时间使用同一个主题，就像每天穿同一件衣服，总会觉得有些单调。适时地调整高亮，哪怕只是改动几个颜色，也能带来一种新鲜感，让写代码的心情都变得不一样。这种微小的变化，对我来说，也是一种保持专注和兴趣的方式。
自定义高亮会影响性能吗？有没有什么需要注意的坑？
关于性能，我可以说，绝大多数情况下，自定义高亮对VSCode的性能影响微乎其微，几乎可以忽略不计。 VSCode在这方面做得相当优化。颜色和字体样式的渲染，是现代文本编辑器最基础也是最高效的任务之一。你添加的
tokenColorCustomizations
规则，本质上只是告诉渲染引擎如何着色，这个过程很快。
当然，如果你写了几百条极其复杂的
textMateRules
，并且每个规则都包含复杂的正则表达式匹配，理论上可能会有一点点影响。但这种情况非常罕见，通常我们只是针对几十个常用scope进行颜色调整。真正影响VSCode性能的，往往是那些重量级的语言服务扩展、Linter、Formatter，或者处理超大文件时。
不过，自定义高亮确实有一些“坑”或者说需要注意的地方：
-
过度定制导致可读性下降： 这是最常见的坑。就像我前面说的，高亮的目的是提升可读性。如果你把每个语法元素都设置成不同的鲜艳颜色，结果可能就是一片“彩虹海洋”，反而让代码变得难以辨认。眼睛在寻找关键信息时，会被过多的颜色分散注意力。我的建议是，保持克制，只调整那些你觉得确实需要改进的颜色，或者突出你认为最重要的元素。颜色种类不宜过多，通常在5-8种主色调之间是比较舒服的。
-
TextMate作用域的复杂性： 找到正确的
scope
是定制的关键。有时一个词可能同时属于多个
scope
，比如
variable.other.readwrite.js
和
meta.definition.variable.js
。如果你只改了其中一个，可能发现高亮没有生效，或者只在特定语境下生效。这时就需要用到
Developer: Inspect Editor Tokens and Scopes
来仔细检查，并可能需要同时指定多个
scope
，或者找到更通用的
scope
。我曾经为了一个Vue组件的属性高亮纠结了很久，最后才发现需要针对
entity.other.attribute-name.html
进行定制。
-
语义高亮（Semantic Highlighting）的冲突： 这是个比较高级的坑。VSCode的LSP（Language Server Protocol）支持的语言（如TypeScript、Go、Rust）会提供语义高亮。这意味着它们可以根据代码的实际含义（比如一个变量是常量还是可变变量，是函数参数还是全局变量）来高亮。语义高亮的优先级通常高于TextMate规则。如果你发现你的TextMate规则不生效，很可能是语义高亮在作祟。这时你需要：
- 检查
editor.semanticTokenColorCustomizations
是否覆盖了你的规则。
- 在
settings.json
中通过
"editor.semanticHighlighting.enabled": false
或者针对特定语言禁用语义高亮，但这会失去语义高亮带来的好处。
- 或者，更推荐的做法是，学习并利用
editor.semanticTokenColorCustomizations
来定制语义高亮。
- 检查
-
主题更新的潜在影响： 如果你对某个第三方主题进行了大量的
tokenColorCustomizations
，当这个主题更新时，可能会出现一些意想不到的视觉变化。因为主题作者可能调整了他们默认的颜色，而你的自定义规则是基于旧的默认颜色来覆盖的。这通常不会导致大的问题，但可能需要你重新审视和微调你的自定义规则。所以，最好是把自定义规则放在用户级别的
settings.json
中，而不是尝试修改主题文件本身。
-
跨设备/环境的一致性： 如果你在多台电脑上工作，或者与团队协作，保持自定义高亮的一致性是个问题。你需要确保你的
settings.json
文件在所有设备上都同步，或者与团队成员分享。这引出了下一个问题。
如何让我的自定义高亮在团队协作中保持一致性？
在团队协作中，代码风格和视觉一致性非常重要，它能减少认知负担，让大家更容易阅读和理解彼此的代码。虽然高亮自定义更多是个人偏好，但如果能有一套团队共识的视觉规范，那无疑会提高整体效率。以下是我觉得比较实用的做法：
-
项目级
.vscode/settings.json
： 这是最直接、最有效的方式。你可以在项目的根目录下创建一个
.vscode
文件夹，并在其中放置一个
settings.json
文件。这个文件中的设置会覆盖用户级别的设置，并且只对当前项目生效。你可以把一些关键的、大家普遍接受的高亮定制规则放进去，比如：
- 某些特定文件类型（如
.gql
文件、
.env
文件）的通用高亮。
- 团队内部定义的特定关键字或注释格式的高亮（例如，所有
TODO:
注释都用醒目的黄色）。
- 强制使用某个特定的主题（
"workbench.colorTheme": "One Dark Pro"
），作为团队的基础视觉规范。
将这个
.vscode
文件夹提交到版本控制（Git），这样所有团队成员拉取代码后，VSCode就会自动应用这些项目级设置。
- 某些特定文件类型（如
-
推荐并强制使用统一主题： 虽然个人可以自定义，但如果团队能达成共识，选择一个大家普遍接受的主题作为基础，会大大减少视觉差异。可以在项目的
README.md
中明确指出推荐或强制使用的主题，甚至可以配合VSCode的
recommendations
功能，在
.vscode/extensions.json
中推荐团队成员安装该主题。
// .vscode/extensions.json { "recommendations": [ "zhuangtongfa.material-theme", // 推荐 Material Theme "esbenp.prettier-vscode" // 推荐 Prettier ] } -
共享自定义规则片段： 如果团队成员对某个主题的某个局部高亮有共同的改进需求，你可以将你的
editor.tokenColorCustomizations
或
editor.semanticTokenColorCustomizations
中的相关片段提取出来，作为一份“团队高亮规范”文档。大家可以根据这份文档，将这些规则复制到自己的用户级
settings.json
中。这虽然不如项目级设置自动化，但对于那些不适合放在项目级设置的、更偏向个人但有共识的定制，是一个不错的折衷方案。
-
利用VSCode的Extension Pack： 如果你的团队有许多共同的扩展和设置，可以考虑创建一个VSCode Extension Pack。这个扩展包可以包含推荐的主题、常用的代码高亮辅助扩展，甚至可以通过配置在安装时自动应用一些默认设置。这样，新成员加入时，只需安装一个扩展包，就能快速获得统一的开发环境。
-
定期讨论与反馈： 视觉规范不是一成不变的。团队成员之间可以定期沟通，讨论现有高亮方案的优缺点，收集反馈，并根据实际情况进行调整。也许某个颜色在某个显示器上表现不佳，或者某种新的语法结构需要特殊处理。开放的沟通能让团队的视觉体验持续优化。
通过这些方法，我们可以在保持个人灵活性的同时，最大限度地在团队内部实现代码高亮的一致性，从而提升整体的开发体验和协作效率。毕竟，代码是给人读的，视觉上的舒适和统一，绝对是提升阅读效率的重要一环。
vscode vue react javascript word python java html js 前端 git Python JavaScript typescript rust json 正则表达式 html 数据类型 常量 局部变量 全局变量 Attribute JS function 对象 作用域 git vscode 自动化