HTML层级应以布局意图为导向，明确每个容器的CSS模式（flex/grid）、尺寸控制和响应式职责，避免无意义嵌套导致样式冲突与计算冗余。
HTML层级不是越深越好，而是要让每个父容器有明确的布局意图——它该用什么CSS模式（flex还是grid）、是否需要独立的尺寸控制、是否承担响应式断点切换。层级混乱直接导致样式冲突、margin塌陷、align-items失效。
用语义标签天然划分布局边界
浏览器对header、nav、main、section、aside、footer默认赋予块级行为，但更重要的是：它们自带逻辑边界。一个section内部适合用flex排卡片，它的父main则更适合用grid划分“主内容+侧边栏”区域。
- 避免把所有内容塞进一个
div class="container"再靠CSS硬掰——这会让grid-template-areas命名失去语义锚点 -
aside必须是main的兄弟，而非子元素；否则grid中无法与main同级并列 -
nav内用ul包裹链接，不是为了“列表语义”，而是因为ul天然提供display: block+ 垂直流，方便后续设display: flex横向排列
扁平化嵌套，只在需要布局干预时加容器
每多一层div，就多一层盒模型计算、多一次box-sizing继承风险、多一个可能被overflow: hidden意外裁剪的节点。现代布局不需要“为了结构而结构”。
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
- 如果只是给几个按钮加统一
gap和居中，直接对nav设display: flex，别额外包div class="nav-wrapper" - 需要响应式换列？用
flex-wrap: wrap或grid-template-columns: repeat(auto-fit, minmax(300px, 1fr))，而不是写两套div结构来回切换display - 绝对定位元素（如弹窗）应挂载到
body下，而非某个深层section里——否则position: fixed会被父级transform或overflow截断
为CSS布局模式预留“容器职责”
HTML层级的本质，是提前声明“谁负责哪段空间分配”。一个容器是否该设display: grid，取决于它下面是否有多个逻辑区域需二维控制；是否该设display: flex，取决于子元素是否需单向弹性对齐。
立即学习“前端免费学习笔记（深入）”；
-
main设display: grid+grid-template-areas，是因为它要统筹header/sidebar/content三者关系；但sidebar内部用display: flex就够了，它只管列表项垂直堆叠 - 不要在
grid容器里再套一个flex容器来“微调”某一行——改用grid-auto-rows或align-content - 当某层
div只为了加padding或background，且不参与任何布局控制，它就不该存在；用伪元素::before或直接写在语义标签上更干净
真正容易被忽略的，是“容器是否真的需要有自己的尺寸上下文”。比如section设了width: 80%，又在里面用grid，那fr单位就基于这个缩窄后的宽度计算——但如果你本意是让它占满视口减去左右margin，就应该去掉width，改用max-width + margin: 0 auto。层级设计最终服务于这个判断：这个盒子，到底是“画布”，还是“画布上的一个图形”？
