writing-mode 改变块流向而非文本方向；需配合 direction、text-orientation、字体 vert 特性等才能实现正确竖排。
书写模式 writing-mode 改变的是块流向，不是文本方向
很多人一上来就用 writing-mode: vertical-rl 想让中文竖排，结果发现文字还是从左往右“躺平”——因为 writing-mode 控制的是块级容器的布局流向（即行内内容如何堆叠），不改变单个字符的朝向或 direction。它真正影响的是：块的起始位置、行盒排列方向、以及 width/height 的语义映射。
实操建议：
-
writing-mode: vertical-rl会让块内行从上到下排列，每行内文字默认按direction: ltr从左往右写（对汉字就是字面朝右）；若要传统古籍式“字头朝右、自上而下、自右而左”排版，还得配direction: rtl - 日文混排时，
writing-mode: vertical-rl+text-orientation: mixed才能让阿拉伯数字和拉丁字母自动旋转90°，否则它们会“横躺”挤在竖行里 - 不要依赖
writing-mode去翻转英文段落——它不会把 “Hello” 变成 “olleH”，那得靠unicode-bidi或 js 处理
text-orientation 决定行内字符怎么“站”
这是竖排场景中最容易被跳过的属性。没有它，中日韩文字能竖着排，但西文、数字、标点大概率歪着或撑开行高。
常见错误现象：竖排菜单里 “2024年” 四个字高度不一致，年份数字特别矮还偏上；或者引号、括号错位到行外。
立即学习“前端免费学习笔记（深入）”；
实操建议：
-
text-orientation: mixed是最常用值：CJK 字符保持直立，拉丁字母/数字旋转90°，标点按 Unicode 类别自动归位（如全角逗号 ✓，半角逗号 ✗） -
text-orientation: upright强制所有字符直立——适合需要统一视觉节奏的现代设计，但英文可读性骤降 -
text-orientation: sideways所有字符统一侧躺90°，基本只用于特殊标题或装饰性文本，日常慎用 - 注意兼容性：
text-orientation在 safari 16.4+ 才完全支持mixed，旧版需降级为upright或加 JS 补丁
竖排 + text-align 和 justify-content 的行为反直觉
当 writing-mode: vertical-rl 生效后，text-align: right 不再是“贴右”，而是“贴‘块’的逻辑顶部”——因为此时行内方向已变成垂直，right 对应的是“上”。
使用场景：做古籍翻页效果时，想让每行文字底部对齐（模拟毛笔字落款），不能设 text-align: bottom（无效），得换思路。
实操建议：
-
text-align的left/right在竖排中对应top/bottom；center仍居中，但参照的是容器的水平中线（即视觉上的“居中列”） - 若需控制某段文字在竖排容器中“靠下对齐”，用
align-self: flex-end配合display: flex更可靠，而不是赌text-align - 两端对齐（
text-align: justify）在竖排中作用于“行高方向”，可能拉伸字间距而非词间距，慎用于长段落
字体特性与 OpenType vert 特性支持才是关键隐性依赖
即使 css 写对了，如果字体本身没嵌入竖排专用字形（比如“。”在竖排中该用全角居中点，而非横排的右下角点），最终渲染仍是错的。这不是浏览器 bug，是字体缺失。
容易踩的坑：本地开发看着正常，上线后用户看到一堆偏移、重叠或方块——大概率是用了系统默认英文字体（如 San Francisco、Segoe ui）去渲染中文竖排。
实操建议：
- 指定字体栈时，优先包含明确支持
vert特性的中文字体，例如：font-family: "Noto Serif CJK SC", "Source Han Serif SC", "KaiTi", serif - 用
@font-face加载 WebFont 时，确认其font-feature-settings: "vert"可启用（部分字体需手动开启） - 测试阶段务必在 windows（默认微软雅黑不支持 vert）、macos（SF Pro 无 CJK vert）、ios（旧版限制多）三端验证真实渲染，别只信 chrome DevTools 模拟
真正卡住人的从来不是 CSS 属性写法，而是字体是否提供对应字形、浏览器是否启用 OpenType 特性、以及 writing-mode 和 direction 的组合是否触发了预期的布局上下文切换。