必须在标签上设置lang属性，因为屏幕阅读器只认根节点的lang声明来初始化语音引擎，其他位置的lang无效；lang值需符合bcp 47标准（如zh-cn），错标会导致发音错误、seo降权及翻译混乱。
直接用 lang 属性控制语音合成的发音基础，比任何 JS 语音 API 都更底层、更可靠——它不依赖用户是否点了“朗读”按钮，而是决定屏幕阅读器从页面加载那一刻起就用什么音调、停顿、重音规则来读你写的每一个字。
为什么必须在 lang，而不是其他地方
浏览器和屏幕阅读器（NVDA、VoiceOver、JAWS）只认 这个根声明。改 或给某个 <div> 加 <code>lang，对整页语音引擎选择毫无影响——它们压根不扫描这些节点来初始化语音模型。
-
lang值必须符合 BCP 47 标准，比如zh-CN、en-US、ja-JP，不能写成zh或chinese - 搜索引擎也靠这个判断页面主语言，错标会导致 SEO 降权或翻译推荐错乱
- 某些浏览器（如 Safari）在未声明
lang时，会把中文汉字按拉丁字符逐字拼读，例如“北京”变成 “B-e-i-j-i-n-g”
混排多语言时怎么让屏幕阅读器实时切换语音
局部语言切换靠嵌套 lang，不是靠 JS 模拟。一段英文引文、一个日文术语、甚至代码块里的 console.log()，只要加了正确 lang，VoiceOver 就会在读到那块时自动切语音引擎。
- 用
<blockquote lang="en">...</blockquote>包裹英文引用，避免整段被中文引擎硬读 - 中英术语对照表，每个单元格单独加
lang：<td lang="zh">辅助技术</td> <td lang="en">Assistive Technology</td> - 不要用
aria-label覆盖多语言文本——它会吞掉原始内容，导致双语信息丢失 - 注意：CSS 的
hyphens: auto也依赖lang，错标会导致连字符断错位置
lang 和 Web Speech API 的 SpeechSynthesisUtterance.lang 别混用
lang 是 HTML 层语义，决定屏幕阅读器如何读；SpeechSynthesisUtterance.lang 是 JS 层控制，只影响 speechSynthesis.speak() 主动触发的朗读——两者作用域、触发时机、兼容性完全不同。
- 即使你用 JS 设置
utterance.lang = "zh-CN"，如果页面没设lang，屏幕阅读器仍会默认用英文引擎读页面正文 - Chrome 和 Edge 支持
getVoices()返回多语言语音，但 Safari 只返回当前系统语言对应的语音，且必须由用户手势触发 - 别在
onload里自动调用speak()：iOS 和部分 Android 浏览器会静音，且违反 WCAG 2.1 的“用户控制”原则
最常被忽略的点是：语音合成是否自然，80% 取决于 lang 是否准确、是否嵌套得当，而不是用了多高级的 TTS 库。一个没 lang 的页面，再好的语音 API 也救不回发音错乱的体验。
