lang属性必须严格遵循BCP 47标准（如zh-CN），写错则静默降级为und；:lang()仅在HTML解析时读取一次，JS修改document.documentElement.lang无效；动态切换需批量更新所有显式lang元素、title并重载第三方组件。
lang属性写错格式，浏览器直接当无效值处理
浏览器对lang值的校验非常严格，写错一个字符就等于没写。常见错误包括：zh_CN（下划线）、ch（非BCP 47标准）、Chinese（自然语言名）、zh（缺地区码）。这些都会被静默降级为und（unknown language），导致:lang(zh-CN)完全不匹配。
验证方法：打开开发者工具，在 Console 输入document.documentElement.lang，看返回值是否是zh-CN、en-US这类合法格式；再检查 Elements 面板里标签上显示的lang属性是否拼写一致、有无空格或不可见字符。
注意大小写：虽然规范允许小写，但部分 iOS VoiceOver 对ZH-cn这种混用大小写的写法无法匹配语音引擎。
:lang()选择器不触发，根本不是CSS问题
:lang()伪类只在 HTML 解析时读取一次lang值，之后 JS 修改document.documentElement.lang不会重计算样式。所以你改了根节点语言，但页面字体、引号、断行等样式仍按旧规则渲染。
立即学习“前端免费学习笔记（深入）”；
真正生效的前提是：必须出现在首屏 HTML 中（服务端输出或静态 HTML），且所有需要语言感知的元素要么自身带lang，要么能从祖先正确继承——比如<section lang="en"><p>See you in 北京</p></section>中，p本身没设lang，但:lang(zh)依然能命中“北京”里的文字，前提是它被包裹在<span lang="zh">北京</span>之类显式声明的节点里。
如果:lang(zh)没生效，先确认目标元素是否真的带lang="zh"或其祖先有lang="zh-Hans"这类兼容值；别用[lang="zh"]去测试，它的匹配逻辑完全不同。
动态切换语言时只改根节点，等于白忙活
SPA 切换语言时，仅执行document.documentElement.lang = "en-US"是无效操作。屏幕阅读器（NVDA/VoiceOver）和浏览器排版引擎在解析完 HTML 后就锁定了语言上下文，JS 后续赋值不会触发字体重排、:lang()重匹配或翻译模型切换。
必须同步做三件事：
- 遍历所有显式声明
lang的元素：document.querySelectorAll('[lang]')，逐个更新el.lang = "en-US" - 更新
document.title（哪怕赋空字符串），强制屏幕阅读器重读根节点 - 若涉及第三方组件（如代码高亮库、富文本编辑器），检查它们是否依赖
lang属性初始化，必要时手动触发重载
更稳妥的做法是在服务端或 SSR 阶段就输出正确的lang值，避免前端补救。
字体链和排版样式不切换，常因lang未穿透到具体文本
即使写对了，:lang(zh-CN) { font-family: "PingFang SC" }也可能不生效——因为目标<p></p>里混着英文单词或日文片假名，而该p没显式声明lang，浏览器默认按根节点语言处理整段，不会自动切分。
解决方式不是给每个词加lang，而是聚焦语义化场景：
<blockquote lang="ja">おはようございます</blockquote><code lang="en">useState<q lang="fr">C'est magnifique</q>
这些才是:lang()真正能稳定捕获的节点。别指望<div lang="en"><p>API 接口文档</p></div>中的“接口”二字自动走中文排版——它仍按en渲染，除非你把“接口文档”包进<span lang="zh">接口文档</span>。
最常被忽略的一点：lang 和 meta charset 是耦合的。一个写错，另一个再准也没用；回归测试若只查 DOM 文案、不验响应头和文件真实编码，就等于绕过故障主因。
