lang 属性必须写在 标签上，作为浏览器解析多语言内容的起点；局部切换需用内联 lang 显式声明，且值须为合法 bcp 47 标签。
lang 属性该写在哪个 HTML 元素上
必须写在 标签上，这是浏览器解析多语言内容的起点。如果只写在某个 <p></p> 或 <div> 里，屏幕阅读器、搜索引擎、翻译插件基本不认——它们优先看根元素的 <code>lang。
常见错误现象：
• 页面主体是中文，但 没改，结果 Chrome 自动翻译成英文再翻回中文，语义全乱
• 多语言切换后只改了部分文案的 lang，没同步更新 ，导致语音朗读仍用旧语种发音
实操建议：
• SSR 页面：服务端渲染时，根据用户语言偏好动态生成 或
• SPA 页面：在路由切换或语言切换钩子中，执行 document.documentElement.lang = "ko"（别只改 state）
• 静态页面：每个语言版本单独一份 HTML， 标签硬编码对应值，避免 JS 注入延迟导致闪动
zh-CN、zh-SG、ja-JP 这类子标签什么时候必须用
当同一语言在不同地区存在显著拼写、标点、数字格式或术语差异时，才需要细化。不是“用了更好”，而是“不用会出错”。
使用场景举例：
• 中文：简体（zh-CN）和繁体（zh-TW）混排时，lang="zh" 不够，浏览器无法区分「软件」vs「軟體」的正确断行与字体 fallback
• 英文：美式（en-US）和英式（en-GB）拼写差异（color / colour），影响 spellcheck 和输入法候选词
• 日文：日本（ja-JP）和日本海外版（ja）对日期/货币格式解析不同，Intl.DateTimeFormat 依赖这个值
容易踩的坑：
• 把 zh-Hans（汉字书写系统）和 zh-CN（国家区域）混用：前者不带地区含义，浏览器兼容性差，zh-CN 是更稳妥的选择
• 在非拉丁语系中滥用短格式：比如写 ja 而非 ja-JP，某些 iOS 版本的 VoiceOver 会降级为英语发音
• 后端返回语言代码时没做标准化：用户传 zh_ch 或 ZH-CN，前端没转成小写+连字符，导致 lang 值非法
嵌套多语言内容怎么处理 lang 属性
局部语言切换必须用内联 lang，且要显式声明，不能靠继承。浏览器不会自动推断段落里的外语是“引用”还是“正文”。
实操建议：
• 引用外文原文：用 <blockquote lang="fr">Je suis français.</blockquote>
• 混排技术术语：如中文文档里出现 <code lang="en">useState，加 lang 可触发 IDE 插件的英文语法高亮
• 多语言按钮文案：不要只靠 class 控制显示，每个 <button></button> 应带对应 lang，方便无障碍工具识别发音规则
性能提示：
• 不要给每个单词都加 lang，粒度太细反而增加 DOM 体积、拖慢可访问性树构建
• 避免在大量列表项中重复写相同 lang，可用父容器统一声明，再用 CSS [lang="de"] 控制样式
lang 属性和 hreflang、Content-Language 的关系
三者完全不等价，不能互相替代。最容易被当成一回事来用，结果 SEO 和 HTTP 缓存全乱。
关键区别：
• lang（HTML 属性）：告诉浏览器和辅助技术“这段文字**实际是什么语言**”，影响渲染、断字、语音合成
• hreflang（<link> 属性）：告诉搜索引擎“这个链接指向**哪种语言/地区的页面版本**”，纯 SEO 用途，不影响页面内行为
• Content-Language（HTTP 响应头）：告诉代理和 CDN “这个响应体**默认适用的语言人群**”，影响缓存键（比如 Varnish 会把 zh-CN 和 en-US 当作不同资源缓存）
典型错误：
• 只配了 hreflang 就以为解决了多语言支持，页面内 还是空的
• Nginx 返回头写了 Content-Language: en，但 HTML 里是 ，CDN 缓存策略和浏览器解析直接打架
• 在单页应用里用 JS 切换语言时，忘了调用 history.pushState() 更新 URL 并同步设置 hreflang 关联，导致 Google 搜索结果展示错版本
最常被忽略的一点：lang 属性的值必须是合法 BCP 47 标签，不能是自定义字符串（比如 lang="mylang"），否则所有依赖它的功能都会静默失效——既不报错，也不工作。
