:lang()伪类生效需HTML元素显式声明lang属性且值精确匹配，不推断语言、不自动继承；浏览器按BCP 47前缀匹配但实现有差异，故:lang(zh)在部分Safari中失效而:lang(zh-CN)稳定。
:lang() 伪类能生效，前提是 HTML 元素显式带有 lang 属性，且值匹配。它不推断语言，也不继承 —— 没写 lang，就完全不匹配。
为什么 :lang(zh) 有时不生效，但 :lang(zh-CN) 可以
浏览器对 :lang() 的匹配是前缀式、大小写敏感的字符串比对，不是语义识别。:lang(zh) 理论上能匹配 lang="zh"、lang="zh-CN"、lang="zh-TW"，但实际行为依赖底层解析逻辑，Chrome 和 Safari 对子标签（如 CN）的宽松处理程度不同，导致兼容性波动。
-
html lang="zh-CN"→:lang(zh)在部分 Safari 版本中不触发，但:lang(zh-CN)稳定命中 -
html lang="zh-Hans"不会被:lang(zh)匹配，必须写成:lang(zh-Hans) - 推荐写法：同时列出常见变体，例如
html:lang(zh), html:lang(zh-CN), html:lang(zh-TW), html:lang(zh-HK) - 或改用属性选择器兜底：
html[lang^="zh"]，但注意它会误中lang="zhx"这类非法值
:lang() 必须作用于带 lang 的具体元素，不能靠继承
常见错误是只在 上设语言，然后指望 p:lang(ja) 命中一段日文段落——只要那段 <p></p> 没显式写 lang="ja"，就不会匹配。
- 混合内容（如中英日混排）必须为每段文字单独加
lang属性：<p lang="ja">こんにちは</p> -
<span lang="ar">مرحبا</span>才能被span:lang(ar)选中 - 浏览器不沿 DOM 向上查找最近的
lang，也不自动 fallback 到的值
字体声明最容易踩的坑：fallback 顺序和跨语言覆盖失效
直接写 font-family: "Noto Sans CJK SC", sans-serif; 看似合理，但若用户系统没装该字体，sans-serif 会回退到系统默认无衬线字体（比如 macOS 的 Helvetica），而 Helvetica 对日文、韩文字符集支持极差，结果就是方块或异常字形。
- 每个
:lang()规则里，font-family必须把该语言「强支持」的字体放在最前面：中文用"PingFang SC"或"Hiragino Sans GB"，日文优先"Hiragino Kaku Gothic Pro"，韩文用"Malgun Gothic" - 通用 fallback（如
sans-serif或system-ui）必须放在最后，绝不能放最前 - 某些浏览器（如旧版 Safari）对
:lang()下的字体链解析不一致：可能跳过整个声明，或只取第一个可用字体撑满整行
如何验证 :lang() 是否真在起作用
最可靠的方式不是看渲染效果，而是打开开发者工具，在 Elements 面板中右键目标元素 → “Force element state” → 勾选 :lang(xxx)，观察样式是否即时应用；或者在 Console 中执行 getComputedStyle(document.querySelector('p[lang="ja"]')).fontFamily，确认返回值是否符合预期。
立即学习“前端免费学习笔记（深入）”；
真正容易被忽略的是：多语言站点上线前，必须在 Windows/macOS/Linux + Chrome/Firefox/Safari/Edge 多端组合测试，尤其关注中日韩混排段落的字体回退链是否完整、是否出现意外 fallback 到英文字体。
