html语义化是让结构、内容与意图对齐，确保浏览器、屏幕阅读器、搜索引擎和维护者准确理解内容角色；需正确使用标签而非仅视觉模拟，如用而非，并验证无障碍属性是否生效。
HTML语义化不是“加几个新标签就完事”，而是让结构、内容与意图对齐——浏览器、屏幕阅读器、搜索引擎和后续维护者都能不靠猜就知道某块内容是导航、主区域还是辅助信息。
哪些标签该用、哪些不该滥用
语义化核心是「用对的标签，而不是看起来像的标签」。比如 <div class="header"> 不等于 <code><header></header>，前者只是视觉模拟，后者自带 ARIA role 和隐式语义；但反过来，<section></section> 也不是万能分块工具，它要求内部有独立标题（<h2></h2>–<h6></h6>），否则就是语义污染。
-
<nav></nav>只用于主导航链接集合，页脚的“关于我们/条款”不算导航，用<footer></footer>+ 普通列表更合适 -
<article></article>表示可独立分发/复用的内容（博客正文、新闻条目），侧边栏推荐卡片不是<article></article>，用<aside></aside> -
<main></main>页面中唯一，且不能嵌套在<article></article>或<aside></aside>内 - 避免用
<h1></h1>到<h6></h6>单纯调样式，层级必须反映内容逻辑，跳级（如<h2></h2>后接<h4></h4>）会破坏屏幕阅读器导航
如何检查语义是否真正生效
光写对标签不够，得验证浏览器和辅助技术是否识别它。最直接的方式是打开 Chrome DevTools → Elements 面板，右键元素 → “Inspect Accessibility Properties”，看 role、name、level 是否符合预期。常见失效场景：
-
<button></button>被设为display: block+ 手动加点击事件，却忘了type="button"，导致表单意外提交 -
<img>缺alt，或写成alt=""却没确认是否真为装饰图（装饰图才该空，数据图必须描述） -
<time datetime="2023-05-20">5月20日</time>的datetime值格式错误（如写成"2023/05/20"），导致机器无法解析 - 用
<div role="button"> 替代 <code><button></button>，却没加tabindex="0"和键盘事件（Enter/Space），键盘用户完全无法操作和 CSS、JS 协作时的语义边界
样式和交互代码不该破坏 HTML 的语义基础。例如：用 JS 动态切换
class控制显隐时，别只靠display: none隐藏关键导航，应同步加aria-hidden="true"；CSS 重置（如移除<button></button>默认边框）后，必须确保焦点状态（:focus-visible）仍清晰可见。- 组件库封装时，避免把
<input type="checkbox">包进<div> 后再用 <code>label[for]关联——ID 生成冲突或丢失会导致语义断裂 - 用
<details><summary></summary></details>做折叠面板时，别用 JS 强行替换<summary></summary>的默认行为，它的展开/收起已内置键盘支持（Space/Enter）和语义角色 - 服务端渲染页面若用
data-*属性传参给 JS，别让它挤占语义空间，比如data-id可以，但data-role="header"就是在覆盖<header></header>的原生语义
真正的语义化难点不在标签选择，而在于持续对抗「视觉优先」惯性——当设计稿没区分主副标题层级、当产品经理说“这个按钮就放这儿，别动结构”，你得知道哪里能妥协，哪里一旦松口，后续的可访问性补救成本会指数级上升。
- 组件库封装时，避免把
