main不能嵌套header，因其语义是页面唯一主内容区，嵌套会误导浏览器和读屏器视为独立文档，导致导航混乱与SEO权重分散；正确做法是全局header置于main外层。

HTML网页区域划分不是靠“画框”或“切图”，而是用语义化标签明确内容层级和功能边界。划错区域，CSS再精细也救不回可访问性、SEO和维护性问题。

为什么

里不能嵌套

常见错误现象：main内部出现header+h1+内容，结果屏幕阅读器把h1识别为子页面标题，主页面标题被忽略；搜索引擎索引权重分散，首页排名下降。

原因很简单：main代表整个页面唯一的主体内容区，它本身不带“头尾”结构。嵌套header等于告诉浏览器：“这段主内容自己还有个独立页眉”——逻辑矛盾。

• 正确结构：全局header必须在main外层，main内部直接用h1或section+h2表达内容层级
• 唯一例外：只有当section或article是完整可独立分发的单元（如一篇博客正文），才允许其内部含局部header
• 检查方法：Chrome开发者工具 → Elements → 右键main → “Accessibility”面板，确认它被识别为landmark且无嵌套冲突

用

但没加标题会怎样

W3C明确要求每个section必须有h2–h6标题，否则它就退化为普通div——辅助技术无法识别其结构意图，SEO也不给额外权重。

使用场景举例：产品页拆成「功能亮点」「技术参数」「用户评价」三块，第二块漏了h3，屏幕阅读器就会把「技术参数」内容接续在「功能亮点」末尾朗读，中间无停顿、无上下文提示。

• 性能影响：无直接渲染损耗，但可访问性 API 调用失败率上升，axe等合规检测工具会报landmark-no-label错误
• 替代方案：若真无合适标题，可用div+aria-labelledby指向附近可见文本，但不如原生标题可靠
• 注意：article同样强制要求标题；aside和nav则不要求（因其语义已明确）

Flex 与 Grid 在区域划分中的实际分工

别一上来就用grid-template-areas——写起来直观，但维护性极差：改一个区域名，所有相关项都要同步更新；而且无法动态插入新区域。

DeepBI DHTML 页面生成器

生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur

下载

真正该按场景选：

• 做整体骨架划分（header/nav/main/aside/footer）→ 用 Flex：单轴流式控制更稳定，兼容性好，DOM顺序即阅读顺序
• 做内部复杂网格（比如卡片列表、九宫格、响应式表单）→ 用 Grid：二维定位精准，fr、minmax()、auto-fill对响应式支持天然友好
• 注意：Grid 容器内若有注释或空格换行，会被当作文本节点计入子项，导致main和aside实际排在第2、3位，宽度计算异常。安全写法是确保它们是容器的直接子元素，中间不用换行，用替代

兼容老浏览器时，语义标签怎么降级

IE8及以下不识别header、main、aside等HTML5标签，但降级不是简单换成div就完事。

关键点在于保留语义意图：

• 用div替代时，必须加role属性，例如
  对应header，

  对应main
• 同时配合aria-label或aria-labelledby显式标注区域用途，否则读屏器仍无法理解
• 不要混用：比如
  ——双重声明反而造成语义冲突

  最易被忽略的是：区域划分一旦定型，后续所有CSS、JS、无障碍测试都基于这个结构。改结构=重测全链路，所以一开始就把main放对位置、每个section配齐标题，比后期补丁省十倍力气。