Sublime Text无法真正实现字体连字效果，因其渲染引擎从未集成OpenType特性解析能力，即使配置"font_options": ["liga"]也仅忽略该选项，不触发任何字形替换逻辑。
Sublime Text 无法真正实现字体连体（ligature）效果，所谓“配置成功”基本是视觉误判或版本混淆导致的错觉。
为什么 font_options: ["liga"] 在 Sublime 中无效
Sublime Text 的文本渲染引擎从未集成 OpenType 特性解析能力，包括 liga（标准连字）、dlig（自由连字）等。即使你把 "font_options": ["liga", "subpixel_antialias"] 写进设置，Sublime 也只会忽略 "liga"，仅应用后一个选项。官方文档和源码中均无 ligature 相关实现痕迹，Build 4126+ 所谓“有限支持”实为社区误传——该版本仅增强了抗锯齿控制，并未触碰字形替换逻辑。
- 错误现象：输入
!=或=>后看到符号合并，大概率是系统级字体渲染（如 macOS Core Text）在界面层做了缓存式合成，不是 Sublime 主动渲染的连字 - 验证方法：切换到非连字字体（如
Monaco），再切回Fira Code，若“连字”消失，说明之前只是字体名匹配触发了系统 fallback 渲染，而非 Sublime 解析了 OpenType 表 - 兼容性影响：Linux 下几乎必然失败；Windows 上依赖 DirectWrite 版本，旧版系统直接无视
liga
font_face 名称必须精确匹配系统注册名
填 "Fira Code" 却不生效？问题往往出在字体名本身。系统安装的字体文件名 ≠ 注册名，Fira Code 安装后在不同平台注册名差异极大：
- macOS：通常为
FiraCode-Regular、FiraCode-Retina，用 Font Book 查看“全名”字段 - Windows：注册表中可能显示为
Fira Code Retina或带版本号的变体，FiraCode-Bold这类文件名不能直接当font_face值 - Linux：需运行
fc-list | grep -i fira确认实际返回的完整字体名，常见含空格或连字符，如Fira Code:style=Regular - 错误示例：
"font_face": "Fira Code.ttf"或"font_face": "FiraCode"—— 都会静默失败
连字插件或主题不会改变底层限制
有人尝试用 BracketHighlighter 或自定义 color scheme 强制重绘符号，这反而会引发新问题：
- 光标定位偏移：连字被当成单个 glyph 渲染，但 Sublime 的光标逻辑仍按字符宽度计算，导致点击
=>时实际停在中间 - 搜索与选中异常：正则匹配
==>可能漏掉视觉上连在一起的字符，因为底层存储仍是两个 Unicode 码位 - 行高裁切风险：若同时设了
line_padding_top过小，部分连字（如===>）顶部会被截断，看起来像缺笔画 - 性能无变化：所有“连字”相关配置都不影响 Sublime 的解析或索引速度，它压根没走那条路径
真正起作用的只有 font_face 和 font_size；其他字段如 font_options 里的抗锯齿项虽有效，但和连字无关。如果你需要可靠连字，VS Code 或 JetBrains IDE 是当前唯一可选方案——它们从底层就集成了 HarfBuzz 或 Core Text 的 OpenType 支持。Sublime 的轻量设计决定了它不会为此重构渲染栈。
