lang属性写错或漏设会导致字体回退失效；浏览器严格依据BCP 47标准（如zh-CN、ja-JP）触发语言感知字体链，错误格式（如zh_CN、chinese）会使中文被当英文处理，引发标点异常、引号错位、混排糊化或方块字。
lang属性写错或漏设，字体回退直接失效
浏览器不是靠内容猜语言，而是严格按lang值触发内置的语言感知字体链。写错、漏写或用非标准格式（如zh_CN、chinese、zh），中文就会被当成英文走西文字体 fallback 链——结果是标点撑开、引号变英文、混排时中文糊成一片，甚至直接显示方块。
必须用 BCP 47 标准写法：zh-CN（简体中文）、zh-TW（繁体中文）、ja-JP（日语）。iOS VoiceOver 和 Safari 对ja这种短格式支持不稳定，ja-JP才稳妥。
-
lang必须写在<html>标签上，<body lang="zh-CN">或<meta http-equiv="Content-Language">全无效 - 后端返回的
lang值（如ZH-CN或zh_ch）需前端转为小写+连字符，否则被忽略 - 局部多语言内容（比如一段法语引用、
<pre lang="bash">）必须显式加lang，不能依赖继承
lang和charset不匹配，乱码问题根本查不到
很多回归测试只检查 DOM 文案是否替换，却漏掉最常出问题的链路：lang和charset的耦合性。一个错，另一个再准也没用。
现象：页面中文字显示为问号或方块，但 W3C Validator 没报错，控制台也无 JS 异常。
立即学习“前端免费学习笔记（深入）”；
- 用
file -i yourfile.html或 VS Code 的“Save with Encoding”确认磁盘文件真实编码，别信编辑器右下角状态栏 - 打开 Chrome DevTools → Network → 找 HTML 请求 → Headers → 查
Content-Type响应头是否含charset=UTF-8 - 服务端配置要同步：Apache 加
AddDefaultCharset UTF-8；Nginx 在server或location里写charset utf-8
:lang(zh)伪类不生效，先看根节点有没有合法lang
:lang(zh)这类伪类能生效，前提是对应元素真有合法lang值。但更稳妥的做法是直接在具体选择器里写，比如p[lang="zh-CN"]或blockquote[lang="fr"]。
常见错误：写了:lang(zh) { font-family: "PingFang SC", sans-serif; }，但<html lang="zh-CN">没写对，或者被 JS 动态改错后没触发重读。
- 检查控制台是否报错，再确认拼写有无空格或下划线（如
zh- CN） - SPA 切换语言时，仅执行
document.documentElement.lang = "ja-JP"不够，必须同步触发document.title = document.title强制屏幕阅读器重读 - 字体链末尾必须是
sans-serif或serif，不能是system-ui——它会绕过所有语言专用字体
表单验证提示语言不变，别怪lang没起作用
HTML 表单验证的错误提示（比如required、type="email"校验失败时弹出的气泡）默认由浏览器控制，语言取决于用户操作系统或浏览器设置，lang属性本身不会改变这个行为。
强行给<html lang="zh-CN">并不能让 Chrome 在英文系统里弹出中文提示——它只影响屏幕阅读器、SEO 和部分 CSS 伪元素。
- 必须禁用原生验证：
<form novalidate> - 监听
invalid事件并调用e.preventDefault()，否则自定义提示和原生气泡会同时出现 - 不要依赖
e.target.validationMessage，它是只读且语言不可控的；应改用字段的name或id查 i18n 表
真正容易被忽略的，是lang和charset的耦合性：一个错，另一个再准也没用；而回归测试脚本如果只查 DOM 文案、不查响应头和文件编码，等于在绕过最常出问题的链路。
