必须在元素上显式设置dir="rtl"，否则整页RTL布局必然出错；它决定Unicode双向算法起点，影响光标、Tab顺序、Flex主轴及滚动条位置，CSS的direction无法替代。
必须在 元素上显式设置 dir="rtl"，否则整页 RTL 布局必然出错——表单光标乱跳、Tab 键顺序反常、Flex 容器起始边不翻转，这些都不是 CSS 能修好的。
整页 RTL 必须从 dir
很多人只给 或某个 <div> 加 <code>dir="rtl"，结果导航栏还是左对齐、输入框退格方向错乱、按钮顺序没翻转。这是因为 dir 是继承性全局属性，只有根元素 的值才能决定整个文档的 bidi 上下文起点。
浏览器据此运行 Unicode 双向算法（UBA），影响：
-
<input>和<textarea></textarea>的光标初始位置和退格行为 - Tab 键焦点流方向（RTL 下应从右往左 tab）
-
flex-direction: row的主轴起点自动变为右侧 - 滚动条在支持双向的系统中出现在左侧（如 macOS + RTL 系统偏好）
别写 ——它不合法，也不生效。HTML 规范明确要求方向基线由 定义。
dir="auto" 在哪些场景会误判方向
dir="auto" 不是“智能识别”，而是依赖首个强方向字符（strong directional character）做一次性判断，且不重算。常见失效场景：
- 开头是 ASCII 字母、数字或空格（如
"Hello world"、"123 أهلا"、" مرحبًا"）→ 强制 fallback 到ltr - 首字符是中文、日文、韩文等中性字符 → 同样 fallback 到
ltr，不会触发 RTL - JS 动态插入内容（如
el.innerHTML = apiResponse）后，方向不会重新推断 - Safari 对带变音符号的阿拉伯字母（如
إ、ؤ）识别不稳定
线上关键路径（如登录表单标签、导航菜单项、商品标题）严禁用 dir="auto"。仅在用户昵称、评论等低风险、不可控、纯内联文本中可谨慎尝试。
混合语言内容该用 <bdi></bdi>，不是 <bdo></bdo> 或手动加 dir
当一段内容来自 API（比如用户名 "أحمد Smith"），方向不确定且含双向混排时，正确做法是用 <bdi></bdi> 包裹：
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
<bdi>{{username}}</bdi>
<bdi></bdi> 是语义化隔离标签，会为该段文本创建独立的 bidi 环境，不影响父容器方向，也避免标点重排错误。而以下写法都有问题：
-
{{username}}：无隔离，可能把整个<div> 拖进错误方向 <li> <code><bdo dir="rtl">{{username}}</bdo>：强制覆盖，会把"123"显示成"321"，仅适合调试 -
<span dir="auto">{{username}}</span>：同上，首字符误判风险高，且不解决隔离问题 -
<input placeholder="مرحبا">：加style="direction: rtl"不会让 placeholder 右对齐；加dir="rtl"就可以 -
<select></select>下拉选项弹出方向：CSS 无效，必须靠dir - 光标在
<textarea></textarea>中的初始位置和选区行为：只响应dir，无视direction
<bdi></bdi> 是 HTML5 原生支持的标签，所有现代浏览器兼容良好，无需 polyfill。
为什么 direction CSS 属性不能替代 dir
direction 只控制块级元素内行盒（inline formatting context）的对齐和顺序，它不参与 Unicode 双向算法，也不改变元素本身的 bidi 上下文。
典型表现差异：
当两者同时存在时，dir 优先级永远高于 direction——这是 HTML 规范强制规定的。CSS 能做的只是视觉微调，底层文本流逻辑必须由 dir 控制。
