语义化标签是降低维护成本的关键手段：用<nav>替代<div class="navigation">可避免多文件修改、class冲突和DOM查询歧义，提升协作与长期迭代效率。
语义化标签不是“让代码看起来更专业”的装饰，而是直接决定你改一个导航栏要不要翻五个文件、查三个 class、再确认一遍有没有闭合错的硬性成本控制手段。
为什么用 <nav> 比用 <div class="navigation"> 更省时间
当你写 <nav>，DOM 结构里就天然带了语义边界：它只该放导航链接，不该塞搜索框或广告位；JS 里 document.querySelector('nav') 能稳稳命中，不用靠 class 名猜意图；CSS 里写 nav ul 也比 .navigation ul 更少歧义——后者可能被复用在侧边栏、页脚甚至弹窗里。
常见错误现象：class="header" 在页头、文章头、卡片头各来一遍，结果改顶部 logo 时，.header img 把三处都干掉了；换成 <header> + <article><header>，样式和 JS 就能按语义自然隔离。
- 使用场景：组件复用率高、多人协作、长期迭代的项目
- 性能影响：无额外开销，反而减少 DOM 查询时的 class 匹配遍历
- 兼容性：所有现代浏览器原生支持，IE9+ 基本可用（需注意部分旧版 screen reader 支持度）
<main> 必须唯一且不嵌套，否则维护会失控
<main> 表示页面中与当前上下文强相关、可独立分发的核心内容。它不是“视觉上居中那块”，也不是“除了 header footer 剩下的部分”。一旦嵌套（比如 <main><main>）或重复（比如列表页和详情页都塞一个 <main>），document.querySelector('main') 就不再可靠，自动化测试、无障碍检查（如 axe）、甚至 SSR 数据注入都可能出错。
立即学习“前端免费学习笔记（深入）”；
容易踩的坑：<main> 里塞了 <aside> 或 <footer> ——这些本该是同级兄弟元素；或者把整个 SPA 的根容器包成 <main>，导致路由切换时语义断裂。
- 正确做法：每个 HTML 文档有且仅有一个
<main>，且它不包含<header>、<footer>、<aside> - 为什么这样做：搜索引擎、屏幕阅读器、自动化工具都依赖这个唯一性做内容权重判断和焦点管理
- 验证方式：运行
document.querySelectorAll('main').length !== 1应该永远返回false
用 data-module 配合语义标签，比堆 class 更可控
当你要给 JS 绑定行为时，别再写 class="js-dropdown-toggle" 或 id="nav-burger"。用 data-module="navigation" 放在 <nav> 上，JS 里直接 document.querySelectorAll('[data-module="navigation"]') ——既不污染 class（避免样式和行为耦合），又不会因 ID 冲突或 class 重命名失效。
对比示例：
❌ <div class="nav js-nav-open" data-breakpoint="768"> ✅ <nav data-module="navigation" data-breakpoint="768">
这种写法让结构、样式、行为三层彻底解耦：CSS 只管 nav，JS 只认 data-module，HTML 本身说清楚“这是导航”。
- 参数差异：
data-属性名可自定义，但必须小写、用短横线分隔（data-module-id合法，dataModuleId不合法） - 容易踩的坑：把业务逻辑塞进
data-值里（如data-state="active"），这该由 JS 控制，不该固化在 HTML 中 - 可维护性提升点：改 JS 行为时，不用扫全项目找 class，只查
data-module即可定位作用域
最常被忽略的复杂点：语义不是贴标签，而是对内容做真实归类。一个“热门推荐”区块，如果它只是当前页面的附属内容，就该是 <aside>；如果它是独立可订阅、可 RSS 分发的文章合集，才考虑用 <section> 配 <h2>。标签选错，后期所有依赖语义的链路都会悄悄偏移——而这种偏移，往往要等上线三个月后 SEO 流量下滑或无障碍审计失败才被发现。
