产品一出海，多语言排版的问题就全冒出来了。中文团队做的界面，一上英文、日文、阿拉伯语，样式碎得亲妈都不认识。这篇把多语言排版的高频坑按语言族梳理一遍。
CJK（中日韩）：折行与标点
中文最大的坑是折行规则：word-break: break-all 会把英文单词撕碎，keep-all 又让长中文串撑破容器。正确姿势是 overflow-wrap: anywhere 配合 line-break 微调。日文还有「禁则处理」（标点不能出现在行首/行尾），浏览器默认处理大部分场景，但自定义渲染（canvas、PDF 导出）就得自己接规则库。
另一个隐形坑：中日文混排时的字体顺序。font-family 里 CJK 字体放错位置，日文汉字会渲染成中文字形（「直」「骨」这些字中日字形差异明显），母语用户一眼就看出违和。
拉丁语系：长度爆炸
德语词长是出了名的（Donaudampfschifffahrtsgesellschaft 这种真会出现在 UI 里），英语按钮文字译成德语平均长 35%。防御三板斧：容器用 min-width + flex-wrap 而不是写死宽度；按钮留 40% 长度冗余；超长降级方案（截断加省略号不如换行，但 tooltip 必须给全）。
RTL（阿拉伯语/希伯来）：不只是镜像文本
RTL 的常见误解是「把 text-align 改一下」。真做起来是整个布局镜像：逻辑属性（margin-inline-start 替代 margin-left）、图标方向（返回箭头要翻转）、图表坐标轴、甚至动画方向。用 dir="rtl" 加 CSS 逻辑属性是唯一可维护的路，物理属性硬写的项目改 RTL 就是重写。
数字和代码段要保持 LTR 嵌入（unicode-bidi: isolate），不然电话号码、代码片段在 RTL 段落里会乱序。
翻译内容的长度控制
界面文案翻译后的长度波动，最好的防御是在源头上控制：源语言文案短一个词，所有译文都省一口气。翻译完做一轮「伪本地化测试」（把文案替换成加长 40% 的假译文跑一遍 UI），能在上线前暴露 90% 的布局问题。
结语
多语言排版的工程本质是「接受长度和方向的不确定性，把确定性留给布局系统」。逻辑属性、弹性容器、伪本地化测试——这三件套落了，多语言样式问题能减掉大半。
