HTML国际化中lang属性必须显式标注多语言内容元素，作用域为自身及子节点；:lang()选择器支持继承匹配，inputmode和autocomplete需配合lang控制输入行为；BCP 47格式须严格校验。
HTML国际化本身不依赖多语言内容存在，但一旦页面混用多种语言，lang属性就从“可选”变成“必须”——漏写、错写或只靠根标签声明，会立刻触发屏幕阅读器读错、浏览器跳过翻译、CSS排版异常、字体回退失败等实际问题。
lang 属性写在哪才真正生效
它不是只在 <html> 标签上起作用。每个含多语言内容的元素都该显式声明：<p lang="ja">こんにちは</p>、<pre lang="bash">curl -X POST</pre>、
<blockquote lang="fr">C’est la vie.</blockquote></p> <ul> <li><code>lang作用域是**自身及其所有子节点**，不继承父级（除非父级没设，且浏览器按默认回退）
document.documentElement.lang 不会重刷已渲染的子元素语言上下文，屏幕阅读器仍按旧值发音:lang() 选择器为什么比 [lang] 更实用
:lang(en) 能匹配继承来的语言值，[lang="en"] 只认显式写的属性——这对多语言混排页面很关键。
- 例如
<article lang="zh"><p>参见<em lang="en">RFC 9110</em></p></article>，:lang(en)可精准给<em>加英文断行规则，而[lang="en"]才能命中它 - 日文段落需要
word-break: keep-all，但其中嵌入的英文 URL 又需允许断行，就得靠:lang(en) { overflow-wrap: break-word; } - 某些 RTL 场景（如阿拉伯语表单）要用
:lang(ar) { direction: rtl; text-align: right; }，不能只靠全局 class
inputmode 和 autocomplete 不是可有可无的补充
仅设 lang="ja" 不会让软键盘弹出日文输入法；仅设 lang="ar" 也不会自动触发阿拉伯数字键盘。这些行为由 inputmode 和 autocomplete 控制。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
-
<input inputmode="text" lang="ja">→ 触发罗马字/假名输入模式 -
<input inputmode="numeric" type="tel">→ 弹出数字键盘（比type="number"更可靠） -
<input autocomplete="email">→ 浏览器调出邮箱建议，且按当前语言格式（如日文系统优先填「yamada@example.co.jp」而非「Yamada Tarou」） - 错误组合：
<input lang="zh">没加inputmode→ 中文用户仍可能面对英文键盘
BCP 47 格式写错一个连字符就失效
zh-Hans 有效，zh_Hans、zh-CN、chinese 全部无效。非标准值会导致语音引擎拒绝加载、拼写检查关闭、某些 SSR 框架（如 Next.js App Router）跳过该节点渲染。
- 简体中文必须用
zh-Hans，繁体用zh-Hant；不要用zh-CN（那是区域标识，不是语言标签） - 巴西葡萄牙语是
pt-BR，欧洲葡萄牙语是pt-PT；pt单独可用，但语义模糊 - 服务端注入时若从 URL 路径取语言（如
/en/about），别直接拼成lang="en"—— 要校验是否符合 BCP 47，否则/xx-XX这类非法路径会污染整个页面语言上下文
最常被忽略的点：语言切换不只是改文本和 document.documentElement.lang，而是要同步更新所有动态生成的元素的 lang 属性、重置 inputmode、刷新 :lang() 匹配状态——否则新语言下的交互细节（比如光标位置、断行逻辑、语音反馈）会持续沿用旧上下文。
