语义化标签不是“可选”，而是渲染逻辑的一部分，因为浏览器和辅助技术直接依据其决定内容权重、导航顺序与默认行为；如用替代会导致焦点失效、触控反馈丢失及safari意外缩放，是唯一被强制识别为主体内容的容器，缺省或重复使用会弱化seo与阅读模式信号，内链接被搜索引擎聚合为导航集影响权重分发，而完全不参与该机制，具备独立分发性（支持rss、社交卡片提取），仅表主题分组，嵌套过深会增加composite层引发重绘抖动，标题层级错乱（如跳级或复数）会使搜索引擎和读屏软件放弃结构解析，表单与图片等交互锚点必须使用原生标签保障focus管理、验证反馈与可访问性。
为什么语义化标签不是“可选”，而是渲染逻辑的一部分
浏览器和辅助技术（如屏幕阅读器）会直接依据语义标签决定内容权重、导航顺序与默认行为。用 <div class="button"> 替代 <code><button></button>，不仅让键盘 Tab 焦点失效，还会导致移动端点击区域缩小、触控反馈丢失，甚至在 Safari 中触发意外的 zoom 行为。
-
<main></main>是唯一被浏览器强制识别为“主体内容”的容器，SEO 抓取和阅读模式都依赖它；缺省或重复使用会直接弱化页面核心内容信号 -
<nav></nav>内部链接会被搜索引擎聚合为“导航链接集”，影响站内权重分发；而<div class="nav"> 完全不参与该机制 <li> <code><section></section>和<article></article>的区别不在视觉，而在可独立分发性：<article></article>可被 RSS 抓取、被社交平台提取为卡片，<section></section>仅表示主题分组 - 用 CSS
display: contents替代无功能包裹层（注意 Safari 15.4+ 才完全支持） - 动态插入内容时，优先用
DocumentFragment批量 append，避免逐个appendChild触发多次 layout
嵌套超过三层就该警惕 DOM 渲染开销
Chrome DevTools 的 Layers 面板能直观显示：每多一层无意义的 <div> 包裹，都会增加 Composite 层数量，尤其在动画或滚动场景下引发重绘抖动。真实项目中，常见于“为了加 class 而套 div”或“JS 框架生成冗余 wrapper”。
<ul>
<li>检查 DOM 树深度：右键任意元素 → “Reveal in Elements panel”，观察路径长度；超过 <code>body > div > div > div > ... 三层即需重构
标题层级错乱比没写 CSS 更伤 SEO 和可访问性
搜索引擎和 NVDA 等读屏软件严格按 <h1></h1>→<h2></h2>→<h3></h3> 的嵌套逻辑构建内容图谱。跳级（如 <h2></h2> 后直接 <h4></h4>）或复数 <h1></h1> 会让它们放弃整段结构解析，退化为纯文本扫描。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 每个页面必须且仅有一个
<h1></h1>，通常对应<main></main>的主标题；侧边栏、弹窗等非主内容区禁用<h1></h1> -
<h2></h2>应作为一级内容区块标题（如“设备状态”、“报警列表”），而非按钮文字或表单项标签 - 用
<strong></strong>或<em></em>替代为强调而滥用<h3></h3>—— 前者是语义强调，后者是结构层级
表单和图片这类“交互锚点”必须原生可控
用户对表单提交、图片加载失败、视频播放中断的容忍度极低。任何用 <div> + JS 模拟的控件，都会在 focus 管理、验证反馈、错误恢复上暴露短板。
<ul>
<li>
<code><label for="id"></label> 不只是提升点击热区，更是建立 input 与描述的 DOM 关联；缺失时，VoiceOver 无法朗读提示文案
<img> 必须带 alt 属性，空值写成 alt=""（表示装饰图），不能省略；否则屏幕阅读器会读出文件名，暴露路径信息required、type="email" 等原生属性，比 JS 正则更可靠——Safari 会自动触发软键盘类型切换，iOS 会提供邮箱快捷输入<section></section> 内部若嵌套了 8 个 <div>，那它的语义价值几乎归零。结构优化不是贴标签，而是让每个节点都有不可替代的职责。</div>
