unicode-bidi 在移动端混排中不能只靠 direction: rtl，因 Safari iOS 和 Android WebView 对双向文本推断保守，ASCII 字符默认强 LTR，需显式隔离；推荐 isolate（等效 <bdi>），embed 用于轻量固定文案，bidi-override 仅限调试；必须配合父容器 direction: rtl 和 RTL 字体支持，并注意物理属性、组件行为及 dir="auto" 兼容性问题。
unicode-bidi 为什么在移动端混排中不能只靠 direction: rtl
移动端浏览器（尤其是 Safari iOS 和 Android WebView）对双向文本的自动推断更保守，direction: rtl 单独作用于容器时，无法强制内部嵌入的拉丁数字、英文缩写或 ASCII 标点按 RTL 上下文重排。典型现象是阿拉伯语段落里出现 "٢٠٢٤ files"，但渲染成 "files ٢٠٢٤" —— 数字被“甩”到右边，违背阅读逻辑。这是因为 Unicode 双向算法（UBA）默认把 ASCII 字符视为强 LTR，需要显式隔离上下文才能覆盖。
embed vs isolate vs bidi-override：三个值的实际选择
这三个值不是性能差异问题，而是语义控制粒度的区别：
-
unicode-bidi: embed创建新的双向嵌入层，适合包裹一段已知方向的子内容（如阿拉伯语标题内嵌一个英文品牌名），但不隔离边界外的影响 -
unicode-bidi: isolate是现代推荐用法，它等效于 HTML 的<bdi>，会严格隔离该元素内的双向计算，前导空格、标点、混合字符全被正确跳过；iOS 15.4+、Android Chrome 90+ 均支持 -
unicode-bidi: bidi-override强制所有字符按direction指定方向排列，容易导致括号翻转、数字镜像错位，仅用于调试或极简纯 RTL 文本（如单独一行阿拉伯语）
实际建议：对用户昵称、动态字段、API 返回的短文本，优先用 unicode-bidi: isolate + direction: rtl；对固定文案模块（如页脚版权），用 embed 更轻量。
移动端必须配合的两个关键点
只设 unicode-bidi 不生效，常见失效原因都卡在这两点：
立即学习“前端免费学习笔记（深入）”；
- 父容器未声明
dir="rtl"或direction: rtl——unicode-bidi是依赖项，不是独立开关 - 字体缺失阿拉伯语/希伯来语字形支持，导致浏览器 fallback 到无 RTL 特性的系统字体（如 San Francisco 在 iOS 上对阿拉伯数字支持弱），此时即使方向正确，字符也可能显示为方块或错位
- 未处理物理属性陷阱：比如
margin-left在 RTL 下仍往左推，应改用margin-inline-start；text-align: right不能替代direction，它只影响对齐，不改变文本流顺序
真实项目中容易漏掉的 RTL 组件细节
按钮、输入框、下拉菜单这些组件在 RTL 下行为会“静默翻转”，光靠 unicode-bidi 无法修复：
- 复选框
<input type="checkbox">的标签默认在左侧，RTL 下需用[dir="rtl"] label { order: -1; }或 flex 调整顺序 - 输入框光标起始位置在右侧，但 placeholder 文本若含混合内容，仍需对
::placeholder单独加unicode-bidi: isolate - 图标按钮（如带
<svg>的“返回”按钮）必须检查 viewBox 是否镜像，否则箭头朝向错误；不要用transform: scaleX(-1)，它会让整个 SVG 坐标系反转，键盘焦点顺序也乱 - 表格列序反转后，排序图标位置、分页控件左右按钮功能需同步交换，这部分逻辑通常不在 CSS 范围内，但常被误认为是
unicode-bidi能解决的问题
最常被忽略的是：当使用 dir="auto" 动态判断方向时，iOS Safari 对空格开头的字符串判断失败率高，此时 <bdi> 是唯一可靠方案，unicode-bidi: isolate 无法完全模拟其自动探测能力。
