writing-mode: vertical-rl 是唯一能真正实现语义正确、可复制、可访问的中文竖排方案，因其原生适配“从上到下、从右到左”传统阅读流，确保括号翻转、数字对齐、标点换行符合出版规范，且需配合 text-orientation: mixed 实现汉字直立、字母数字自动旋转。
writing-mode: vertical-rl 是唯一能真正实现语义正确、可复制、可访问的中文竖排方案，其他方式（如 transform 旋转）本质是“假竖排”，会破坏文本选择、屏幕阅读器支持和打印行为。
为什么 vertical-rl 是唯一可靠选项
vertical-rl 表示“文字从上到下、行从右到左”，它原生适配中日韩字体的竖排逻辑：括号自动翻转（「(」在上、「)」在下）、数字按竖排对齐、标点换行规则符合出版习惯。vertical-lr 虽然也竖排，但行从左往右推进，会导致中文段落右侧异常留白，且部分中文字体对标点位置未做 vertical-lr 优化；sideways-rl 是整行顺时针转 90°，所有字符横躺，不可读，仅适合表头装饰。
- 别用
transform: rotate(90deg)模拟竖排——选中、复制、搜索全部失效 -
vertical-rl在 Chrome/Firefox/Safari/Edge 100% 支持，无需前缀（-webkit-writing-mode和-ms-writing-mode只需兼容 IE11，现代项目可忽略） - IE11 仅支持
ms-writing-mode: tb-rl，但不支持text-orientation，降级时需接受英文数字躺倒
text-orientation: mixed 必须配合使用
只设 writing-mode: vertical-rl 不够，text-orientation 控制单个字符朝向。默认值 mixed 才能让汉字 upright、ASCII 字母/数字自动顺时针旋转 90°，标点按上下文智能翻转。
- 不用
text-orientation: upright——它会让 “2024” 显示成四行细高字，阅读顺序错乱 - 纯数字列（如页码、年份）若必须直立，仅限 2–4 个连续数字，且需额外加
font-variant-east-asian: proportional-width - Safari 13+ 已稳定支持
mixed，但旧版 Safari（sideways，导致汉字歪斜
容器样式不匹配是失效主因
90% 的 “写了没反应” 问题不是属性写错，而是布局模式冲突：writing-mode 只对块级流或 flex/grid 容器生效，内联元素（<span>、<a>）默认不响应。
立即学习“前端免费学习笔记（深入）”；
- 确保目标元素设
display: block或display: inline-block（<div>默认 OK，<span>必须显式改） - 禁用
float、position: absolute——它们触发旧式定位，绕过 writing-mode 文本流 - 必须设宽度（
width: 2em）或高度（竖排下width控制每列占多少水平空间） - 换行用
white-space: normal（推荐）或white-space: pre-line，绝对避免white-space: nowrap
line-height 和 padding 在竖排下容易误判
竖排后，line-height 的“行”变成垂直方向间距，padding-top/padding-bottom 实际作用于左右两侧，padding-left/padding-right 反而控制上下留白——极易混淆。
-
line-height建议用无单位值（如1.4），避免px或em在不同字号下失衡 - 优先用逻辑属性：
padding-block（对应书写流前后）和padding-inline（对应左右），比物理方向更可靠 - 若容器设了
height，竖排内容可能被截断；建议用min-height或让高度由内容撑开 - 字体必须支持竖排特性（如
Noto Sans CJK、Source Han Serif），部分西文字体在竖排下标点位置异常
真正难的不是写出那两行 CSS，而是理解 writing-mode 不是“让字转过来”，而是切换整个文本流方向——它影响 line-height 计算、padding 映射、flex 主轴走向，甚至影响 text-align 的基准轴。任何试图绕过这个模型的“技巧”，最终都会在可访问性或跨浏览器场景里暴露代价。
