bdo标签仅强制逐字符视觉翻转，不设语言方向；如ABC显示为CBA，而非右对齐，且复制粘贴仍为ABC，屏幕阅读器读源序，dir仅支持"ltr"/"rtl"，禁用"auto"。
bdo 标签不是“让文字从右向左显示”的通用方案，它只做一件事：按 dir 属性值强制逐字符翻转视觉渲染顺序。写成 <bdo dir="rtl">ABC</bdo>，浏览器不会显示“ABC 右对齐”，而是把字符挨个倒过来画——结果是 CBA。
为什么 bdo dir="rtl" 渲染出的不是 RTL 语言效果，而是字符反转
它绕过了 Unicode 双向算法（UBA），不识别语言、不保留单词结构、不处理标点嵌套逻辑，只机械地按方向“从右往左”或“从左往右”排布每一个 Unicode 码位。所以：
-
<bdo dir="rtl">Hello123</bdo>→ 视觉上变成321olleH，不是“Hello123 右对齐” -
<bdo dir="ltr">مرحبا</bdo>→ 阿拉伯字母被强行左排为ابحرم，完全不可读 - 复制粘贴该内容，得到的仍是原始字符串
Hello123，和看到的不一致 - 屏幕阅读器照读源码，不会按视觉顺序朗读
bdo 的 dir 属性只能是 "ltr" 或 "rtl"，"auto" 无效
规范明确要求 dir 是必需属性，且仅接受这两个字面值。写 dir="auto" 会被浏览器忽略或 fallback 到 ltr，导致希伯来文、阿拉伯文直接乱码：
-
<bdo dir="auto">שלום</bdo>实际渲染为םולש（从左到右硬排），而非正确 RTL 顺序 - 大小写敏感：
DIR="RTL"在 XHTML 中可能解析失败；dir="RTL"在部分旧浏览器中也不被识别 - 想确认真实设置，不能依赖
bdoElement.dir，要用bdoElement.getAttribute("dir")
什么场景下才该用 bdo，而不是 dir 或 bdi
它只适用于需要**人工强控字符视觉顺序**的极少数情况，比如：
Convert Markdown To HTML And PDF - Markdown和HTML、PDF互转
下载
实现 Markdown↔ HTML 互转，支持导出 PDF，用于用户请求的文档格式转换。
- 调试双向文本渲染问题，快速验证某段字符串是否真被 RTL 算法误判 —— 用
<bdo dir="rtl">test123</bdo>看是否变成321tset - 在 RTL 页面中嵌入一段已知为 LTR 的代码缩写（如
API、URL），防止被周围上下文拖偏 —— 此时应优先用<bdi>API</bdi>，仅当bdi不够用时再考虑bdo - 实现特殊 UI 动效（如镜像翻转入场）或展示 bidi 控制符行为
但以下情况坚决不用：bdo 处理用户输入、昵称、评论、API 返回字段；整段阿拉伯语文档；单纯想右对齐中文/英文；需要语义正确的多语言混排。
嵌套 bdo 会引发不可预测的字符重排
每层 bdo 都会覆盖上一层的方向指令，不是“叠加”，而是“重写”。例如：
<bdo dir="rtl">a1<bdo dir="ltr">b2</bdo>c3</bdo>
Chrome 和 Firefox 渲染结果可能不一致：3c2b1a 或 c3b2a1，取决于底层 bidi 引擎如何解析嵌套边界。SSR 渲染与客户端 hydration 后也可能出现方向跳变。除非你在写双向算法测试用例，否则嵌套就是自找麻烦。
真正容易被忽略的是：它只动视觉层，不动 DOM 文本值、不改换行逻辑、不调整空格语义。一旦混排复杂 Unicode 字符（比如阿拉伯数字+拉丁字母+括号），光标位置、选区范围、剪贴板内容都会和所见严重脱节。
