最常见原因是HTML中未声明lang属性或写法非法，如lang="zh_cn"（下划线）、lang="chinese"（非BCP 47标准）、lang="zh zh-CN"（空格分隔），浏览器不纠错且严格区分大小写，必须确保标签存在正确值如zh-CN。
为什么[lang="zh-CN"]有时不生效
最常见原因是 HTML 中根本没写 lang 属性，或写法非法。比如：lang="zh_cn"（下划线）、lang="chinese"（非 BCP 47 标准）、lang="zh zh-CN"（空格分隔多值）——这些都会导致选择器完全不匹配。浏览器只认标准格式，不自动纠错。
属性选择器严格区分大小写：[lang="en-US"] 不会匹配 lang="en-us"，尽管部分浏览器宽松处理，但不可依赖。
- 检查 DOM：用浏览器开发者工具确认目标元素（通常是
）是否真实存在lang属性且值正确 - 避免在服务端模板或构建脚本中拼错，例如误写成
language或data-lang -
[lang="zh-CN"]是精确匹配，不会命中lang="zh-TW"；如需覆盖所有中文变体，改用[lang^="zh"]（但注意可能误中lang="zhx"这类非法值）
[lang|="en"] 和 [lang^="en"] 的区别在哪
[lang|="en"] 是专为语言子标签设计的语法，它匹配 lang="en" 或 lang="en-US"、lang="en-GB" 等“以 en 开头并紧接连字符或结尾”的值，语义更严谨；而 [lang^="en"] 是纯字符串前缀匹配，会命中 lang="en-US"、lang="en-x-custom"，甚至 lang="english" —— 只要开头是 en 就算。
- 推荐优先用
[lang|="zh"]处理区域变体，比[lang^="zh"]更安全 -
[lang|="en"]不会匹配lang="en_US"（下划线）或lang="zhen"（非连字符结尾） - 若后端输出语言值不稳定（如偶发
lang="en-us"小写），[lang|="en"]仍可能失效，此时需统一标准化输出
和 :lang(zh) 混用时要注意什么
[lang="zh-CN"] 和 :lang(zh) 行为不同：:lang(zh) 支持继承和子字符串匹配（能命中 lang="zh-CN" 的子元素），而 [lang="zh-CN"] 只找属性值**完全相等**的元素。但两者都依赖 DOM 中真实存在的 lang 值，不会自动读取 navigator.language。
立即学习“前端免费学习笔记（深入）”；
- 如果只在
上设值，那么p:lang(zh)和p[lang="zh-CN"]都能匹配其内部未显式声明lang的<p></p>（因继承）；但p[lang="zh-CN"]无法匹配<p lang="zh-TW"></p>，而p:lang(zh)可以 - 混合内容场景（如中英双语段落），必须给具体文本节点加
lang属性：<p lang="ja">こんにちは</p>，否则:lang(ja)或[lang="ja"]都不会生效 - React/Vue SSR 页面要确保服务端渲染时已注入正确的
lang值，否则首屏样式丢失
字体声明里最容易被忽略的陷阱
即使选择器匹配成功，字体也可能不显示——问题常出在 font-family 声明顺序上。把 sans-serif 放最前，等于主动放弃语言专用字体；系统找不到第一个字体时直接跳过后续所有候选，最终回退到默认英文字体，导致日文、韩文显示异常。
- 每个语言规则必须把该语言强支持的字体放在最前：
[lang="zh-CN"] { font-family: "PingFang SC", "Microsoft YaHei", sans-serif; } - 不要复用同一套
font-family值覆盖所有语言；中、日、韩字体需分开声明，各自前置对应系统字体 -
@font-face若用于自定义字体，必须配合unicode-range限定字符范围，否则加载冗余、触发 FOIT/FOUT
lang 属性是否真实、标准、可继承，以及字体链是否按语言分层且顺序无误。任何一环断开，样式就停在半路。 
