中文竖排应选 vertical-rl，因其符合传统从右向左阅读习惯、标点直立自然、兼容性好；vertical-lr 仅适用于特殊场景，且需配合 text-orientation: mixed 等调整字符朝向，否则易出现标点错位、数字倒置等问题。
vertical-lr 和 vertical-rl 到底该选哪个
取决于文字阅读方向和浏览器默认行为，不是“哪个更高级”，而是“哪个符合你的排版逻辑”。中文传统竖排从右向左（vertical-rl），日文也常用；而 vertical-lr 是从左向右竖排，适合部分少数民族文字或特殊设计需求，但现代网页中极少用。
常见错误是直接写 writing-mode: vertical-lr 后发现标点位置错乱、数字倒置——因为 css 的 text-orientation 和 unicode-bidi 会联动影响。比如中文句号「。」在 vertical-lr 下默认会横过来，而 vertical-rl 下保持直立更自然。
-
vertical-rl更贴近中文出版习惯，兼容性好（chrome 48+、firefox 41+、safari 12.1+） - 若强制用
vertical-lr，需额外加text-orientation: mixed控制字符朝向 - IE 完全不支持
writing-mode的垂直值，只认旧语法-ms-writing-mode: tb-rl（已废弃）
text-orientation 怎么配合 writing-mode 用才不翻车
text-orientation 决定单个字符的旋转方式，它和 writing-mode 是搭档关系，不是可选项。不设的话，浏览器按默认规则处理：CJK 字符直立，拉丁字母/数字自动顺时针旋转 90°，但标点（如括号、引号）可能方向混乱。
典型现象：竖排段落里英文单词歪着，中文引号「」变成横的「”」状，或者数字 123 看起来像在“躺平”。
立即学习“前端免费学习笔记（深入）”；
- 中文竖排推荐
text-orientation: upright：所有字符直立，包括英文字母和数字（适合标题、强调短语） - 常规正文用
text-orientation: mixed：CJK 字直立，拉丁字母/数字自动旋转，标点依上下文调整（最稳妥） - 避免用
text-orientation: sideways：整行当一个块旋转，失去竖排意义 - 注意 Safari 对
upright支持不稳定，某些版本下仍会微调小写字母角度
line-height 和 padding 在 vertical-rl 下为什么“变矮了”
因为 writing-mode: vertical-rl 把行内方向（inline-axis）变成了垂直方向，原本控制“行高”的 line-height 实际控制的是“列宽”，而 padding-top/padding-bottom 变成了左右内边距——视觉上就像元素突然被压扁、留白错位。
你调了半天 line-height: 2 没反应？不是失效，是它现在决定的是字与字之间的横向间距（即列间距），不是你眼睛看到的“行距”。
- 想控制字与字之间的垂直距离（即传统“行距”），该调
line-height，但它数值含义已变为“相对于 font-size 的垂直空间倍数” -
padding-top在vertical-rl下实际作用于右边缘，padding-left才是顶部留白 - 用
margin-block-start/margin-block-end替代margin-top/margin-bottom，能真正对应逻辑方向 - flex/Grid 布局中，
align-items和justify-content的主轴也会随writing-mode切换，别硬套水平布局经验
font-feature-settings 和竖排标点对齐怎么搞
纯靠 writing-mode 不足以实现出版级竖排，尤其标点悬挂、避头尾、全角标点居中等细节，得靠 OpenType 特性。比如中文句号「。」在竖排时应略向下偏移以视觉居中，但默认不会动。
常见表现：竖排文本里冒号「：」、顿号「、」明显偏上，引号「『』」贴边难看，破折号「——」断成两截。
- 启用竖排优化特性：
font-feature-settings: "vert", "vkrn"（vert启用竖排字形，vkrn启用竖排字距） - 不是所有字体都支持
vert表，思源黑体、Noto Sans CJK、霞鹜文楷等开源字体有较完整覆盖 - WebFont 加载时加
font-display: optional避免回退到无 vert 特性的系统字体 - 注意
font-feature-settings优先级高于font-variant-east-asian，后者仅控制比例（proportional-width/tabular-width）
事情说清了就结束。真正麻烦的从来不是加一行 writing-mode，而是后续所有盒模型、排版流、字体特性的连锁响应——它们不会自动“跟着转过来”。