lang属性比语义标签更直接影响国际化SEO，因搜索引擎依赖它判断页面主语言；缺失或错误设置会导致索引错乱、hreflang失效；必须设在<html>根节点并动态注入，且各语言页需保持语义结构一致。
HTML语义本身不“国际化”，但语义化结构可以被多语言内容安全承载；工程化SEO维护的关键不是堆砌标签，而是建立可验证、可收敛、可自动巡检的语义契约。
为什么 lang 属性比语义标签更直接影响国际化 SEO
搜索引擎（如 Google）依赖 lang 属性判断页面主语言，而非标签名。比如 <article> 在中文页和英文页语义一致，但若缺失 lang="zh-CN" 或 lang="en-US"，可能导致：页面被错误归入其他语言索引、hreflang 标签失效、多语言站点交叉收录。
-
lang必须设在<html>根节点，子元素仅在语言切换时覆盖（如双语词典条目用<span lang="ja">日本語</span>） - 避免
lang="auto"或空值 —— 浏览器和爬虫均不识别 - 服务端渲染时，
lang应随用户语言偏好或 URL 路径（如/en/blog）动态注入，不能硬编码
<link rel="alternate" hreflang> 和语义结构必须对齐
hreflang 声明的是“同一内容的不同语言版本”，但若各语言页的语义结构不一致（比如中文页用 <main> 包全文，英文页却用 <div class="main-content">），Google 会降低对 hreflang 关系的信任度，导致多语言流量错配。
- 所有语言版本必须使用完全一致的语义骨架：
<header>→<nav>→<main>→<footer> - 各语言页的
<h1>文本语义需等价（不是字面翻译，而是功能对等），例如中文“产品介绍”对应英文“Product Overview”，而非直译“Introduction of Products” - 禁止在某语言页中额外插入
<aside>或<section>而其他语言页没有 —— 差异应仅限文本内容，不包括结构
工程化维护：用 ESLint + 自定义规则卡住语义退化
靠人工 review 无法长期守住语义质量。真正落地的工程化做法，是把语义约束转为可执行的代码检查规则。
立即学习“前端免费学习笔记（深入）”；
- 用
eslint-plugin-jsx-a11y检查<img>缺alt、<button>缺aria-label等基础项 - 自定义 ESLint 规则，校验关键语义标签出现次数：如报错 “Multiple
<main>found” 或 “Missing<main>in page root” - CI 流程中加入
w3c-validatorCLI 或axe-core扫描，失败则阻断部署 —— 尤其检查lang、hreflang、标题层级跳跃等高风险项
容易被忽略的点：语义一致性 ≠ 标签数量一致
多语言站点常误以为“每个语言页都放一个 <nav> 就算语义对齐”。实际中，导航结构可能因本地化需求而不同：比如日文站增加“客户支持”入口，英文站没有。这时正确做法是保留 <nav> 标签，但通过 CSS display: none 隐藏非目标语言项，或服务端条件渲染 —— 而不是删掉整个 <nav> 改用 <div>。结构框架必须稳定，内容填充才允许差异化。
