dirname属性仅在表单提交时配合name属性生成xxx.dir字段，值为ltr或rtl，由首个强方向Unicode字符决定，不控制显示，Firefox不支持，服务端需用方括号访问。
dirname 属性提交的是 direction，不是文字内容本身
dirname 不会改变 input 的显示或行为，它只让浏览器在表单提交时，额外带上一个名为 dir（或你指定的 name）的隐藏字段，值为 ltr 或 rtl，取决于当前输入框的 Unicode 双向算法推导出的方向，或显式设置的 dir 属性。
常见误解是以为它“提交文字方向”，其实它提交的是浏览器对当前输入内容「方向性上下文」的判断结果，且仅在表单 submit 时生效。
- 必须配合
name属性使用，否则该字段不会出现在提交数据中 - 如果 input 已有
dir="rtl"，则提交dir=rtl；若无显式 dir，浏览器根据首字符 Unicode 类别（如阿拉伯字母、希伯来字母）自动判定 - 用户切换输入法（比如从中文切到阿拉伯语键盘）通常不会实时触发 dir 变更，方向由初始渲染或手动设置的
dir决定，不是动态跟踪输入内容
dirname 的 name 值决定提交字段名，不是固定叫 “dirname”
很多人写 <input dirname="mydir">，以为提交字段名就是 dirname，其实不然：dirname 是属性名，它的值（如 "mydir"）才是提交时的字段名。
例如：
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
<input type="text" name="q" dirname="q_dir">
当用户输入 “مرحبا”（混合阿拉伯与西班牙语），且浏览器判定方向为 rtl，表单提交时会多带一个键值对：q_dir=rtl。后端收到的就是 q 和 q_dir 两个字段。
- 若省略
dirname值（即只写dirname），浏览器默认使用name+_dir作为字段名（如name="q"→ 提交q_dir） - 如果
name为空或缺失，dirname字段根本不会提交 - 多个 input 共享同一个
dirname值会导致字段名冲突，后端只能收到最后一个的值
服务端收不到 dirname 字段？检查这三点
dirname 是纯客户端行为，不依赖 JS，但容易因表单配置失效。典型失败场景：
- 表单用了
method="get"但 input 在<form>外 —— dirname 只在 form submit 中生效，不响应 onchange 或 click - 提交方式为 AJAX（如
fetch+FormData）——FormData默认不包含 dirname 字段，它只序列化显式的name属性元素 - input 被设为
disabled—— disabled 元素连name都不提交，dirname 更不会出现
验证是否生效：用原生 submit 提交，抓包看请求体（或在 PHP/Node 中打印全部 POST 参数），确认是否存在你指定的 dirname 字段名。
替代方案：需要实时方向检测就别依赖 dirname
dirname 只在提交瞬间快照方向，无法反映编辑过程中的方向变化，也不支持 programmatic 获取。如果业务需要：
- 实时监听输入方向（比如做 RTL 输入提示）→ 用
getComputedStyle(input).direction或检查input.dir，再结合input.value.charCodeAt(0)查首字符 bidi 类别 - 确保某段文本按特定方向渲染 → 直接写
<span dir="rtl">نص</span>，别指望 input 自动处理 - 后端需可靠方向信息 → 不要只信 dirname，应同时提交原始文本，由服务端用 ICU 或 unicode-bidi 库分析首尾强类型字符
dirname 是个轻量级提示机制，不是方向控制开关。它起作用的前提是：表单、name、浏览器自动判定逻辑三者都在线，且你清楚它只送一次、不更新、不保证准确。
