简介VScode雅蓝配色主题是一套从HbuilderX编辑器移植到Visual Studio Code的轻量主题资源面向追求清爽编码界面的前端、后端及全栈开发者旨在缓解长时间盯着代码带来的眼部疲劳。资源压缩包体积仅7KB共包含3个JSON文件分别承担主题颜色定义、扩展基础配置和本地化信息结构精简无需安装额外依赖导入后即可快速启用。目前已有2459人下载学习。这套主题以深蓝色调为背景配合淡色文字与柔和的高亮配色能够清晰区分关键字、注释、字符串等元素帮助使用者更快识别代码逻辑与结构。同时JSON配置也便于按个人习惯微调各语法元素的颜色让代码阅读更省力无论日常编码还是调试排查都能借助明确的高亮规则提升效率是希望兼顾美观与实用性的开发者的不错选择。1. 雅蓝配色主题给自己调一套能长期盯着看的蓝色系工作台装好 VSCode 之后大多数人第一件不会做的事就是换主题。默认的 Dark 不是不能用但连续盯上四五个小时纯黑背景加白字的对比会逼着人反复调屏幕亮度眼睛很快就干了。雅蓝配色主题的思路很简单用低饱和的蓝灰做背景、中低亮度的蓝色做界面框架再给语法高亮保留一组克制的色阶让整个编辑器看起来是「冷静」的工作台不是「发光」的广告屏。无论你平时写 Python、C/C、前端还是折腾 ESP32、STM32 这类嵌入式工程这套配色都能直接套进日常环境。这篇笔记不依赖某个现成扩展来兜底直接给你一套能照着抄的 settings.json 配置以及从排错到打包分发的一整条落地路径。新手照着改熟手能拿去做成团队共享的主题文件。2. 雅蓝配色拆解背景、前景、高亮三层为什么要这么设计2.1 蓝色系背景比纯黑更耐看的底层原因很多人以为深色主题就等于省电加护眼其实没这么简单。在 IPS 或者 OLED 屏上纯黑背景意味着像素熄灭整个屏幕只剩编辑器里的亮色文字在发光眼睛要在“一片漆黑”和“局部高亮”之间反复对焦时间一长就疲劳了。雅蓝这种“没黑透”的背景本质是给界面加了一层低亮度的环境光让屏幕变成一张有明暗层次的纸而不是一块黑板上钉着几十个灯泡。人眼对蓝灰色系的对比度感知比纯黑白温和前提是蓝色饱和度压得足够低明度停留在中低档不是那种带荧光感的电蓝。低饱和蓝灰的好处是前景的冷白文字能和背景拉开差距但亮度差没有黑底白字那么剧烈阅读代码时瞳孔不需要频繁缩放。所以护眼的核心指标不是绿色而是亮度差可控雅蓝做的就是控制这件事。从工程角度看背景明度还直接关系到整套色板的校准。如果你选了一套很暗的背景为了让文字可读所有语法高亮色都会被逼着调亮结果整份配色都漂移了。雅蓝把背景明度控制在 8% 到 15% 的区间比纯黑的 0% 高出一截但比常规深色主题的 #1E1E1E 暗一档。这个区间的意义是语法高亮用的中等亮度颜色能自然获得足够的对比度不用为了迁就纯黑背景把所有 token 都调成荧光色。2.2 雅蓝色板参数界面骨骼用什么色代码语义用什么色先给出我实际在用的雅蓝参数后面所有配置都围绕它展开。界面层和代码层分开列方便对照。用途色值HEX说明编辑器背景#10151C蓝黑基调不纯黑编辑器前景#D5DCE6冷白带一点蓝选区背景#1A3A5C蓝灰半透明感当前行高亮#151C26比背景亮一档不刺眼光标#6A9FD8中等蓝色容易定位侧边栏背景#121922比编辑器略亮活动栏背景#0C1118最暗一层压视觉边状态栏背景#0C1118与活动栏呼应语法层这组颜色比界面层更关键它决定你扫代码时第一眼看到什么。注释用 #5C6A7A蓝灰安静退后关键字用 #7DB4D9亮蓝让 if、for、return 这类控制结构浮出来字符串用 #8FBCBB带一点青和关键字区分开函数名用 #D9C97C暖黄是整片蓝色里唯一抢眼的色块用来标记“这里发生了调用”数字和常量用 #D19A66偏橙让魔法数字不至于淹没在代码里。变量名和普通文本保持冷白 #D5DCE6。提示这组颜色不是把所有东西染成蓝色而是让蓝色当主色、暖色当强调色。全蓝一片的编辑器在截图里好看写起代码来根本没层次。补充一个调节经验如果你在具体项目里觉得某两个色太接近优先微调前景而不是背景。背景一动整个界面的明暗层级全部漂移风险大。比如觉得字符串的青和关键字的蓝分不清就先把字符串往 #8FBCBB 这个偏青的方向拉而不是去把背景调深。2.3 界面配色和语法配色为什么要分开调VSCode 的配色机制分成两层这两层千万别混着调。第一层叫 workbench.colorCustomizations管的是编辑器外壳背景、侧边栏、活动栏、状态栏、标签页、滚动条这些是“界面骨骼”。第二层叫 editor.tokenColorCustomizations管的是编辑区里的代码文字而且不是按“文字颜色”这个粗粒度去调是按 Token 类型去调比如关键字、字符串、函数名、注释、常量这些是“语义节点”。把它们分开的直接原因有两个。一是故障隔离如果界面层和语法层写在同一组配置里某天你只想微调函数名颜色手一抖就可能让整个侧边栏变色排查时还得一层层剥。二是组合复用有人喜欢“雅蓝界面加默认语法”有人喜欢“默认界面加雅蓝语法”。雅蓝不是一套写死的主题而是一组可以自由组合的色块我后面给的每段配置都独立成块你可以只挑一段用不用全量梭哈。分开还有一个工程上的好处很多第三方主题其实只改了一层。界面好看的主题语法高亮可能一团糟语法色讲究的主题界面却停留在出厂状态。只要你自己把两层的 colorCustomizations 都声明一遍就等于在你选中的基线上覆盖出自己的雅蓝。这个覆盖层级搞明白了后面第五张里的踩坑排查基本都能自己推出来。3. 用 workbench.colorCustomizations 复刻雅蓝最小配置与逐项参数说明3.1 先打开用户设置 JSON两个入口一个原则在 VSCode 里做两件准备。第一把界面语言切到中文常用操作会好找很多CtrlShiftP 打开命令面板输入“Configure Display Language”装中文语言包后重启。第二打开用户设置 JSONWindows 和 Linux 用 CtrlShiftPmacOS 用 CmdShiftP输入「首选项: 打开用户设置(JSON)」回车。注意选用户级别而不是工作区级别用户级别对当前登录用户的所有项目生效工作区级别只对当前打开的文件夹生效。主题配色属于个人习惯放在用户级别合理团队统一的事放到后面单独谈。打开后你会看到一个 JSON 文件里面可能已经有不少配置项。雅蓝要追加三个 sectionworkbench.colorCustomizations、editor.tokenColorCustomizations以及终端那组小键。这里有一个原则要提前记住直接往文件里写全局键颜色会作用在所有主题上你以后切到别的主题会发现雅蓝的颜色赖着不走界面变成混血。为了避免这种翻车我习惯用“主题限定键”写法也就是在外层套一个中括号加主题名比如 [Default Dark]。这样配置只作用于指定主题换主题不会互相污染。3.2 UI 层把编辑器骨架染成蓝灰{ workbench.colorCustomizations: { [Default Dark]: { editor.background: #10151C, editor.foreground: #D5DCE6, editor.selectionBackground: #1A3A5C, editor.lineHighlightBackground: #151C26, editorCursor.foreground: #6A9FD8, activityBar.background: #0C1118, activityBar.foreground: #D5DCE6, sideBar.background: #121922, sideBar.foreground: #A8B4C4, statusBar.background: #0C1118, statusBar.foreground: #D5DCE6, editorGroupHeader.tabsBackground: #121922, tab.activeBackground: #1A2B3C, tab.activeForeground: #D5DCE6, scrollbarSlider.background: #2A3B4C } } }这段配置管的是界面主骨架。editor.background 是编辑区大背景editor.foreground 是所有普通文本的默认颜色编辑器里所有没被特殊处理的文字都走它是全配置里最关键的一对。editor.selectionBackground 和 editor.lineHighlightBackground 分别是选中代码时的底色、光标所在行的高亮底色建议都用蓝灰系但别太亮太亮了代码一密集就会出现一条明显的发光带。activityBar 是左侧那个竖排图标栏我把它压到最暗让图标浮出来sideBar 是资源管理器那一片比编辑区稍亮形成层次statusBar 是最底下的状态栏压暗是为了不抢编辑区的注意力。关于 [Default Dark] 这个键名有一个必须注意的细节如果你当前用的主题不是 Default Dark 而是一套第三方主题这段配置不会生效。正确做法是把方括号里的名字改成你当前主题的完整显示名怎么确认打开命令面板输入「Preferences: Color Theme」中文界面输入“颜色主题”看列表里当前选中项的名字或者直接打开设置搜索 workbench.colorTheme那里显示的就是完整主题名。想同时兼顾多套主题就复制多个这种 section各自指定主题名。3.3 语法层按 Token 类型给代码染色{ editor.tokenColorCustomizations: { [Default Dark]: { comments: #5C6A7A, keywords: #7DB4D9, strings: #8FBCBB, functions: #D9C97C, numbers: #D19A66, types: #6FA8DC, variables: #D5DCE6, textMateRules: [ { scope: punctuation.definition.keyword, settings: { foreground: #7DB4D9 } }, { scope: entity.name.function, settings: { foreground: #D9C97C, fontStyle: } } ] } } }comments、keywords 这些是 VSCode 提供的语义快捷名内部会映射到一串 TextMate scope。举个例子keywords 不只是 keyword.control还包括 keyword.operator 之类的一堆。快捷名的好处是写法简单坏处是你没法精确控制某个小类比如只想把 if 调亮、不想让 return 也变亮快捷名做不到。这时候就要用 textMateRules里面写真正的 scope 名。调试阶段可以用命令面板里的“开发人员: 检查编辑器 token”来查看鼠标悬停处具体命中了哪个 scope。textMateRules 的作用域覆盖优先级高于快捷名。如果你在快捷名里把 keywords 设为蓝色又用 textMateRules 精确指定了 punctuation.definition.keyword 的颜色那么这类标点最终显示 textMateRules 里的值。这是双刃剑能带来精确控制也会让后续排查变麻烦。我建议在还没完全弄清 scope 层级前只用快捷名等需要处理模板字符串里的 ${} 这类拼接语法时再去碰 textMateRules。字体样式这里也有一个隐藏参数。fontStyle 可以设 italic、bold也可以留空。我习惯让注释保持正常字重不加斜体因为斜体在等宽字体里辨识度其实不高连续几行注释会糊成一片。函数名也不加粗加粗会让高频出现的函数调用显得太吵。真正值得加粗的是少数声明类关键字这个可以单独在 textMateRules 里按 scope 补上。4. 深浅色跟随、终端与括号配色让雅蓝在真实项目里不打架4.1 给浅色场景配一套「雅蓝 Lite」深色雅蓝适合长时间写代码但白天坐在窗边或者灯很亮的会议室里深色屏幕会反射环境光反而看不清。我的做法是准备一套同色相的浅色版背景提到近白保留蓝灰层级语法色相不变但整体加深明度。这样你用快捷键或者让系统自动切换视觉不会跳得离谱。workbench.colorCustomizations: { [Default Light]: { editor.background: #F2F4F7, editor.foreground: #1C2733, editor.selectionBackground: #BBD4EA, editor.lineHighlightBackground: #E6ECF2, editorCursor.foreground: #2F6FA1, activityBar.background: #DDE4EC, statusBar.background: #DDE4EC } }, editor.tokenColorCustomizations: { [Default Light]: { comments: #6B7A8A, keywords: #2F6FA1, strings: #3E8F8C, functions: #8A6D1F, numbers: #9C5A2A, types: #3D6B99, variables: #1C2733 } }这里的关键还是 [Default Light] 必须和你当前的浅色主题名称完全匹配。同时建议打开 window.autoDetectColorScheme 这个设置它能让 VSCode 跟随系统深浅色模式自动切换当前主题。你只要把系统的深色浅色模式设置好雅蓝就会自动在深夜用暗色版、白天用 Lite 版。这个组合是 VSCode 里最省心的双主题方案不用手动切来切去。4.2 终端、搜索框、滚动条最容易被忽略的配色角落很多人调了半天主题打开集成终端发现还是默认的黑底白字以为 VSCode 的终端不受主题控制。其实终端有一套独立的颜色键叫 terminal.background、terminal.foreground 这组。它们不会自动继承你在 workbench 里设置的编辑器前景背景必须单独声明否则你打开终端满屏还是那个刺眼的黑底白字和编辑器格格不入。workbench.colorCustomizations: { [Default Dark]: { terminal.background: #0C1118, terminal.foreground: #D5DCE6, terminal.ansiBlue: #6A9FD8, terminal.ansiBrightBlue: #7DB4D9, terminal.ansiCyan: #8FBCBB, terminal.ansiYellow: #D9C97C, terminal.ansiGreen: #A3C88A, terminalCursor.foreground: #6A9FD8, scrollbarSlider.background: #2A3B4C, badge.background: #2F6FA1, badge.foreground: #FFFFFF } }除了终端还有一个高频角落是滚动条滑块和搜索结果的角标。滚动条滑块如果沿用默认的浅灰色在蓝灰背景上会显得像一块疤痕建议压成蓝灰。角标是搜索结果里显示匹配数量的小圆标默认蓝色通常能接受但为了整体统一最好也换成雅蓝主色。终端里另外要注意的是 ANSI 颜色编号很多 CLI 工具给输出的蓝色偏紫或者偏亮跑 git diff 或 pytest 时颜色会很突兀。雅蓝这组把 ansiBlue 和 ansiBrightBlue 都校准成同一蓝系是靠做嵌入式开发、整天看串口日志总结出来的经验串口日志工具的颜色五花八门统一 ANSI 色后才能一眼分清 error 和 info。4.3 括号配对面、GitLens、AI 插件高亮谁该听谁的括号配对是深色主题最容易翻车的地方。VSCode 内置了括号配对着色默认在蓝、绿、黄三组循环。如果你同时装了第三方括号高亮插件两边会叠出诡异颜色。我的建议是关掉第三方用内置的然后在 workbench.colorCustomizations 里自定义 bracket-pair 颜色。editor.bracketPairColorization.enabled: true, workbench.colorCustomizations: { [Default Dark]: { editorBracketHighlight.foreground1: #7DB4D9, editorBracketHighlight.foreground2: #8FBCBB, editorBracketHighlight.foreground3: #D9C97C, editorBracketHighlight.foreground4: #6FA8DC, editorBracketHighlight.foreground5: #D19A66, editorBracketHighlight.foreground6: #A8B4C4 } }GitLens、AI 助手这类插件的高亮有自己的颜色体系它们不算主题的一部分。你经常会看到插件给当前行加亮黄色背景、给代码段打装饰色这些颜色基本不受 colorCustomizations 控制除非插件本身开放了相应设置项。所以当你配完大功告成、打开项目后发现某处颜色“没听你的”先别急着怀疑自己的配置按 CtrlShiftP 输入「开发人员: 检查编辑器 token」点一下那个怪异颜色弹出来的列表中会显示实际生效的 scope 和插件来源。这是排查配色的第一手段比翻文档快得多。5. 雅蓝主题常见翻车点对比度、覆盖层与插件冲突排查5.1 改了半天颜色不生效多半是插件覆盖现象明明在 colorCustomizations 里写了 editor.background打开编辑器背景还是原来的样子。原因你装的某个主题扩展或者 UI 美化插件也向同一个颜色键写入了值。VSCode 的合并策略是后加载者胜出插件在启动时把自己的颜色注入优先级高于用户在设置里手写的配置。这是最典型的“我改了配置界面纹丝不动”的血泪场景。解决先在命令面板执行「开发者: 重新加载窗口」把插件彻底重启一遍。如果还不行逐个禁用最近安装的 UI 类插件排查。更稳的做法是回到第 3 章说的主题限定 section把颜色写死到当前主题名下面。禁用插件后你的颜色大概率会弹出来然后你再决定是换插件还是继续手写配置。5.2 注释调到最亮还是看不清现象comments 的 foreground 已经改成接近白色注释依然发灰甚至和背景色糊在一起。原因不是眼睛问题而是当前主题的 textMateRules 里对 comment 的 scope 设置了更低的亮度且权重比你用快捷名设置的更高。很多知名主题把注释设计成“视觉后退”的一层低明度加斜体是刻意为之。你用快捷名调整时VSCode 把它转成基础 scope 的覆盖但主题自身的 textMateRules 权重更高。解决别再用快捷名去硬碰改用 textMateRules把作用域精确到 comment 这一组写 comment.line.double-slash、comment.block 这类明确 scope再补一个 comment 兜底。这样注释亮度才能脱离原主题的黑匣子由你说了算。5.3 打开 TypeScript 项目后关键字颜色突然变了现象写 JavaScript 时关键字是雅蓝的一旦打开 .ts 项目if、return 变成另一种颜色。原因VSCode 内置的语义高亮semantic highlighting生效了。语言服务会把 token 重新分类用自己的语义颜色覆盖 TextMate 的静态配色。TypeScript 语言服务默认做这件事所以你会看到同一个 token 在不同语言里颜色不一样。这不是主题 bug是功能特性。解决如果只想保住雅蓝视觉统一把设置里的 editor.semanticHighlighting.enabled 设为 false让所有语言回归 TextMate 配色。如果你想享受语义高亮的精度比如区分同名变量和枚举那就得在 editor.semanticTokenColorCustomizations 里把语义 token 颜色也按雅蓝色板映射一遍。工作量偏大但这是唯一能兼顾智能着色和主题统一的路线。5.4 集成终端只黑不蓝和编辑器完全是两个世界现象编辑器已经是雅蓝一开 Ctrl终端还是默认黑底输出颜色杂乱。原因终端颜色走独立键位不继承 workbench 的编辑器配色。你以为的“没有配色”其实是出厂默认深色终端配色。解决回到第 4 章那组 terminal.background、terminal.foreground、terminal.ansiBlue 补全别忘了给 terminalCursor.foreground 也设一个否则光标是白色在蓝黑背景下像一道裂缝。补完之后旧终端窗口不会自动刷新关掉重开才生效这个细节踩的人很多。5.5 切换主题后雅蓝残留整个界面像混血现象换了新主题侧边栏、状态栏还是雅蓝的颜色。原因你写的 colorCustomizations 没有带主题限定键属于全局覆盖。换主题后新主题的目标颜色被你全局声明压住了于是出现混血界面。解决检查所有自定义颜色是否都写在 [主题显示名] 限定 section 里。如果你的目标是不管什么主题下面都要雅蓝那就不该靠局部覆盖而是直接做一个自己的主题文件从根上取代默认主题。这也是我把主题扩展放在最后一章的原因真正彻底的做法是拥有一个独立主题而不是用全局配置去污染其他主题。6. 把雅蓝导出成主题扩展从改配置到团队共享6.1 用内置命令把你手头的配色收拢成一个文件先有一份已经调得顺手的雅蓝配置然后打开命令面板输入「开发人员: 从当前设置生成颜色主题」英文环境下是 Developer: Generate Color Theme From Current Settings。VSCode 会把你当前用户设置里所有 colorCustomizations 和 tokenColorCustomizations 汇总、去重生成一份单一 JSON 主题文件并自动打开预览窗口。这个生成器是我最常用的兜底手段它不完美比如会把限定键展开成独立主题但至少能把散落在 settings.json 里的配置收拢成同一份文件。生成的 JSON 里包含 name、colors、tokenColors 三个核心块。colors 对应原来写在 workbench.colorCustomizations 的键值tokenColors 对应 editor.tokenColorCustomizations并按 TextMate 规则展开。把这份 JSON 存为 themes/ya-blue-color-theme.json后续维护这个文件比维护 settings.json 直观得多。6.2 最小主题扩展的工程结构将 JSON 变成扩展其实就是一个最小 package.json 加一个 themes 目录。新建文件夹放 package.json 和 themes/ya-blue-color-theme.json在 package.json 里声明主题贡献点{ name: ya-blue-theme, displayName: Ya Blue Theme, description: 雅蓝配色主题低饱和蓝灰背景适合长时间编码, version: 0.0.1, publisher: your-name, engines: { vscode: ^1.80.0 }, categories: [Themes], contributes: { themes: [ { label: Ya Blue Dark, uiTheme: vs-dark, path: ./themes/ya-blue-color-theme.json } ] } }按 F5 直接启动调试VSCode 会临时打开一个窗口装载这个扩展在主题列表里切到 Ya Blue Dark 就能看到最终效果。这个最小结构不需要发布到市场团队内部足够了。如果想让团队所有成员都装上常见做法是把扩展打包成 vsix 文件发给同事或者放到团队内网扩展市场大家通过扩展面板安装。相比在项目里塞 .vscode/settings.json主题扩展不需要每个成员手改配置装上就一致是团队统一编辑器观感最省心的路径。6.3 验证对比度两个硬指标一个脚本配色做完别急着发出去先跑一遍验证。用任何带计算能力的语言都能算对比度按 WCAG 公式def luminance(rgb): def channel(c): c c / 255 return c / 12.92 if c 0.03928 else ((c 0.055) / 1.055) ** 2.4 r, g, b channel(rgb[0]), channel(rgb[1]), channel(rgb[2]) return 0.2126 * r 0.7152 * g 0.0722 * b def contrast(c1, c2): l1, l2 sorted([luminance(c1), luminance(c2)], reverseTrue) return (l1 0.05) / (l2 0.05) print(contrast((0x10, 0x15, 0x1C), (0xD5, 0xDC, 0xE6)))如果对比度低于 4.5前景文字和背景的辨识度不足白天户外观感会很差。正文级别文字至少要 4.5:1大标题或加粗的变量声明可以放宽到 3:1。这是笨但有效的把关手段比肉眼判断靠谱得多。我每次调完雅蓝都会跑一遍背景与前景、背景与注释、背景与关键字这三组对比把勉强能看清的颜色再往上提一档这比反复截图问别人“看得清吗”快十倍。主题配色从来不是一遍调完的完美配色只存在于展示图里。我自己的习惯是配完雅蓝后把语义高亮开关来回切两次确认没有哪个 token 在两种模式下变成分不清的色块再切到浅色主题盯着看五分钟确认没有刺眼的残留色最后才把这份主题文件写进团队仓库。配色这事儿有点像玄学但至少把对比度做到位、层次拉开、不依赖特定屏幕剩下的就交给个人习惯了。希望帮到你。本文还有配套的精品资源点击获取
VSCode雅蓝配色完全指南：从settings.json自定义到生成主题扩展
简介VScode雅蓝配色主题是一套从HbuilderX编辑器移植到Visual Studio Code的轻量主题资源面向追求清爽编码界面的前端、后端及全栈开发者旨在缓解长时间盯着代码带来的眼部疲劳。资源压缩包体积仅7KB共包含3个JSON文件分别承担主题颜色定义、扩展基础配置和本地化信息结构精简无需安装额外依赖导入后即可快速启用。目前已有2459人下载学习。这套主题以深蓝色调为背景配合淡色文字与柔和的高亮配色能够清晰区分关键字、注释、字符串等元素帮助使用者更快识别代码逻辑与结构。同时JSON配置也便于按个人习惯微调各语法元素的颜色让代码阅读更省力无论日常编码还是调试排查都能借助明确的高亮规则提升效率是希望兼顾美观与实用性的开发者的不错选择。1. 雅蓝配色主题给自己调一套能长期盯着看的蓝色系工作台装好 VSCode 之后大多数人第一件不会做的事就是换主题。默认的 Dark 不是不能用但连续盯上四五个小时纯黑背景加白字的对比会逼着人反复调屏幕亮度眼睛很快就干了。雅蓝配色主题的思路很简单用低饱和的蓝灰做背景、中低亮度的蓝色做界面框架再给语法高亮保留一组克制的色阶让整个编辑器看起来是「冷静」的工作台不是「发光」的广告屏。无论你平时写 Python、C/C、前端还是折腾 ESP32、STM32 这类嵌入式工程这套配色都能直接套进日常环境。这篇笔记不依赖某个现成扩展来兜底直接给你一套能照着抄的 settings.json 配置以及从排错到打包分发的一整条落地路径。新手照着改熟手能拿去做成团队共享的主题文件。2. 雅蓝配色拆解背景、前景、高亮三层为什么要这么设计2.1 蓝色系背景比纯黑更耐看的底层原因很多人以为深色主题就等于省电加护眼其实没这么简单。在 IPS 或者 OLED 屏上纯黑背景意味着像素熄灭整个屏幕只剩编辑器里的亮色文字在发光眼睛要在“一片漆黑”和“局部高亮”之间反复对焦时间一长就疲劳了。雅蓝这种“没黑透”的背景本质是给界面加了一层低亮度的环境光让屏幕变成一张有明暗层次的纸而不是一块黑板上钉着几十个灯泡。人眼对蓝灰色系的对比度感知比纯黑白温和前提是蓝色饱和度压得足够低明度停留在中低档不是那种带荧光感的电蓝。低饱和蓝灰的好处是前景的冷白文字能和背景拉开差距但亮度差没有黑底白字那么剧烈阅读代码时瞳孔不需要频繁缩放。所以护眼的核心指标不是绿色而是亮度差可控雅蓝做的就是控制这件事。从工程角度看背景明度还直接关系到整套色板的校准。如果你选了一套很暗的背景为了让文字可读所有语法高亮色都会被逼着调亮结果整份配色都漂移了。雅蓝把背景明度控制在 8% 到 15% 的区间比纯黑的 0% 高出一截但比常规深色主题的 #1E1E1E 暗一档。这个区间的意义是语法高亮用的中等亮度颜色能自然获得足够的对比度不用为了迁就纯黑背景把所有 token 都调成荧光色。2.2 雅蓝色板参数界面骨骼用什么色代码语义用什么色先给出我实际在用的雅蓝参数后面所有配置都围绕它展开。界面层和代码层分开列方便对照。用途色值HEX说明编辑器背景#10151C蓝黑基调不纯黑编辑器前景#D5DCE6冷白带一点蓝选区背景#1A3A5C蓝灰半透明感当前行高亮#151C26比背景亮一档不刺眼光标#6A9FD8中等蓝色容易定位侧边栏背景#121922比编辑器略亮活动栏背景#0C1118最暗一层压视觉边状态栏背景#0C1118与活动栏呼应语法层这组颜色比界面层更关键它决定你扫代码时第一眼看到什么。注释用 #5C6A7A蓝灰安静退后关键字用 #7DB4D9亮蓝让 if、for、return 这类控制结构浮出来字符串用 #8FBCBB带一点青和关键字区分开函数名用 #D9C97C暖黄是整片蓝色里唯一抢眼的色块用来标记“这里发生了调用”数字和常量用 #D19A66偏橙让魔法数字不至于淹没在代码里。变量名和普通文本保持冷白 #D5DCE6。提示这组颜色不是把所有东西染成蓝色而是让蓝色当主色、暖色当强调色。全蓝一片的编辑器在截图里好看写起代码来根本没层次。补充一个调节经验如果你在具体项目里觉得某两个色太接近优先微调前景而不是背景。背景一动整个界面的明暗层级全部漂移风险大。比如觉得字符串的青和关键字的蓝分不清就先把字符串往 #8FBCBB 这个偏青的方向拉而不是去把背景调深。2.3 界面配色和语法配色为什么要分开调VSCode 的配色机制分成两层这两层千万别混着调。第一层叫 workbench.colorCustomizations管的是编辑器外壳背景、侧边栏、活动栏、状态栏、标签页、滚动条这些是“界面骨骼”。第二层叫 editor.tokenColorCustomizations管的是编辑区里的代码文字而且不是按“文字颜色”这个粗粒度去调是按 Token 类型去调比如关键字、字符串、函数名、注释、常量这些是“语义节点”。把它们分开的直接原因有两个。一是故障隔离如果界面层和语法层写在同一组配置里某天你只想微调函数名颜色手一抖就可能让整个侧边栏变色排查时还得一层层剥。二是组合复用有人喜欢“雅蓝界面加默认语法”有人喜欢“默认界面加雅蓝语法”。雅蓝不是一套写死的主题而是一组可以自由组合的色块我后面给的每段配置都独立成块你可以只挑一段用不用全量梭哈。分开还有一个工程上的好处很多第三方主题其实只改了一层。界面好看的主题语法高亮可能一团糟语法色讲究的主题界面却停留在出厂状态。只要你自己把两层的 colorCustomizations 都声明一遍就等于在你选中的基线上覆盖出自己的雅蓝。这个覆盖层级搞明白了后面第五张里的踩坑排查基本都能自己推出来。3. 用 workbench.colorCustomizations 复刻雅蓝最小配置与逐项参数说明3.1 先打开用户设置 JSON两个入口一个原则在 VSCode 里做两件准备。第一把界面语言切到中文常用操作会好找很多CtrlShiftP 打开命令面板输入“Configure Display Language”装中文语言包后重启。第二打开用户设置 JSONWindows 和 Linux 用 CtrlShiftPmacOS 用 CmdShiftP输入「首选项: 打开用户设置(JSON)」回车。注意选用户级别而不是工作区级别用户级别对当前登录用户的所有项目生效工作区级别只对当前打开的文件夹生效。主题配色属于个人习惯放在用户级别合理团队统一的事放到后面单独谈。打开后你会看到一个 JSON 文件里面可能已经有不少配置项。雅蓝要追加三个 sectionworkbench.colorCustomizations、editor.tokenColorCustomizations以及终端那组小键。这里有一个原则要提前记住直接往文件里写全局键颜色会作用在所有主题上你以后切到别的主题会发现雅蓝的颜色赖着不走界面变成混血。为了避免这种翻车我习惯用“主题限定键”写法也就是在外层套一个中括号加主题名比如 [Default Dark]。这样配置只作用于指定主题换主题不会互相污染。3.2 UI 层把编辑器骨架染成蓝灰{ workbench.colorCustomizations: { [Default Dark]: { editor.background: #10151C, editor.foreground: #D5DCE6, editor.selectionBackground: #1A3A5C, editor.lineHighlightBackground: #151C26, editorCursor.foreground: #6A9FD8, activityBar.background: #0C1118, activityBar.foreground: #D5DCE6, sideBar.background: #121922, sideBar.foreground: #A8B4C4, statusBar.background: #0C1118, statusBar.foreground: #D5DCE6, editorGroupHeader.tabsBackground: #121922, tab.activeBackground: #1A2B3C, tab.activeForeground: #D5DCE6, scrollbarSlider.background: #2A3B4C } } }这段配置管的是界面主骨架。editor.background 是编辑区大背景editor.foreground 是所有普通文本的默认颜色编辑器里所有没被特殊处理的文字都走它是全配置里最关键的一对。editor.selectionBackground 和 editor.lineHighlightBackground 分别是选中代码时的底色、光标所在行的高亮底色建议都用蓝灰系但别太亮太亮了代码一密集就会出现一条明显的发光带。activityBar 是左侧那个竖排图标栏我把它压到最暗让图标浮出来sideBar 是资源管理器那一片比编辑区稍亮形成层次statusBar 是最底下的状态栏压暗是为了不抢编辑区的注意力。关于 [Default Dark] 这个键名有一个必须注意的细节如果你当前用的主题不是 Default Dark 而是一套第三方主题这段配置不会生效。正确做法是把方括号里的名字改成你当前主题的完整显示名怎么确认打开命令面板输入「Preferences: Color Theme」中文界面输入“颜色主题”看列表里当前选中项的名字或者直接打开设置搜索 workbench.colorTheme那里显示的就是完整主题名。想同时兼顾多套主题就复制多个这种 section各自指定主题名。3.3 语法层按 Token 类型给代码染色{ editor.tokenColorCustomizations: { [Default Dark]: { comments: #5C6A7A, keywords: #7DB4D9, strings: #8FBCBB, functions: #D9C97C, numbers: #D19A66, types: #6FA8DC, variables: #D5DCE6, textMateRules: [ { scope: punctuation.definition.keyword, settings: { foreground: #7DB4D9 } }, { scope: entity.name.function, settings: { foreground: #D9C97C, fontStyle: } } ] } } }comments、keywords 这些是 VSCode 提供的语义快捷名内部会映射到一串 TextMate scope。举个例子keywords 不只是 keyword.control还包括 keyword.operator 之类的一堆。快捷名的好处是写法简单坏处是你没法精确控制某个小类比如只想把 if 调亮、不想让 return 也变亮快捷名做不到。这时候就要用 textMateRules里面写真正的 scope 名。调试阶段可以用命令面板里的“开发人员: 检查编辑器 token”来查看鼠标悬停处具体命中了哪个 scope。textMateRules 的作用域覆盖优先级高于快捷名。如果你在快捷名里把 keywords 设为蓝色又用 textMateRules 精确指定了 punctuation.definition.keyword 的颜色那么这类标点最终显示 textMateRules 里的值。这是双刃剑能带来精确控制也会让后续排查变麻烦。我建议在还没完全弄清 scope 层级前只用快捷名等需要处理模板字符串里的 ${} 这类拼接语法时再去碰 textMateRules。字体样式这里也有一个隐藏参数。fontStyle 可以设 italic、bold也可以留空。我习惯让注释保持正常字重不加斜体因为斜体在等宽字体里辨识度其实不高连续几行注释会糊成一片。函数名也不加粗加粗会让高频出现的函数调用显得太吵。真正值得加粗的是少数声明类关键字这个可以单独在 textMateRules 里按 scope 补上。4. 深浅色跟随、终端与括号配色让雅蓝在真实项目里不打架4.1 给浅色场景配一套「雅蓝 Lite」深色雅蓝适合长时间写代码但白天坐在窗边或者灯很亮的会议室里深色屏幕会反射环境光反而看不清。我的做法是准备一套同色相的浅色版背景提到近白保留蓝灰层级语法色相不变但整体加深明度。这样你用快捷键或者让系统自动切换视觉不会跳得离谱。workbench.colorCustomizations: { [Default Light]: { editor.background: #F2F4F7, editor.foreground: #1C2733, editor.selectionBackground: #BBD4EA, editor.lineHighlightBackground: #E6ECF2, editorCursor.foreground: #2F6FA1, activityBar.background: #DDE4EC, statusBar.background: #DDE4EC } }, editor.tokenColorCustomizations: { [Default Light]: { comments: #6B7A8A, keywords: #2F6FA1, strings: #3E8F8C, functions: #8A6D1F, numbers: #9C5A2A, types: #3D6B99, variables: #1C2733 } }这里的关键还是 [Default Light] 必须和你当前的浅色主题名称完全匹配。同时建议打开 window.autoDetectColorScheme 这个设置它能让 VSCode 跟随系统深浅色模式自动切换当前主题。你只要把系统的深色浅色模式设置好雅蓝就会自动在深夜用暗色版、白天用 Lite 版。这个组合是 VSCode 里最省心的双主题方案不用手动切来切去。4.2 终端、搜索框、滚动条最容易被忽略的配色角落很多人调了半天主题打开集成终端发现还是默认的黑底白字以为 VSCode 的终端不受主题控制。其实终端有一套独立的颜色键叫 terminal.background、terminal.foreground 这组。它们不会自动继承你在 workbench 里设置的编辑器前景背景必须单独声明否则你打开终端满屏还是那个刺眼的黑底白字和编辑器格格不入。workbench.colorCustomizations: { [Default Dark]: { terminal.background: #0C1118, terminal.foreground: #D5DCE6, terminal.ansiBlue: #6A9FD8, terminal.ansiBrightBlue: #7DB4D9, terminal.ansiCyan: #8FBCBB, terminal.ansiYellow: #D9C97C, terminal.ansiGreen: #A3C88A, terminalCursor.foreground: #6A9FD8, scrollbarSlider.background: #2A3B4C, badge.background: #2F6FA1, badge.foreground: #FFFFFF } }除了终端还有一个高频角落是滚动条滑块和搜索结果的角标。滚动条滑块如果沿用默认的浅灰色在蓝灰背景上会显得像一块疤痕建议压成蓝灰。角标是搜索结果里显示匹配数量的小圆标默认蓝色通常能接受但为了整体统一最好也换成雅蓝主色。终端里另外要注意的是 ANSI 颜色编号很多 CLI 工具给输出的蓝色偏紫或者偏亮跑 git diff 或 pytest 时颜色会很突兀。雅蓝这组把 ansiBlue 和 ansiBrightBlue 都校准成同一蓝系是靠做嵌入式开发、整天看串口日志总结出来的经验串口日志工具的颜色五花八门统一 ANSI 色后才能一眼分清 error 和 info。4.3 括号配对面、GitLens、AI 插件高亮谁该听谁的括号配对是深色主题最容易翻车的地方。VSCode 内置了括号配对着色默认在蓝、绿、黄三组循环。如果你同时装了第三方括号高亮插件两边会叠出诡异颜色。我的建议是关掉第三方用内置的然后在 workbench.colorCustomizations 里自定义 bracket-pair 颜色。editor.bracketPairColorization.enabled: true, workbench.colorCustomizations: { [Default Dark]: { editorBracketHighlight.foreground1: #7DB4D9, editorBracketHighlight.foreground2: #8FBCBB, editorBracketHighlight.foreground3: #D9C97C, editorBracketHighlight.foreground4: #6FA8DC, editorBracketHighlight.foreground5: #D19A66, editorBracketHighlight.foreground6: #A8B4C4 } }GitLens、AI 助手这类插件的高亮有自己的颜色体系它们不算主题的一部分。你经常会看到插件给当前行加亮黄色背景、给代码段打装饰色这些颜色基本不受 colorCustomizations 控制除非插件本身开放了相应设置项。所以当你配完大功告成、打开项目后发现某处颜色“没听你的”先别急着怀疑自己的配置按 CtrlShiftP 输入「开发人员: 检查编辑器 token」点一下那个怪异颜色弹出来的列表中会显示实际生效的 scope 和插件来源。这是排查配色的第一手段比翻文档快得多。5. 雅蓝主题常见翻车点对比度、覆盖层与插件冲突排查5.1 改了半天颜色不生效多半是插件覆盖现象明明在 colorCustomizations 里写了 editor.background打开编辑器背景还是原来的样子。原因你装的某个主题扩展或者 UI 美化插件也向同一个颜色键写入了值。VSCode 的合并策略是后加载者胜出插件在启动时把自己的颜色注入优先级高于用户在设置里手写的配置。这是最典型的“我改了配置界面纹丝不动”的血泪场景。解决先在命令面板执行「开发者: 重新加载窗口」把插件彻底重启一遍。如果还不行逐个禁用最近安装的 UI 类插件排查。更稳的做法是回到第 3 章说的主题限定 section把颜色写死到当前主题名下面。禁用插件后你的颜色大概率会弹出来然后你再决定是换插件还是继续手写配置。5.2 注释调到最亮还是看不清现象comments 的 foreground 已经改成接近白色注释依然发灰甚至和背景色糊在一起。原因不是眼睛问题而是当前主题的 textMateRules 里对 comment 的 scope 设置了更低的亮度且权重比你用快捷名设置的更高。很多知名主题把注释设计成“视觉后退”的一层低明度加斜体是刻意为之。你用快捷名调整时VSCode 把它转成基础 scope 的覆盖但主题自身的 textMateRules 权重更高。解决别再用快捷名去硬碰改用 textMateRules把作用域精确到 comment 这一组写 comment.line.double-slash、comment.block 这类明确 scope再补一个 comment 兜底。这样注释亮度才能脱离原主题的黑匣子由你说了算。5.3 打开 TypeScript 项目后关键字颜色突然变了现象写 JavaScript 时关键字是雅蓝的一旦打开 .ts 项目if、return 变成另一种颜色。原因VSCode 内置的语义高亮semantic highlighting生效了。语言服务会把 token 重新分类用自己的语义颜色覆盖 TextMate 的静态配色。TypeScript 语言服务默认做这件事所以你会看到同一个 token 在不同语言里颜色不一样。这不是主题 bug是功能特性。解决如果只想保住雅蓝视觉统一把设置里的 editor.semanticHighlighting.enabled 设为 false让所有语言回归 TextMate 配色。如果你想享受语义高亮的精度比如区分同名变量和枚举那就得在 editor.semanticTokenColorCustomizations 里把语义 token 颜色也按雅蓝色板映射一遍。工作量偏大但这是唯一能兼顾智能着色和主题统一的路线。5.4 集成终端只黑不蓝和编辑器完全是两个世界现象编辑器已经是雅蓝一开 Ctrl终端还是默认黑底输出颜色杂乱。原因终端颜色走独立键位不继承 workbench 的编辑器配色。你以为的“没有配色”其实是出厂默认深色终端配色。解决回到第 4 章那组 terminal.background、terminal.foreground、terminal.ansiBlue 补全别忘了给 terminalCursor.foreground 也设一个否则光标是白色在蓝黑背景下像一道裂缝。补完之后旧终端窗口不会自动刷新关掉重开才生效这个细节踩的人很多。5.5 切换主题后雅蓝残留整个界面像混血现象换了新主题侧边栏、状态栏还是雅蓝的颜色。原因你写的 colorCustomizations 没有带主题限定键属于全局覆盖。换主题后新主题的目标颜色被你全局声明压住了于是出现混血界面。解决检查所有自定义颜色是否都写在 [主题显示名] 限定 section 里。如果你的目标是不管什么主题下面都要雅蓝那就不该靠局部覆盖而是直接做一个自己的主题文件从根上取代默认主题。这也是我把主题扩展放在最后一章的原因真正彻底的做法是拥有一个独立主题而不是用全局配置去污染其他主题。6. 把雅蓝导出成主题扩展从改配置到团队共享6.1 用内置命令把你手头的配色收拢成一个文件先有一份已经调得顺手的雅蓝配置然后打开命令面板输入「开发人员: 从当前设置生成颜色主题」英文环境下是 Developer: Generate Color Theme From Current Settings。VSCode 会把你当前用户设置里所有 colorCustomizations 和 tokenColorCustomizations 汇总、去重生成一份单一 JSON 主题文件并自动打开预览窗口。这个生成器是我最常用的兜底手段它不完美比如会把限定键展开成独立主题但至少能把散落在 settings.json 里的配置收拢成同一份文件。生成的 JSON 里包含 name、colors、tokenColors 三个核心块。colors 对应原来写在 workbench.colorCustomizations 的键值tokenColors 对应 editor.tokenColorCustomizations并按 TextMate 规则展开。把这份 JSON 存为 themes/ya-blue-color-theme.json后续维护这个文件比维护 settings.json 直观得多。6.2 最小主题扩展的工程结构将 JSON 变成扩展其实就是一个最小 package.json 加一个 themes 目录。新建文件夹放 package.json 和 themes/ya-blue-color-theme.json在 package.json 里声明主题贡献点{ name: ya-blue-theme, displayName: Ya Blue Theme, description: 雅蓝配色主题低饱和蓝灰背景适合长时间编码, version: 0.0.1, publisher: your-name, engines: { vscode: ^1.80.0 }, categories: [Themes], contributes: { themes: [ { label: Ya Blue Dark, uiTheme: vs-dark, path: ./themes/ya-blue-color-theme.json } ] } }按 F5 直接启动调试VSCode 会临时打开一个窗口装载这个扩展在主题列表里切到 Ya Blue Dark 就能看到最终效果。这个最小结构不需要发布到市场团队内部足够了。如果想让团队所有成员都装上常见做法是把扩展打包成 vsix 文件发给同事或者放到团队内网扩展市场大家通过扩展面板安装。相比在项目里塞 .vscode/settings.json主题扩展不需要每个成员手改配置装上就一致是团队统一编辑器观感最省心的路径。6.3 验证对比度两个硬指标一个脚本配色做完别急着发出去先跑一遍验证。用任何带计算能力的语言都能算对比度按 WCAG 公式def luminance(rgb): def channel(c): c c / 255 return c / 12.92 if c 0.03928 else ((c 0.055) / 1.055) ** 2.4 r, g, b channel(rgb[0]), channel(rgb[1]), channel(rgb[2]) return 0.2126 * r 0.7152 * g 0.0722 * b def contrast(c1, c2): l1, l2 sorted([luminance(c1), luminance(c2)], reverseTrue) return (l1 0.05) / (l2 0.05) print(contrast((0x10, 0x15, 0x1C), (0xD5, 0xDC, 0xE6)))如果对比度低于 4.5前景文字和背景的辨识度不足白天户外观感会很差。正文级别文字至少要 4.5:1大标题或加粗的变量声明可以放宽到 3:1。这是笨但有效的把关手段比肉眼判断靠谱得多。我每次调完雅蓝都会跑一遍背景与前景、背景与注释、背景与关键字这三组对比把勉强能看清的颜色再往上提一档这比反复截图问别人“看得清吗”快十倍。主题配色从来不是一遍调完的完美配色只存在于展示图里。我自己的习惯是配完雅蓝后把语义高亮开关来回切两次确认没有哪个 token 在两种模式下变成分不清的色块再切到浅色主题盯着看五分钟确认没有刺眼的残留色最后才把这份主题文件写进团队仓库。配色这事儿有点像玄学但至少把对比度做到位、层次拉开、不依赖特定屏幕剩下的就交给个人习惯了。希望帮到你。本文还有配套的精品资源点击获取