根本原因是字体栈混入非等宽中文字体或未指定中文字体，导致中文占1.5个英文宽度而破坏对齐；需用单引号包裹、中文字体前置的等宽字体链（如"'Maple Mono', 'Cascadia Code', monospace"），并显式设置editor.fontSize、editor.lineHeight、editor.fontLigatures，且必须重启终端生效。
为什么中文在 VSCode 里总“不站队”？
根本原因不是字体没装，而是你用的字体栈里混进了非等宽中文字体，或者压根没指定中文字体——VSCode 默认拿 Consolas 或 Monaco 渲染中文，这两个字体根本不含中文字符，系统 fallback 到 SimSun、Microsoft YaHei 等非等宽字体后，一个中文占 1.5 个英文宽度，表格、注释、JSON key 对齐立刻崩坏。
别信“改了 editor.fontFamily 就万事大吉”。Windows/macOS/Linux 都要手动确认字体已安装，且名称必须和系统字体管理器里显示的「全名」完全一致（比如 macOS 要写 PingFang SC，不是“苹方”；Windows 是 Microsoft YaHei，不是“微软雅黑”）。
怎么配出真正等宽的中英文混合字体栈？
关键不是单个字体多好看，而是整条字体链能兜住所有字符，且中英文宽度严格对齐。推荐两种可靠组合：
-
"editor.fontFamily": "'Maple Mono', 'Cascadia Code', 'Fira Code', 'JetBrains Mono', monospace"—— Maple Mono 是目前唯一公开实现稳定 2:1 中英文宽度比的开源字体，表格、注释、log 输出对齐无压力 -
"editor.fontFamily": "'Sarasa Gothic SC', 'Noto Sans CJK SC', 'Cascadia Code', monospace"—— 更纱黑体（Sarasa Gothic）是更成熟的选择，支持 Nerd Font 图标，中文渲染清晰，但需注意其部分字重在高 DPI 下可能轻微发虚
务必把中文字体放前面，且每个字体名用单引号包裹；末尾保留 monospace 保底，否则某字体缺失时整个链会失效。
只改字体还不够，这几个参数必须同步调
光有好字体，行高、字号、连字开关不匹配，照样错位。尤其中英文混排时，西文字体的 metrics 和中文字体差异大，不干预就会塌行、光标悬空、退格跳位。
-
editor.fontSize建议设为14或15（比纯英文环境略大），避免中文过小导致视觉拥挤 -
editor.lineHeight必须显式设为像素值，如24或26；设1.2这类相对值在中文字体下容易触发基线浮动 -
editor.fontLigatures对中文无效，且可能干扰标点定位，建议保持false（除非你只写纯英文代码）
改完后不要只刷新编辑器，必须关闭所有终端面板再按 Ctrl + Shift + ` 重开——旧终端缓存不会自动更新字体度量信息。
远程开发或 WSL 下中文错位更难搞？先盯住 TERM
你在本地 VSCode 里调好了字体，一连 WSL 或 Docker，中文又开始偏移、重叠、换行错乱——大概率是远端 TERM 环境变量没设对。WSL 默认常设成 screen 或 linux，这类 TERM 类型不支持现代光标定位协议，ncurses 直接放弃对齐计算。
进远端终端执行：echo $TERM
如果不是 xterm-256color，就加到远端 shell 配置里（如 ~/.bashrc）：export TERM=xterm-256color
Windows 用户额外注意：VSCode 终端右键 → 属性 → 字体，必须手动选一次 Cascadia Code 或 Consolas，仅靠 settings.json 不生效。
真正卡住人的从来不是“要不要换字体”，而是换完之后没验证系统是否真装上了、没关掉旧终端、没调行高、也没管远端 TERM。四个环节漏一个，中文就继续歪着站。
