lang属性必须设在具体表单控件上，不能仅设在外层form；需为label、input、textarea等逐个显式标注合法BCP 47值（如zh-Hans、ar-SA），否则影响朗读、拼写检查、输入法及校验提示语言一致性。

lang属性必须设在具体表单控件上，不能只套在

外层

浏览器不会因为你在<form lang="zh-Hans">里写了中文就自动切换输入方向或朗读语言。它只告诉辅助技术“这段文本该用哪种语言朗读”，也会影响输入法默认行为和拼写检查词典。如果你发现 Chrome 的拼写红线在英文输入框里对中文无效，大概率是 lang 没设对位置。

正确做法是给每个需要控制语言/方向的元素单独加 lang：

• <label lang="zh-Hans">邮箱</label>
• <input type="email" lang="zh-Hans" placeholder="请输入您的邮箱">
• <textarea lang="ar" dir="auto"></textarea>（阿拉伯语需配合 dir="auto"）

注意：lang 值必须是合法 BCP 47 标签，比如 zh-Hans、ar-SA、he-IL，别写 zh 或 arabic。

RTL语言输入时，比dir="auto"更可靠

当表单中混入用户输入的 RTL 内容（如阿拉伯用户名、希伯来语 ID、带连字符的路径），仅靠 dir="auto" 不够稳定——旧版 Safari 和部分 Android WebView 对纯数字或空格开头的字符串 fallback 到 LTR，导致 user-2024 显示为 2024-resu。

立即学习“前端免费学习笔记（深入）”；

此时应使用 <bdi> 包裹不可预知方向的内容：

Doc To HTML

使用 MinerU 文档处理引擎将 Word 文档（.doc、.docx）转换为保留结构和格式的干净 HTML。

下载

• <label>用户名：<bdi id="username-display"></bdi></label>
• JS 动态填入：document.getElementById('username-display').textContent = apiResponse.username;
• 不要写 <bdi dir="rtl">...</bdi>——显式指定会关闭自动探测
• 禁止嵌套 <bdi><bdi>...</bdi></bdi>，旧 WebView 可能失效

placeholder 和 label 文本不随 lang 自动切换，必须动态注入

HTML 标准里没有任何属性能根据浏览器语言自动切换 placeholder 或 label 内容。所谓“多语言表单”，本质是 JS 根据 navigator.language 或用户偏好，把不同语言的字符串注入 DOM；或者由后端渲染时直接输出对应语言的 HTML。

推荐做法：

• 静态资源按语言拆文件：locales/zh-Hans.json、locales/en.json
• 切换语言时，同步更新：label.textContent、input.placeholder、aria-label、title
• 禁用原生校验提示：input.setCustomValidity('')，再手动调 reportValidity() 并接管文案
• 校验函数返回语言无关的错误码（如 "INVALID_EMAIL"），查语言包映射成对应文案

提交前校验提示必须和当前语言一致，否则用户看不懂

如果校验失败时显示的提示文字（如“请输入有效邮箱”）硬编码在 JS 里，或依赖浏览器默认的 ValidityState 提示，就会卡在浏览器语言，和页面其他文案不一致。用户切到中文界面，却看到英文报错，体验直接断裂。

关键点：

• 所有校验文案（包括 title 属性触发的 tooltip）都必须走同一套语言包
• 服务端返回的错误消息如果带语言，前端渲染时也要同步带上对应 lang 属性
• 避免在 JS 里堆 if (lang === 'zh') {...} else if (lang === 'en') {...}，用查表方式更易维护

最易被忽略的是 title 和 aria-describedby 引用的文本节点——它们一旦漏掉语言同步，就等于在多语言表单里埋了个静默 bug。