bdi唯一作用是为不可控混排文本（如阿拉伯语与英文数字混排）提供确定性双向隔离，避免UBA错位；它不嵌套、不加dir属性，且不可用于表单控件内部。
它不控制对齐、不设置方向、也不美化排版——bdi唯一作用是让浏览器把一段文本当作独立单元，运行 Unicode 双向算法（UBA），避免 RTL 和 LTR 内容互相“拉扯”导致显示错位。
什么时候必须用 bdi，而不是 dir="auto" 或 CSS
当内容来自用户输入、API 返回、数据库字段等不可控来源，且可能混排阿拉伯语、希伯来语与英文/数字时，dir="auto" 在旧 Safari 和部分 Android WebView 中会失效；而 CSS 的 unicode-bidi: isolate 必须配合 direction: ltr 或 direction: rtl 才生效，你得先知道方向——这恰恰是你无法预判的。
- 纯数字开头（如
"123@example.com"）会让dir="auto"误判为 LTR - 标点或空格开头（如
" (user-456)"）同样触发错误方向推断 -
bdi对首字符方向属性（Unicode Bidi Class）更鲁棒，连"١٢٣"（阿拉伯数字）也能正确识别为 RTL - SSR 框架（如 Next.js）中，
bdi不依赖 JS，服务端直出即生效
bdi 为什么不能嵌套、也不能加 dir 属性
bdi 的语义是“单层双向隔离段”，浏览器按规范只做一次 UBA 隔离。嵌套会导致隔离层级混乱，某些引擎（如旧版 WebKit）可能直接忽略内层 bdi；显式写 <bdi dir="rtl">أحمد</bdi> 会覆盖其自动检测逻辑，退化为普通 span，失去隔离意义。
- 规范明确：
bdi的默认行为就是dir="auto"，写出来纯属冗余 - 想强制方向？该用
dir="rtl"直接设在父容器上，而不是塞进bdi - 嵌套常见于模板拼接错误，比如后端渲染时重复包裹：
<bdi><bdi>أحمد</bdi></bdi>
bdi 和 bdo 别混，尤其别用 bdo 显示用户名
bdo 是强制逐字符翻转视觉顺序，它绕过 UBA，但破坏可访问性——屏幕阅读器仍按源码顺序读，而用户看到的是反的。用 <bdo dir="rtl">أحمد123</bdo> 会导致数字 “123” 被倒成 “321”，这不是你想要的用户名。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
-
bdi：自动识别 + 隔离 →أحمد右对齐，Ahmad左对齐，各自保持原始字符顺序 -
bdo：强制重排 →<bdo dir="rtl">Ahmad</bdo>显示为 “dahmA”，仅适用于调试或镜像设计 - 邮箱、URL 等中性字符密集内容，
bdo是唯一能锁定字面顺序的手段，但必须明确你就是要那个“倒过来”的效果
表单控件里不能用 bdi，但可以给 input 加 dir="auto"
bdi 是行内语义标签，不适用于替换表单元素的原生方向控制机制。在 input 或 textarea 里套 bdi 完全无效——光标定位、选区行为、IME 输入都由浏览器原生处理，bdi 插不进去。
- 正确做法：直接在
<input dir="auto">上设dir="auto"，现代浏览器均支持 - 若需兼容极旧环境（IE10以下），可用 JS 监听
input事件，根据首字符 Unicode 类型动态设dir -
bdi可用于包裹input旁边的标签文字（如<label>昵称：<bdi>أحمد</bdi></label>），但不要侵入控件内部
真正难处理的不是纯阿拉伯语段落，而是 أحمد (user-2024) 这种混排——括号、连字符、数字全都是 UBA 里的“中性字符”，极易被方向上下文带偏。bdi 的价值，就在这一层隔离的确定性上：它不猜、不妥协、不依赖运行时判断，只做一件事——把这段文本从 UBA 的全局上下文中切出来，单独跑一遍算法。
