必须用 时是需强制绕过Unicode双向算法（UBA）逐字符按指定方向渲染，如RTL环境中锁定URL显示顺序；则用于自动隔离并推断未知内容方向，二者语义与用途截然不同。
什么时候必须用
而不能只靠 CSS
当需要强制覆盖浏览器默认的双向文本（Bidi）自动重排逻辑时，
是唯一可靠手段。比如阿拉伯语或希伯来语中嵌入英文 URL、数字序列或代码片段，CSS 的
和
无法阻止 UBA（Unicode Bidi Algorithm）对这些中性字符的“重新归类”和位置调整。
直接绕过 UBA，按指定方向逐字符渲染。
常见错误现象：
在 RTL 环境下被显示为
—— 这不是 CSS 没生效，而是 UBA 把数字和 ASCII 符号当作“弱类型字符”重新排序了。
实操建议：
强制整个字符串从右向左逐字符输出，结果就是
（注意：这是你明确要的效果，不是 bug）
只对真正需要“字面顺序锁定”的片段使用
，避免包裹整段混合文本，否则会破坏正常阅读流
不要用
替代语义化标签（如
+ CSS），它没有语义，仅用于方向覆盖
解决的是什么问题：动态内容的自动方向隔离
不是设置方向，而是告诉浏览器：“这段内容的方向应根据它自己的 Unicode 字符自动推断，且不与周围文本耦合”。典型场景是用户评论、搜索结果、数据库字段等不可预知语言的内容。
例如一个用户昵称字段存了
（阿拉伯语）和
（英语），混排在 LTR 列表中：
– 不加
：阿拉伯用户名会被拉到行尾，与前面的序号、图标错位
– 加
：每个昵称独立判断方向，对齐保持稳定
实操建议：
在表格、列表、卡片等结构化 UI 中，对所有可能含 RTL 内容的文本单元（如用户名、标题、摘要）套一层
不接受
属性；它只做“隔离 + 自动检测”，加了
会退化为普通
兼容性良好（IE10+，所有现代浏览器），但 SSR 渲染时需确保服务端不误删该标签（某些模板引擎会过滤未知标签）
为什么
在
里是多余的
是冗余写法。
的规范行为就是自动检测首字符方向，等价于隐式
。显式写出反而可能引发混淆，尤其在团队协作中让人误以为它支持其他
值。
对比真实效果：
容易踩的坑：
用
试图“加强”RTL 效果 —— 实际上失去自动检测能力，且丧失语义
在已用 CSS 设置
的容器内嵌套
—— 不冲突，但没必要；
的价值恰恰在于“无需预知方向”
依赖
修复输入框内光标跳转异常 —— 它不控制编辑行为，需配合
在
或
directionunicode-bidi123@example.commoc.elpmaxe@321123@example.commoc.elpmaxe@321أحمدAhmaddirdirdir="auto"dir="auto"dirأحمد → 正确：识别为 RTL，独立隔离
أحمد → 行为相同，但无必要
أحمد → 失效：dir 属性，退化为普通容器direction: rtldir="auto"