unicode-bidi: isolate 必须配合 direction 使用才生效，单独设置无效；它仅隔离双向计算，direction 才指定方向，且不继承，需显式声明，移动端优先用 isolate 而非 embed，禁用 bidi-override。
unicode-bidi: isolate 必须配 direction 才生效
单独写 unicode-bidi: isolate 不会触发任何方向重排，浏览器直接忽略。它只是告诉 UBA「这段内容要独立算」，但没说往哪边算——direction: rtl 或 direction: ltr 才是方向判决依据。
常见错误：
- 在 span 上只设 unicode-bidi: isolate，结果中文/英文混排依然错位
- 父容器用了 direction: rtl，子元素却漏了 direction，导致 unicode-bidi: isolate 无方向锚点
- 正确写法：
.mixed-text { unicode-bidi: isolate; direction: rtl; } - 若内容实际是 LTR（如阿拉伯语里嵌一段英文 URL），则用
direction: ltr，不是硬套rtl - 不要依赖继承：
direction不继承 Bidi 环境，必须显式声明
移动端 Safari 和 Android WebView 对 embed 支持不稳定
unicode-bidi: embed 在 iOS 14 及更早版本、部分 Android WebView（尤其旧版 Chrome 内核）中行为不一致：有时隔离失败，导致中性标点（如 :、/、空格）仍被拉进外部 RTL 上下文，出现 ٢٠٢٤/files → files/٢٠٢٤ 这类翻转。
这不是 bug，是 UBA 实现差异——embed 依赖浏览器对嵌入层的解析精度，而移动端渲染引擎常做简化。
- 优先用
unicode-bidi: isolate，iOS 15.4+、Chrome 90+ 已稳定支持 - 若需兼容 iOS 13 或更低，改用 HTML
<bdi></bdi>标签，语义明确且无需 CSS 注入时机保障 - 避免在 SSR 场景下仅靠 CSS 控制：服务端未注入样式时，
embed失效风险更高
中英文混排时，bidi-override 是危险操作
unicode-bidi: bidi-override 强制按内存顺序排列字符，完全绕过 UBA。中英文混排下极易出错：
- Hello 123 变成 321 olleH
- file.txt 变成 txt.elif
- 括号、引号全部镜像错位，连光标定位都失常
它只适合极简纯文本调试，比如单行阿拉伯语测试；真实业务字段（用户昵称、文件名、API 返回值）绝不能用。
- 看到
bidi-override就该警觉：检查是否误配，或被自动化工具错误注入 - 替代方案：用
isolate+ 正确direction，或直接上dir="ltr"/dir="rtl"属性 - 特别注意日志、错误提示等动态文本：它们常含中英文混合结构，
bidi-override会让报错信息本身不可读
字体缺失会导致 unicode-bidi 形同虚设
即使 CSS 写得完全正确，若系统或页面未加载支持阿拉伯语/维吾尔文/希伯来文的字体，浏览器 fallback 到无 RTL 字形的字体（如 San Francisco 在 iOS 上对阿拉伯数字支持弱），就会显示方块、错位或强行 LTR 渲染。
典型现象：文字方向对了，但 ٢٠٢٤ 显示为 2024，或根本无法识别连字规则。
- 必须声明
font-family包含 Noto Sans Arabic、Noto Sans Uyghur 等开源字体 - 用
@font-face加载并设置font-display: swap，避免 FOIT 同时保证字形可用 - 在 DevTools 中检查 computed font-family，确认最终生效的是含 RTL 字形的字体
实际项目里最容易被跳过的，是字体链和 dir 属性的配合。CSS 的 unicode-bidi 只管“怎么算”，不管“用什么字”和“从哪开始算”——这两步漏掉任何一个，方向控制就只剩个空壳。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
