vertical-rl下line-height控制“列宽”而非行高，Chrome按块方向计算字符列间隙，Firefox严格映射为行内方向视觉高度；IE9需-ms-writing-mode:tb-rl并手动重置间距。
writing-mode 在垂直排版时，line-height、margin、padding 的计算逻辑会随文本流方向翻转，但各浏览器对“垂直间距”的解释不一致——这不是 bug，而是规范实现差异。核心问题不在属性本身，而在你是否意识到：竖排时 line-height 控制的是“行间垂直距离”，而这个“垂直”是相对于当前书写方向的坐标系，不是屏幕物理方向。
vertical-rl 下 line-height 为何在 Chrome 和 Firefox 中表现不同？
Chrome（Blink）把 line-height 当作沿块级方向（即从右到左）的间距基准，实际影响的是字符列之间的空隙；Firefox（Gecko）则更严格遵循规范，将其映射为“行内方向上的行高”，也就是文字上下堆叠的视觉高度。两者都合法，但结果肉眼可见差异。
- 用无单位值（如
line-height: 1.6）比像素值（line-height: 24px）更稳定，因为它是基于当前font-size的相对计算，避免了绝对尺寸在不同引擎下的映射偏差 - 若需精确控制，可配合
text-orientation: upright+font-feature-settings: "vert"，让字体自身参与行距微调（前提是字体支持vert特性） - 不要依赖
em或rem做垂直间距主力——它们仍锚定在水平基线上，竖排时语义模糊
IE9 及以下如何处理 vertical-rl 的间距失控？
IE9 不识别 vertical-rl，只认 -ms-writing-mode: tb-rl；IE8 及更早版本连这个都不支持，只能靠 filter: progid:DXImageTransform.Microsoft.BasicImage(rotation=1) 做图形旋转。此时所有间距属性都失效：
-
line-height完全失灵，必须手动设大值（如font-size: 16px时尝试line-height: 40px），再靠padding-top/padding-bottom补偿 -
margin和padding的方向不变——margin-top还是向上推，不是向右推；所以竖排视觉居中得用position: absolute+ 手动top/left微调 - 必须触发 hasLayout：加
zoom: 1或display: inline-block，否则filter不生效，间距更不可控
多列竖排（column-count）中垂直间距为何忽大忽小？
当 writing-mode: vertical-rl 配合 column-count 使用时，column-gap 是沿块级方向（即列与列之间从右到左的距离），但各浏览器对“列内行高继承”处理不同。尤其在内容不均等时，Firefox 可能压缩末列行距，Chrome 则保持均匀。
立即学习“前端免费学习笔记（深入）”；
- 显式设置
column-fill: auto，避免默认的balance算法干扰行高一致性 - 禁用
break-inside: avoid——它在竖排中容易导致某列突然多出一整行空白 - 如果容器高度固定，优先用
height而非max-height，后者在竖排下触发截断逻辑不稳定
最易被忽略的一点：竖排时 overflow-x 和 overflow-y 的含义会互换——overflow-y: hidden 实际剪裁的是水平方向溢出（即左右），不是上下。写错就会白忙活半天。
