我很少为一篇配置类的小教程单独立项写文章，但“vscode设置代码字体”这个看似简单的话题，实际上藏着不少值得展开讲的东西。很多开发者在换编辑器、换电脑、或者刚入坑 VSCode 的时候，第一件事是装插件、配主题，代码字体往往被随手忽略。但字体恰恰是你每天盯着屏幕八个小时最值得花时间调的一项——它影响的不是审美，而是眼睛的疲劳速度，甚至你写代码时的思维流畅度。这篇文章不打算只扔给你一行配置命令，而是把字体设置背后的逻辑、常见误区和真正好用的字体方案一次性讲清楚。
1. 字体配置为什么值得单独写一篇：不只是“好不好看”
先说一个反直觉的结论：代码字体选得好不好，直接影响你的编码效率和错误率，而不是单纯的视觉偏好。我见过不少团队里，大家用同一个主题、同一套插件，但每个人打开同一个文件看到的排版完全不同，问题往往就出在字体上。
1.1 字体影响的是“元素辨识”，不是观感
代码里充满了大量形状相近的字符组合。最典型的是英文字母l（小写 L）、I（大写 i）、数字1，以及数字0、大写字母O、小写字母o。如果你用系统中文字体（比如微软雅黑、苹方）或者默认的西文字体来写代码，这几个字符在一段代码里混在一起时，你几乎无法快速区分。这在阅读长变量名、判断赋值语句、排查 Bug 时是实实在在的障碍。
好的代码字体会专门在字形设计上区分这些容易混淆的字符。比如0中间加一个点或者斜杠，1带明显的衬线底座，l带一个弯钩。这些看起来是很小的设计差异，但在你连续盯了三四个小时代码之后，差别会被放大得非常明显。我自己的亲身体验是：换用专门为代码设计的等宽字体之后，读代码时的“卡顿感”减少了，某些奇怪的变量名错误也能更快地扫出来。
1.2 等宽对齐是代码可读性的隐形支柱
代码和普通文本最大的不同在于：代码需要对齐。无论是缩进、多行连续赋值、注释对齐，还是表格状的数组结构，都依赖字符宽度一致才能形成清晰的视觉网格。中文字体或者比例字体（比如 Arial、Helvetica）每个字符的宽度都不一样，放到代码里就会出现错位、参差不齐，读起来非常难受。
这也是为什么 VSCode 默认就会使用等宽字体，比如Consolas。但“默认可用”和“最优配置”之间还有很长一段距离。真正的问题是：默认字体往往只覆盖了英文场景，一旦代码里混入中文注释、中文日志，字体渲染就会自动回退到系统中文字体，导致中英文混排时高度、基线、行距不协调，整个编辑器的视觉效果一下子变得很“脏”。这个问题的解法，就是后面要讲到的字体回退（fallback）配置。
1.3 字体与编码疲劳的生理关联
还有一个经常被忽略的维度：字体渲染的清晰度会影响眼睛的调节负担。低质量的字体往往笔画粗细不均匀、锯齿感强，长时间阅读容易导致视疲劳；而设计良好的代码字体笔画清晰、在屏幕上的渲染针对像素网格做过优化（尤其是有 hinting 优化的字体），眼睛会轻松很多。加上字号、行高、字间距的合理搭配，等于给你的眼睛做了一次“人体工学调整”。
所以，这篇文章的适用范围其实很广：如果你是刚用 VSCode 写代码的新手，可以直接照抄配置；如果你是老手但从来没在意过字体，这篇文章也能帮你审视一下当前设置是否有可优化空间。后面我们从原理讲起，最后落到可以直接抄的配置方案。
2. 代码字体的核心逻辑：等宽、连字与中英文混排
很多第一次接触字体配置的人会问：为什么代码不能用系统默认字体？为什么大家都在推荐 Fira Code、JetBrains Mono 这些名字奇奇怪怪的字体？要理解这个问题，得先搞清楚代码字体的三个底层逻辑：等宽、连字、以及字体回退。
2.1 等宽字体（Monospace Font）的工作原理
等宽字体指的是字体中每个字符的水平宽度完全相等。打字机时代因为机械结构限制，所有字符必须占用同样的宽度，后来这个特性被代码编辑器继承了下来。等宽的核心价值是“对齐”：当上下两行代码都以相同数量的字符开头时，它们会在屏幕上形成整齐的列，多行参数、表格数据、缩进层级一眼就能看清。
常见等宽字体之间的差异，主要在于字形细节，而不是“是否等宽”。比如：
Consolas是 Windows 系统自带的等宽字体，字形清晰，但风格偏朴素；Courier New也是老牌等宽字体，但笔画偏细、复古感强，现代屏幕上观感一般；Fira Code、JetBrains Mono则是在等宽基础上加入了更多为程序员服务的字形设计，比如连字、对消歧字符的特别处理。
对 VSCode 来说，只要editor.fontFamily指定的字体本身是等宽的，编辑器就能正常做对齐。但要注意，字体列表里如果包含非等宽字体（比如中文字体），VSCode 在渲染某些字符时会去匹配它，这时对齐规则会按照字体回退机制处理，整体视觉上仍然以英文字体的等宽宽度为主。
2.2 连字（Ligature）到底是什么
连字是近十年代码字体最出圈的功能。简单说，就是把两个或三个字符在视觉上合并成一个更符合语义的符号。比如：
->变成一个更长的箭头符号；=>变成一个实心箭头；!=变成不等号；===变成一个三横线等号；<=、>=变成数学上的小于等于、大于等于。
它的价值不只是“好看”。对于经常写 C、Java、JavaScript、Python 的人来说，=>、->、===这类符号出现的频率极高。用连字渲染后，这些多字符运算符在视觉上被“压缩”成一个语义单元，大脑解析代码时会更快地把它们识别为“一个操作符”，而不是“两个或三个字符的组合”。这在读长表达式时能明显降低认知负担。
但连字功能不是所有字体都支持。它依赖字体本身包含对应的字形，同时需要编辑器开启fontLigatures设置。VSCode 中默认情况下这个设置是启用的，但如果你指定的字体不支持连字，开启也没用。后面我会给出支持连字的字体列表和具体配置方式。
2.3 中英文混排与字体回退机制
这是很多中文开发者最容易踩坑的地方。VSCode 的字体配置允许你设置一个字体列表（font stack），渲染时按顺序查找：如果第一个字体不包含某个字符，就尝试下一个字体；如果所有字体都不包含，就交给系统默认字体兜底。
举个例子，你的配置是：
"editor.fontFamily": "'Fira Code', 'Microsoft YaHei', monospace"这时候英文和代码符号优先用 Fira Code，遇到中文字符时 Fira Code 没有，就会回退到微软雅黑；如果微软雅黑也没有（比如某些特殊符号），就回退到monospace这个通用字体族。
理解了这个机制，很多问题的原因就清楚了：为什么有的人设置了好的西文字体，但中文注释还是“变难看了”？因为系统回退到了默认中文字体，而你没有主动指定中文回退字体。为什么要主动指定？因为不同中文字体的行高、基线差异很大，与西文字体混排时容易出现上下错位、大小不一的问题。选一个与主字体风格协调的中文字体作为回退，整个代码才显得干净。
2.4 字体渲染的细节：hinting、抗锯齿与屏幕表现
还有一个影响实际观感的因素是渲染方式。VSCode 基于 Electron（Chromium），字体渲染的默认方式在不同操作系统上不同：在 Windows 上通常使用 DirectWrite + ClearType，在 macOS 上使用 Core Text，在 Linux 上则依赖 FreeType 和你的字体渲染配置。这导致同一个字体在不同系统上的观感差别很大。
比如Consolas在 Windows 上表现很好，但在 macOS 上因为没有专门的 hinting 优化，显示效果偏淡。反过来，Menlo是 macOS 自带的优秀代码字体，在 Linux 上可能没那么好。这个问题没有统一答案，只能靠实测。后面的配置案例里，我会按操作系统给出推荐组合，帮你避开这些平台差异的坑。
3. 动手配置：settings.json 里的几个关键参数
讲完原理，进入实操环节。VSCode 的字体设置分散在几个参数里，绝大多数情况下你只需要修改settings.json就够了，不需要安装任何插件。如果你对 JSON 配置不熟，完全可以放心，这里给出的都是可以直接粘贴的完整配置。
3.1 打开配置的两种方式
第一种是图形界面操作：点击左下角齿轮图标 → 选择 “设置”，然后在搜索框输入font，就能看到所有与字体相关的配置项，直接可视化修改。
第二种更高效的方式是直接编辑配置文件：点击右下角齿轮 → “命令面板”（快捷键Ctrl+Shift+P/Cmd+Shift+P）→ 输入open settings→ 选择 “首选项: 打开用户设置(JSON)”，就能直接编辑settings.json。
我建议所有 VSCode 用户都学会第二种方式。因为你最终可能会积累一套统一的环境配置，放在用户级settings.json里，换电脑、换系统时直接拷贝一份就完成迁移了。而且字体参数就那么几行，在 JSON 里看远比在图形界面里来回翻页直观。
3.2 核心参数逐项拆解
VSCode 的字体相关配置项主要有五个：
| 参数 | 作用 | 默认值 |
|---|---|---|
editor.fontFamily | 编辑器主体字体（含回退列表） | Consolas, 'Courier New', monospace |
editor.fontSize | 编辑器字体大小（px） | 14 |
editor.fontWeight | 字体粗细 | normal |
editor.fontLigatures | 是否开启连字 | true |
editor.letterSpacing | 字符间距（px） | 0 |
editor.lineHeight | 行高倍数 | 0（自动） |
其中核心是editor.fontFamily。它的写法要特别注意：字体名如果包含空格，必须用单引号包裹，多个字体之间用英文逗号加空格分隔。比如：
"editor.fontFamily": "'JetBrains Mono', 'Sarasa Term SC', 'Microsoft YaHei', monospace"这里第一项是主字体（英文 + 代码符号），第二项和第三项是中文字体回退，最后monospace是兜底通用字体族。VSCode 渲染时字符匹配顺序是从左到右，意味着英文优先用 JetBrains Mono，中文则依次尝试 Sarasa Term SC（更纱黑体）和微软雅黑。
editor.fontSize和editor.lineHeight是配套调整的。如果你把字号调大，最好同步把行高稍微调大一些，否则行与行之间会显得拥挤，代码块缺乏呼吸感。一般经验是字号 14、行高 1.5 左右是比较舒适的起步值；如果你屏幕分辨率高、喜欢更紧凑的排版，可以字小一号、行高也相应调低。
editor.fontLigatures默认是true，但如果你想明确控制，可以写成字符串形式，比如"editor.fontLigatures": true。个别字体支持更细粒度的连字控制（通过设置字体特性参数），但绝大多数场景下用布尔值就够了。
3.3 一份可直接复制的基础配置
这里给出一份覆盖常见场景的配置，可以直接粘贴进你的settings.json：
{ "editor.fontSize": 14, "editor.lineHeight": 1.6, "editor.fontFamily": "'JetBrains Mono', 'Sarasa Term SC', 'Microsoft YaHei', monospace", "editor.fontLigatures": true, "editor.fontWeight": "normal", "editor.letterSpacing": 0.5 }这份配置的思路是：英文部分用 JetBrains Mono 保证字形质量和连字支持，中文部分用 Sarasa Term SC（更纱黑体）保证中英文高度协调，Windows 用户如果没有安装更纱黑体，会自动回退到微软雅黑。letterSpacing设置为 0.5 是为了让字符之间稍微有一点空隙，利于长时间阅读，如果你喜欢紧凑风格，可以改回 0 或者干脆删除这一行。
注意：fontWeight默认是normal，也可以设置成"bold"或者数值（如500），但如果不是有特殊需求，建议保持默认。部分字体在加粗状态下连字和字符间距的渲染并不理想。
3.4 工作区级配置与用户级配置的区别
VSCode 的settings.json分三个层级：用户级、工作区级、文件夹级。用户级配置对所有项目生效；工作区级配置只在当前打开的文件夹/工作区生效，通常存在.vscode/settings.json里；文件夹级则是针对某个目录更精细的控制。
字体设置一般推荐放在用户级。因为它是个人偏好，不应该跟着项目走。如果团队对代码风格和编辑器配置有统一要求（比如要求所有人开启editor.fontLigatures），才考虑把字体相关配置放到团队共享的工作区配置里。不过这种情况比较少见。
工作区级配置的一个常见坑是：如果你在某个项目里设置了一个字体，但它在你电脑上没安装，VSCode 不会报错，而是直接静默回退到系统字体。排查时很容易被忽略，所以当你发现某台机器上字体“不生效”时，第一反应应该是检查当前打开的工作区是否有覆盖配置。
3.5 字体安装完成后的验证
配置修改完后，怎么确认字体真的生效了？有个小技巧：在 VSCode 的命令面板里执行 “开发人员: 检查编辑器字体和连字”（Developer: Inspect Editor Tokens and Scopes），然后点一下你的代码，右侧面板会显示当前使用的字体名称。如果显示的是你配置的主字体，说明生效；如果显示的是 fallback 字体，说明主字体没有被正确加载。
另一个更直观的验证方式是：专门打开一个包含中文注释、英文代码、=>、->、!==等符号的测试文件，肉眼确认中英文混排是否协调、连字是否正常渲染。这个后面章节会有更详细的经验分享。
4. 值得一试的代码字体与组合方案
市面上优秀的编程字体不少，但每个字体的设计侧重点不同。我按使用场景把它们分了类，你不必每个都装，选一个主字体 + 一个中文字体回退，就足够应付绝大多数项目了。
4.1 主字体推荐
JetBrains Mono：这是 IntelliJ IDEA 团队推出的开源字体，专为代码阅读设计。它的特点是大写字母比小写字母略高，数字在表格里对齐效果很好，而且自带完整的连字支持。重点是它的字形设计跟 VSCode 的默认配色主题搭配非常协调，给人一种“清晰但不扎眼”的感觉。如果你不知道选什么，直接选它，基本不会出错。
Fira Code：最早把连字功能带火的字体，也是很多人的入门选择。带连字的箭头、等号、比较运算符号看起来非常有科技感。不过要注意 Fira Code 的字符相对较窄，如果你喜欢宽一点的排版，可能需要把字号调大。
Cascadia Code：微软出品，是 Windows Terminal 和 PowerShell 的默认字体，也适用于 VSCode。它的设计理念是“现代、有辨识度”，连字风格比较内敛，没有 Fira Code 那么张扬，但阅读舒适度很高。尤其是在 Windows 上，与系统的整合度很好。
Source Code Pro：Adobe 开源的经典字体，风格偏中性、稳重，没有太多花哨的连字设计，但字形的可读性极佳。如果你反感连字效果、只想要纯等宽字体，Source Code Pro 会是一个很可靠的选择。
IBM Plex Mono：IBM 开源的等宽字体，特征是带一点复古 IBM 打字机的机械感，字重选择多，观感独特。适合想跟别人“不太一样”但又不想牺牲可读性的场景。
Hack：一个专门面向源码阅读的开源字体，也是老牌选择，字形设计严谨，和 JetBrains Mono、Cascadia Code 相比风格更传统，但它体积小、渲染性能好，在低配机器上和远程开发场景下表现更稳定。
| 字体 | 连字 | 开源 | 风格 | 适合场景 |
|---|---|---|---|---|
| JetBrains Mono | 支持 | 是 | 现代清晰 | 通用首选 |
| Fira Code | 支持 | 是 | 科技感强 | 喜欢连字效果 |
| Cascadia Code | 支持 | 是 | 微软风格 | Windows 默认替换 |
| Source Code Pro | 不支持原生连字 | 是 | 稳重中性 | 不需要连字 |
| IBM Plex Mono | 不支持原生连字 | 是 | 机械感 | 个性化选择 |
| Hack | 不支持 | 是 | 传统严谨 | 远程/低配环境 |
4.2 中文字体回退方案
讲完了主字体，中文回退字体同样重要。理想的中文回退字体需要满足两个条件：一是字形风格与西文字体协调，二是行高和基线尽量一致，不会导致中英文混排时高度错位。
Sarasa Term SC（更纱黑体）：这是我目前最推荐的方案。它是专门针对“终端 + 代码编辑器”场景优化的字体项目，把英文等宽字体和中文黑体结合在了一起，中英文的基线、高度配合得非常好。它的英文部分还集成了 IBM Plex Mono 的字形，中文部分则是思源黑体的改版，整体观感非常统一。
Microsoft YaHei（微软雅黑）：Windows 系统自带，不需要额外安装，胜在“零成本”。问题是它的中文字体基线偏高，行间距偏大，与大多数西文字体混排时会显得中文略微偏大，视觉效果不如更纱黑体精致。但如果你不想折腾安装新字体，用它是完全可行的。
PingFang SC（苹方）：macOS 系统的默认中文黑体，和 macOS 上的原生渲染风格高度匹配。如果你用 Mac，中文字体回退设置PingFang SC是比较稳妥的选择。
WenQuanYi Micro Hei（文泉驿微米黑）：Linux 发行版上最常见的开源中文黑体，虽然字形不算精致，但胜在普遍存在，也不容易出问题。
实际配置时，中文字体应该放在主字体后面作为回退。我更推荐这种做法：即使在纯英文代码中，编辑器也可能遇到零宽字符、特殊符号等情况，这些符号往往会交给后面的字体处理，所以回退列表越完整越好。
4.3 不同操作系统的安装与配置差异
Windows 安装字体最简单：下载字体文件（通常是.ttf或.otf），右键 → “为所有用户安装”，或者双击打开后点击“安装”。装完后最好重启一次 VSCode，因为字体缓存不一定能实时刷新。
macOS 只需要双击字体文件，在弹出的“字体册”窗口中点击“安装字体”，安装后会全局生效。但注意，macOS 对字体渲染和 Windows 不一样，同一个字体在 Mac 上显示效果可能更“细”。你可以适当调整fontWeight到"medium"或500来补偿。
Linux 上需要把字体文件放入~/.local/share/fonts或/usr/share/fonts，然后运行fc-cache -f刷新字体缓存。很多发行版在图形界面上双击字体文件也能一键安装，但命令行方式最通用。装完之后用fc-list | grep -i "jetbrains"验证字体是否被系统识别。
4.4 我的长期配置组合参考
我自己在用的组合是：
- Windows 主机：
Cascadia Code+Microsoft YaHei，关闭连字保持传统风格； - macOS 笔记本：
JetBrains Mono+PingFang SC，开启连字； - Linux 服务器环境（VSCode Server 场景）：
Hack+WenQuanYi Micro Hei，因为远程环境下字体加载越轻量越好。
这个组合不是因为它们“最新”，而是在各自平台经过了长期验证、渲染效果稳定、不会出莫名其妙的兼容问题。如果你有精力折腾，也完全可以试试 Fira Code 配更纱黑体的组合，视觉效果很惊艳。
5. 进阶玩法与常见问题的排查
基本的字体配置搞定之后，你可能会遇到一些“明明配了但看着不对”的情况。这一节总结了我自己折腾字体配置时踩过的坑，以及一些进阶的设置技巧。
5.1 编辑器与终端字体分离设置
VSCode 内置了一个集成终端（Terminal），它的字体默认跟随编辑器的editor.fontFamily设置，但实际上可以不跟随。终端字体由terminal.integrated.fontFamily控制，默认值为空，表示继承编辑器设置。
我建议在工作区或者用户设置里把终端字体单独设置：
{ "terminal.integrated.fontFamily": "'JetBrains Mono', 'Sarasa Term SC', 'Microsoft YaHei', monospace", "terminal.integrated.fontSize": 13 }这样做的好处是：编辑器里你可能喜欢大一点的字号和行高，但终端窗口往往显示的是命令行输出、Git 状态、日志，更紧凑的排布有利于观察更多内容。我的习惯是编辑器字号 14、行高 1.6，终端字号 13、行高 1.3。
另外，如果你常用的命令行工具有一些特殊的 Unicode 符号（比如 git 分支状态的图标、文件类型图标），这些符号通常在终端字体里才能正常显示。如果终端里出现方框或乱码，大概率是终端字体没有正确匹配到带这些图标的 Nerd Font（下文会讲）或中文字体。
5.2 配合主题与图标字体的整体体验优化
代码字体不是孤立存在的，它和 VSCode 的主题、图标字体协同作用。很多用户装了 Material Icon Theme、Symbols 之类的插件后，会发现侧边栏和编辑器里出现一些不常见的图标字符，这些字符如果当前字体不支持，就会显示为方块或者问号。
解决方案是安装一款“Nerd Font”风格的字体。Nerd Font 社区把大量图标字形（如文件类型图标、Git 图标、系统图标）合并到了常见的编程字体里，这样你在终端、资源管理器、代码小地图里都能看到完整图标。常见的 Nerd Font 有 JetBrainsMono Nerd Font、FiraCode Nerd Font、CaskaydiaCove Nerd Font 等。
安装后，配置editor.fontFamily时使用 Nerd Font 版本的字体名，图标就不会再出现方块。但要注意：Nerd Font 版本的字体会把图标字形混入字体中，可能会导致部分代码符号的显示变“粗”或者不规范，有些人会因此不习惯。我个人的建议是：编辑器主体字体用原版，终端字体用 Nerd Font 版，这样兼顾两者。
5.3 字体“配置了但没生效”的排查链路
这是一个非常高频的问题。以下是完整的排查顺序：
第一步，确认字体是否真的安装了。在系统字体设置（Windows 的字体设置、macOS 的字体册、Linux 的fc-list）里搜索字体名称，找不到就是没装上。很多人直接复制网上的配置，但字体文件根本没下载，配置自然无效。
第二步，确认字体名称是否写对了。VSCode 对字体名大小写不敏感，但对空格和连字符敏感。比如JetBrains Mono不能写成JetBrainsMono（除非你安装的是不带空格的版本），Sarasa Term SC不能写成Sarasa Term SC以外的名称。最简单的办法是在系统里复制字体属性的“字体名称”栏目里显示的名字。
第三步，检查是否有工作区级配置覆盖。打开命令面板，输入Preferences: Open Workspace Settings (JSON)，看里面有没有editor.fontFamily或editor.letterSpacing之类的设置。工作区配置优先级高于用户设置，如果这里有旧配置，你的全局设置就无效。
第四步，重启 VSCode 或重载窗口。字体配置是即时生效的，但字体文件的加载可能需要一次窗口重载。执行命令 “开发人员: 重新加载窗口” 即可，不用重启整个应用。
第五步，检查是否开启了某些修改字体的插件。有些主题或插件（比如部分反色主题）会强制指定字体，覆盖用户配置。遇到这种情况，可以在设置里搜索"editor.fontFamily"看当前生效值是多少。
5.4 中文乱码、方块与特殊符号的显示问题
中文注释偶尔会变成方框，通常有三个原因：
第一个原因是字体列表里没有中文字体回退。如果editor.fontFamily写的是'Fira Code', monospace，且系统里没有能匹配中文的字体，VSCode 就会交给系统默认字体处理，在某些 Linux 服务器环境下可能没有中文字体，就出现了方框。解决方法是补齐中文字体回退，或者安装文泉驿、Noto Sans CJK 这类字体。
第二个原因是编码问题。文件本身不是 UTF-8（比如 GBK 编码的历史项目），VSCode 可能会用错误编码打开导致乱码。这种情况跟字体无关，需要在右下角编码选择器里重新选择正确的编码方式。
第三个原因是字体本身缺少某些字形。比如个别生僻中文汉字在某些字体里确实没有，就会显示为方框或者空白。这类问题只能换个更全的中文字体，或者接受它。
特殊符号（比如数学符号、箭头、盒式绘图符号）也是类似的情况，优先检查字体设置和 Nerd Font 是否安装。
5.5 实测效果：连字与字体平滑渲染的取舍
最后聊一下我个人经验里“看起来高级但未必好用”的配置。
很多人一装好 Fira Code 就无脑开启连字，但连字有一个隐性副作用：当代码里出现字符串、正则表达式、或者多行连续的比较操作符时，连字符号会改变字符的视觉占位宽度，有时反而误导你对字符数量的判断。最典型的例子是=>和>=在某些字体下渲染得几乎一样，如果你在写 TypeScript 的箭头函数和比较表达式，这两种情况混着出现时，需要一眼分辨，连字反而增添了视觉干扰。
还有字体平滑（anti-aliasing）的问题。VSCode 默认开启平滑，但在 Windows 高 DPI 屏幕上，某些字体的平滑效果会让笔画变“糊”。这时候可以试试在系统层面关闭某个字体的平滑渲染，或者在 VSCode 里调整window.titleBarStyle相关配置，但这些都是次优解。我更推荐在 Windows 上优先选专门为 Windows 优化过的字体（比如 Cascadia Code），而不是一味追求跨平台热门字体。
5.6 一些值得长期坚持的小习惯
到这里，VSCode 设置代码字体这件事已经说得很完整了。但有几个衍生的小习惯，我在实践中发现非常有用。
第一，定期检查自己的字体设置。尤其是系统升级、VSCode 大版本更新之后，字体渲染引擎可能发生变化，某些配置可能失效。把settings.json纳入你的 dotfiles 管理，换新电脑时能快速恢复开发环境。
第二，不要过度折腾。字体配置的根本目的是提升阅读体验和编码效率，而不是满足收集癖。我曾经花了一整个下午试了七八种字体组合，最后发现最顺手的还是 JetBrains Mono 加更纱黑体这个基础组合。字体这种东西，找到适合自己的之后就安静下来好好写代码，才是正事。
第三，如果你做远程开发，比如通过 SSH 连接远程服务器、使用 VSCode Server 的情况，远程端的字体并不影响本地的显示和渲染，因为 VSCode 的渲染发生在本地的浏览器/Electron 窗口里。这一点想清楚后，你就知道“服务器上没有装字体所以代码不好看”是一个误解，字体配置永远是本地客户端的事。
最后分享一个小技巧：当你拿不准某个字体在 VSCode 里的实际渲染效果时，可以打开命令面板，输入 “开发人员: 打开编辑器日志” 然后在输出面板里切到 “字体” 相关日志，它会列出 VSCode 实际匹配到的字体列表。这比靠肉眼猜要靠谱得多。配置字体看起来是一件小事，但它每天陪伴你的时间远超其他工具。花半小时选对一款字体、调好一个配置，长期回报是非常划算的。
