Sublime Text中真正生效的行距控制方式仅有line_height和line_padding_top/line_padding_bottom;前者设绝对像素或相对倍数,后者精确控制上下留白像素,二者均只作用于编辑区,且必须在用户设置中配置。

line_height 和 line_padding_top/line_padding_bottom 是 Sublime Text 中唯二真正生效的行距控制方式,其他如 margin、letter_spacing 或 UI 主题 CSS 注入均无效或仅影响非编辑区。
用 line_height 调整绝对像素行高(最常用)
这是多数用户首选,参数直白、效果立竿见影,单位是像素(也可用浮点数表示相对于 font_size 的倍数)。
-
line_height设为 0 表示交还给字体自身度量,不是“无间距” - 设为整数(如
"line_height": 20)时,Sublime 按像素严格渲染;设为小数(如"line_height": 1.45)时,会乘以当前font_size后四舍五入取整——中英文混排建议优先用小数,避免中文被裁切 - 常见失效原因:写在了左侧 Default Settings 里、JSON 格式错误(多逗号/中文引号)、被插件(如 Origami)或主题(如 Theme - Soda)硬覆盖
- 实操建议:等宽字体下,
font_size14 →line_height19~21;16 → 22~24;避免奇数值(如 17、23),部分字体渲染下光标线会轻微偏移
用 line_padding_top 和 line_padding_bottom 精控上下留白(更底层)
这两个参数才是真正控制“每行文字上下空白”的像素级开关,加起来才是你看到的视觉行距增量。它不依赖字体度量,也不受中英文混排影响,但需注意对齐副作用。
- 二者必须同时设置才稳定;只设
line_padding_top而line_padding_bottom为 0 会导致折叠标记错位、光标垂直居中异常 - 值可不对称:比如
"line_padding_top": 4, "line_padding_bottom": 2让文字整体“下沉”,缓解长时间阅读的视觉压迫感 - 等宽字体(Fira Code、JetBrains Mono)纵向密度高,建议比默认多加 0.5~1px,例如从 3/3 改为 4/3
- Windows/macOS/Linux 渲染器不同(GDI/Core Text/FreeType),同一组值在不同系统上实际行距可能差 1~2px,别硬套跨平台数值
为什么改了没反应?重点检查这三处
绝大多数“调了没用”问题都出在配置加载优先级或作用域上,而不是参数本身。
- 确认修改的是 Preferences → Settings 右侧「User Settings」面板,左侧 Default 是只读的,改了也会被升级清空
- 检查是否有语法专属配置干扰:Preferences → Settings – Syntax Specific(比如 Python.sublime-settings)里也写了
line_height,它会覆盖全局设置 - 某些主题(尤其是老版本 ayu、Soda)会在自己的
.sublime-theme文件里强制重置line_height,临时切换成 Adaptive 主题测试是否生效
侧边栏、标签页、行号栏的“行距”要另配
line_height 和 line_padding_* 只作用于代码编辑区,对文件树、Tab 标签、行号栏(gutter)完全无效。这些区域由当前主题文件控制。
- 安装 PackageResourceViewer 插件,Ctrl+Shift+P → “PackageResourceViewer: Open Resource” → 选当前主题(如 Theme - Default)→ 打开
Default.sublime-theme - 搜索
"class": "sidebar_tree",添加或修改"row_padding": [8, 4](第二个值是垂直间距) - 同理,
"class": "tabset_control"控制标签页高度,"class": "gutter"控制行号栏内边距 - 改完保存,无需重启,但需切 Tab 或 Ctrl+R 刷新视图才能稳定显示
真正容易被忽略的是:Sublime 没有“统一行高”概念,编辑区、UI 区、语法高亮层各自有一套独立控制逻辑;同一个参数名(比如 line_height)在不同上下文里含义可能完全不同——比如 Sublime Text 4 的 ui_line_height 只管侧边栏字体,和编辑区毫无关系。











