是，屏幕阅读器会因lang属性缺失或非法（如zh_CN、Chinese、en-us）而直接 fallback 到系统默认语音引擎，将中文读成英文音素；同时导致字体回退失效、hreflang整组被搜索引擎静默忽略。
lang属性没设或写错，屏幕阅读器真会念错
不设 lang 或设成 zh_CN、Chinese、en-us 这类非法值，屏幕阅读器（NVDA、VoiceOver、JAWS）会在解析 HTML 阶段直接跳过语言声明，fallback 到系统默认语音引擎——中文页面被读成英文音素，“微信”变成 /weɪ tʃiːn/，“支付宝”读作 /zhī fù bǎo/ 的英语口型。这不是偶发问题，是语义链断裂的必然结果。
常见错误包括：
- <html lang="zh">：太宽泛，旧版 JAWS 可能降级为英文 TTS
- <html lang="zh_CN">：下划线非法，浏览器静默忽略，等效于无 lang
- <body lang="zh-CN">：只影响该元素内文本，整页仍被识别为“未声明语言”
Chrome 翻译按钮不出现，或点了就翻错
Chrome 不靠内容扫描猜语言，而是优先信任 <html lang="...">。如果页面全是中文但 lang="en"，它可能：直接跳过翻译提示；或误判为“英文乱码”，先翻成日语再翻回中文，导致“React Router”变成 “瑞克特 路由器”。
更隐蔽的问题是动态改 document.documentElement.lang 无效——Chrome 只在 HTML 解析阶段读一次，JS 后续 patch 对已加载页面的翻译行为零影响。
多语言混排时，仅靠根 lang 也不行：
- <p>我们调用 <code>fetch()</code> API</p> 中的 fetch() 和 API 会被中文引擎硬读
- 必须显式加 <code lang="en">fetch()</code> 才触发英文音素切分
中文字体 fallback 失效，显示方块或标点异常
浏览器不是靠字符判断该用什么字体，而是靠 lang 值激活内置的语言感知 font fallback 链。设错或漏设，中文就会被扔进西文字体链，最终落到 Courier New 或 Times 上——结果是：
立即学习“前端免费学习笔记（深入）”；
- macOS Safari 下中文显示为空心矩形（
lang="zh_cn"→ PingFang SC 被跳过） - 引号「」变成英文 " "，左右间距爆炸（Chrome 对
lang="en"的中文段落禁用中文标点挤压） - 同一行中英混排，英文正常、中文糊成一片（
lang缺失 → 中文被当 Latin-1 字符流解析）
验证方式：DevTools → Elements → 选中文 <p> → Computed → 展开 font-family → 看 “resolved value” 第一个字体是不是 "Microsoft YaHei" 或 "PingFang SC"。不是，说明 lang 没生效。
hreflang 整组失效，SEO 直接降权
lang 写错会导致 <link rel="alternate" hreflang="zh-CN"> 全组被 Google 静默忽略——不是报错，而是当没写。原因很硬：Google 要求页面根 lang 值与 hreflang 中的语言代码严格一致（大小写、短横线），zh-cn ≠ zh-CN，zh_Hans ≠ zh-Hans。
更麻烦的是，hreflang 必须成组互指：有 en-US、zh-Hans、ja-JP 三个版本，每页 <head> 都得写三条 <link>，包括指向自身的那条。漏掉任意一个，整组可能被降权。而所有 href 必须是绝对 URL，HTTP/HTTPS 协议必须一致——混用等于两个不同页面。
容易被忽略的细节：
- lang 和 hreflang 职责分离：lang 决定渲染和朗读，hreflang 只告诉搜索引擎“还有哪些语言版本”
- lang="x-default" 是兜底页（如语言选择器页），不能替代具体语言标签
