HTML结构优化需平衡语义性与性能：必须使用header、nav、main、footer等具隐式ARIA role的标签；section/article须配标题才具语义价值；嵌套宜≤3层且单容器子元素≤50个；避免深层CSS选择器与位置依赖型JS查询，优先用语义类名和data属性解耦。
HTML结构设计不能只图语义清晰，也不能只追DOM节点最少——真正在意首屏速度和可维护性的项目，得在两者之间卡准那个临界点：语义足够让辅助技术与搜索引擎理解，嵌套又浅到不拖慢解析和CSS选择器匹配。
语义化标签用到什么程度才算“够”
不是所有 <section> 都必要，也不是所有容器都该塞进 <div>。关键看是否带来实际收益：
- 用
<header>、<nav>、<main>、<footer>是必须的——它们有明确的隐式 ARIA role，浏览器和读屏软件直接识别，不用额外加role -
<section>和<article>要配合标题（<h2>及以上）出现才有语义价值；单独一个没标题的<section>和<div>在可访问性上没区别 -
<aside>不等于“侧边栏”，而是指与当前内容相关但可独立存在的信息（如引用、注释、广告），滥用会导致逻辑混乱 - 避免嵌套
<section>→<section>→<section>：三层语义区块已接近人类认知上限，再深就该拆页或换交互形式
嵌套层级怎么控制在“不影响解析”的范围内
浏览器解析 HTML 是单线程流式处理，每多一层嵌套，就多一次 DOM 节点创建 + 样式计算开销。重点不是“不能超三层”，而是“别让某一块 DOM 成为性能黑洞”：
- 检查
document.querySelectorAll('div div div div')这类选择器是否高频出现——如果 CSS 里大量依赖深层嵌套，说明结构本身就在制造维护成本 - 动态插入内容时，优先用
DocumentFragment批量挂载，而不是逐个appendChild：哪怕只多两层嵌套，100 个子节点逐个 append 会触发 100 次重排 - 用开发者工具的 Layers 面板看是否有意外的“合成层爆炸”——某些看似扁平的结构，因
transform或will-change被强制分层，反而更耗资源 - 移动端尤其注意：iOS Safari 对超过 5 层嵌套的 flex 容器渲染效率明显下降，不是理论值，是实测帧率跌落点
DOM 节点数量与首屏渲染的实际关系
节点数不是越少越好，而是要避开“高密度低价值”区域。一个含 200 个 <li> 的菜单列表，比 20 个精心组织的 <section> 更伤性能：
立即学习“前端免费学习笔记（深入）”；
- 单个父容器下子元素建议 ≤ 50 个：超出后，Chrome 的样式计算时间呈非线性增长，尤其当这些子元素还带 inline style 或 JS 绑定事件
- 表格类结构慎用
<table>渲染万级数据——<table>的 layout 算法是 O(n²) 级别，哪怕加了table-layout: fixed，首行解析仍需遍历全部<col> - 用
<template>预编译结构比用字符串拼接快 3–5 倍，且不会触发中间态解析；但注意它不参与渲染树，得手动content.cloneNode(true) - 服务端渲染（SSR）时，
<script type="application/json">内联数据比重复生成 50 个<meta>更轻量——后者每个都会被 HTML 解析器当成新节点处理
HTML 结构改动如何不牵连 CSS 和 JS
结构一动，样式和逻辑常跟着崩，根本原因在于选择器和 DOM 查询过度绑定具体标签形态：
- CSS 中避免写
main > section > div > p这种路径式选择器，改用语义类名如.article-body或 BEM 命名，结构变而样式稳 - JS 中少用
parentElement.children[2]这类位置依赖型访问，优先用querySelector('[data-role="primary-cta"]')或closest()向上找锚点 - 组件化项目里，把结构约束下沉到模板层（如 Lit、HTM），HTML 文件只保留骨架，避免业务逻辑和结构耦合
- 上线前跑一次
grep -r "querySelector.*section" src/—— 如果结果里混着大量硬编码结构路径，说明这个页面已经不适合再做结构性优化了
真正难的不是选对标签，而是每次增删一个 <div> 时，能预判它会在哪类设备上拖慢哪段 JS 执行，或者让哪个屏幕阅读器用户多绕三次焦点。结构设计的终点，是让 HTML 既不显眼，又无处不在地起作用。
