<bdo> 不等于“右对齐”或“设为RTL”，它仅按 dir 属性逐字符翻转视觉渲染顺序，不改变语义、对齐、换行或空格逻辑；必须显式指定 dir="ltr" 或 dir="rtl" 才生效，不继承、不回退、不支持 auto；嵌套会导致不可预测的翻转叠加；复制粘贴、屏幕阅读器、DOM 文本内容均保持源码顺序。
为什么不等于“右对齐”或“设为RTL”
不是排版工具，它不改变文本的语义方向，也不影响对齐、换行或空格逻辑。它只做一件事：按 dir 属性指定的方向，**逐字符翻转视觉渲染顺序**。比如 <bdo dir="rtl">Hello</bdo> 渲染出来是 olleH，不是“Hello 右对齐”，也不是“用希伯来语方式排版”。常见错误是把它当 text-align: right 或 direction: rtl 的快捷写法——结果发现标点错位、光标跳变、复制粘贴内容和看到的完全不一致。
必须显式写dir="ltr"或dir="rtl"，否则无效
不继承父元素的 dir，也不 fallback 到文档默认方向，更不支持 dir="auto"。浏览器遇到没写 dir 的 会直接忽略其覆盖行为。以下写法全部无效：
– <bdo>نص عربي</bdo>
– <bdo dir="">نص عربي</bdo>
– <bdo dir="auto">نص عربي</bdo>
正确写法只有两种：<bdo dir="rtl">نص عربي</bdo>（阿拉伯文强制 RTL 渲染）或 <bdo dir="ltr">مرحبا</bdo>（西班牙文强制 LTR 渲染，视觉上变成 “ابحرم”）。
嵌套<bdo>时方向逐层覆盖，但不可预测
外层 <bdo dir="rtl"> 包着内层 <bdo dir="ltr">，浏览器会先对外层内容整体翻转，再对内层内容再次翻转。这种“翻转套翻转”极易导致字符顺序混乱，尤其混排 Unicode 字符（如阿拉伯字母+拉丁数字+标点）时：
立即学习“前端免费学习笔记（深入）”；
– <bdo dir="rtl">a1<bdo dir="ltr">b2</bdo>c3</bdo>
Chrome 和 Firefox 可能渲染为 3c2b1a 或 c3b2a1，取决于底层 Bidi 算法实现细节
– 嵌套超过两层基本无法人工推演结果
– SSR 渲染与客户端 hydration 后可能方向不一致（因解析时机差异）
除非你在写双向算法测试用例，否则应避免嵌套。
复制粘贴内容永远是源码顺序，不是视觉顺序
这是最常被忽略的可访问性与功能断裂点： 只改显示，不改 DOM 文本节点值。用户 Ctrl+C 复制一段 <bdo dir="rtl">Hello</bdo>，粘贴出来仍是 Hello，而非 olleH。如果你的前端逻辑依赖剪贴板内容做校验（比如密码确认、验证码比对），就会失败。
其他连带问题包括：
– 屏幕阅读器严格按源码顺序朗读，无视 的视觉翻转，造成语义与听觉完全脱节
– 搜索引擎索引、DOM 查询（如 document.querySelector('bdo').textContent）拿到的都是原始字符串
– 正则匹配、表单提交、服务端接收的数据，全都不含翻转效果
真正需要镜像文字效果时，务必确认这是纯展示需求，且不涉及任何后续文本处理或交互逻辑。
