HTML语义化标签本身不生成树形结构，但能确保树形结构被机器正确解析为逻辑树；纯<ul><li>嵌套仅表达列表关系，需role="tree"和role="treeitem"等ARIA属性才能被识别为可交互树组件，并支持键盘导航与状态感知。
HTML语义化标签本身不生成树形结构，但能确保你写的树形结构（比如组织架构、导航菜单、文档大纲）被机器正确解析为逻辑树——这是搜索引擎和辅助技术“看见”层级关系的前提。
为什么用 <ul><li> 做树状菜单时必须加 ARIA 属性
纯 <ul><li> 嵌套只能表达“列表中的列表”，浏览器和屏幕阅读器默认不认为它是可交互的树组件。没有 role="tree"，键盘用户按方向键无法展开/收起节点；没有 aria-expanded，视障用户不知道某个部门下是否还有下属团队。
- 外层
<ul>必须设role="tree"，每个可展开节点的<li>设role="treeitem" - 动态展开/折叠时，必须同步更新
aria-expanded="true/false"和aria-hidden="true/false"（控制子<ul>是否对辅助技术可见） - 避免给非交互节点（如纯标题行）加
tabindex="0"，否则会干扰焦点流
<main> 和 <section> 怎么配合构建内容语义树
搜索引擎靠 <main> 定位页面核心，再靠内部的 <section> + 标题层级（<h2>→<h3>）推导出子主题分支。跳级或重复 <h1> 会让这棵树断裂。
-
<main>全页只能有一个，且不能嵌套在<article>或<section>内部 - 每个
<section>应有且仅有一个<h2>（或对应层级的标题），作为该区块的语义根节点 - 若某
<section>下还要分组（如“前端工具”里再分“构建工具”“UI 库”），用<section>套<section>，而非硬塞<div class="group">
哪些语义标签会破坏 DOM 树的语义连贯性
看似合理实则危险的操作：把 <nav> 放进 <footer>、在 <main> 里塞广告位、用 <aside> 包裹与当前内容无关的推广链接——这些都会让爬虫误判权重流向或直接忽略区块。
立即学习“前端免费学习笔记（深入）”；
-
<nav>只应包含主导航、面包屑，不含“猜你喜欢”“相关推荐” -
<aside>必须和<main>内容存在语义关联（如文章侧边的作者简介、术语解释），空的或只含广告的<aside>是低质信号 -
<figure>必须配<figcaption>，否则它只是个普通容器，无法被识别为独立图文单元
真正难的不是写对标签，而是每次增删一个区块时，都得问一句：这个容器在语义上是否可独立存在？它的父/子关系是否和用户认知一致？机器不会容忍“视觉上像树，代码里是平铺”的侥幸。
