只加 direction: rtl 不足以解决多语言混排，unicode-bidi 是补上双向算法（UBA）缺失一环的关键开关；因为 direction 仅控制视觉对齐，不触发 UBA 解析，而 unicode-bidi: isolate 才能严格隔离文本方向计算，确保混合文本正确排版。
只加 direction: rtl 不足以解决多语言混排，unicode-bidi 是补上双向算法（UBA）缺失一环的关键开关。
为什么 direction: rtl 单独失效？
移动端（尤其是 Safari iOS 和 Android WebView）对 Unicode 双向算法的推断很保守。ASCII 字符（如英文单词、数字、标点）默认被识别为强 LTR，即使父容器设了 direction: rtl，它们仍会“逃逸”出 RTL 上下文，导致阿拉伯语段落里出现 "files ٢٠٢٤" 这类错位——数字被甩到右边，违背阅读逻辑。
这不是 CSS 写错了，是浏览器没被明确告知：“这段内容要独立算方向”。unicode-bidi 就是干这个的。
unicode-bidi: isolate 是当前最稳妥的选择
它等效于 HTML 的 <bdi> 标签，会严格隔离该元素内文本的双向计算，不干扰外部，也不被外部干扰。适合所有动态、不可信来源的短文本：
立即学习“前端免费学习笔记（深入）”；
- 用户昵称（含中/英/阿/维吾尔混合）
- API 返回的标题或摘要
- 评论、消息气泡里的任意语言内容
示例：
/* 推荐写法 */
.user-name {
direction: rtl;
unicode-bidi: isolate;
}注意：iOS 15.4+、Chrome for Android 90+ 均支持；老版本可降级为 embed，但隔离性弱，易受邻近文本影响。
别漏掉两个生效前提
unicode-bidi 不是独立开关，它依赖两个基础条件：
- 父级必须声明
dir="rtl"或direction: rtl—— 它只是“配合项”，不是“启动项” - 字体必须支持对应语言的字形和 RTL 渲染逻辑。例如 iOS 上 San Francisco 对阿拉伯数字支持弱，fallback 后可能显示方块或顺序错乱；维吾尔文必须用
Noto Sans Uyghur这类专用字体
常见失效场景：样式写了，但数字还是跑右边 → 先查 dir 是否继承到了目标元素，再打开开发者工具 > Elements 面板 > Computed，看 font-family 实际加载的是哪个字体。
避开 bidi-override 的坑
它强制所有字符按 direction 指定方向排列，括号会翻转、数字镜像错位、连字断裂。仅适用于纯 RTL 固定文案（如单独一行阿拉伯语版权说明），绝对不要用在用户输入或混合文本上。
真正需要控制方向的混合场景，优先用 isolate + direction，必要时对嵌入的 LTR 片段显式加 dir="ltr"（如阿拉伯文中夹一个英文品牌名）。
逻辑属性（如 margin-inline-start）和 dir 属性才是布局翻转的主力，unicode-bidi 只管文本流内部怎么算——这点边界不清，很容易把整个 RTL 适配搞成 patch 大杂烩。
