必须用zh-CN、zh-TW、zh-HK等标准BCP 47地区码，因浏览器和读屏软件只识别合法地区码；zh-CN与zh-TW需区分字体回退、标点宽度、断词规则及拼音输入法行为，不区分会导致排版错位、语音朗读错误、SEO报错。
必须用 zh-CN、zh-TW、zh-HK，不能用 zh 或 zh_Hans 这类模糊/非法写法——浏览器和读屏软件只认标准 BCP 47 地区码，写错等于没写。
为什么 zh-CN 和 zh-TW 必须区分
字体回退、标点宽度、断词规则、拼音输入法默认行为，甚至部分 CDN 的缓存策略，都依赖地区码。比如：zh-CN 下「。”」会紧贴前字，zh-TW 下「。」后默认多一个空格；Chrome 拼写检查对 zh-TW 启用繁体词典，对 zh-CN 启用简体词典。不区分会导致排版错位、语音朗读腔调混乱（如把「著」读成 zhù 而非 zhuó），Google Search Console 可能报“语言未明确”。
zh-Hans 和 zh-Hant 能不能替代地区码
不能作为主语言声明使用。zh-Hans 表示“简体字”，但不指定地域；zh-Hant 同理。它们在部分现代工具（如某些 CMS 的导出逻辑）中被接受，但旧版 Safari 的 :lang(zh) 伪类可能无法匹配，NVDA 语音引擎加载简体 TTS 时可能 fallback 到英文发音。实际项目中，zh-CN 是全链路兼容性最稳的选择；只有当你明确要覆盖港澳台用户且强制统一用简体（排除所有繁体变体）时，才考虑 zh-Hans，但仍需测试 VoiceOver 和 Chrome 翻译按钮是否正常出现。
局部混排时怎么设 lang 才不冲突
根元素用 zh-TW，不代表页面里所有中文都是台湾用语。遇到大陆术语（如「微信」）、英文 API 名（如 useState）、日文引文，必须显式标注：
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
-
<p lang="zh-CN">微信小程序支持离线缓存</p>—— 明确该段按大陆规范处理 -
<code lang="en">useState</code>—— 防止屏幕阅读器硬读成“用状态” -
<blockquote lang="ja">ありがとうございます</blockquote>—— 触发日语语音引擎
不要给 <div> 加 lang 批量包裹多个段落，语义不清，还可能干扰父级 :lang(zh-TW) 样式匹配。
动态切换语言时最容易漏的三件事
SPA 切换语言不是改个 document.documentElement.lang 就完事：
- 必须重写
document.documentElement.outerHTML或整页刷新，否则已渲染的 DOM 不会响应新lang值，:lang()样式不重算，Chrome 翻译按钮不更新 - 所有带
lang属性的子元素（如<p lang="en">）必须同步更新，除非你确定那段英文引用始终该是英文 -
hreflang<link>标签必须和当前页的html lang值严格一致，否则搜索引擎分流错误，用户点进英文页却看到lang="zh-CN"的 HTML
真正难的不是写对值，而是确保每个语言片段——从根到代码块注释——都有对应且合法的 lang，且首屏 HTML 就得对。JS 动态补救只是障眼法，辅助技术根本看不见。
