HTML后台管理系统布局必须基于语义化标签header/nav/main/aside/footer分层，而非div堆叠；main唯一且不可嵌套，nav需aria-label，aside须与main内容逻辑关联，section/article按功能封装并配h2标题，Grid区域按功能命名（如topbar/content），禁用iframe而用section+inert控制模块显隐。
HTML管理系统布局的分层不是靠视觉堆叠，而是靠语义职责与 DOM 层级协同决定的。直接用 div 套 div 写出“看起来像后台”的结构，后续改权限、加无障碍支持、做 SSR 渲染时会反复返工。
header/nav/main/aside/footer 是强制分层依据，不是可选装饰
这五个标签不是“为了语义而语义”，它们在浏览器中已绑定默认 ARIA role 和隐式大纲行为：
-
header必须只包裹全局性内容（Logo、系统名、用户头像），不能塞搜索框或操作按钮——这些属于nav或独立工具栏 -
nav只能放导航链接，aria-label="主菜单"是必须属性，否则屏幕阅读器无法识别其用途 -
main必须且只能出现一次，且不能嵌套在article或section里；它代表整个页面唯一的内容主干 -
aside不是“右边那块空白”，它必须和main中当前内容存在逻辑关联（如“本页相关文档”“当前订单的物流追踪”） -
footer里放button或表单会破坏语义流，应移至main或独立模块
功能模块必须用 section 或 article 封装，不能只靠 class
后台里一个“用户列表 + 搜索栏 + 分页控件”组合，如果只用 <div class="user-table-section"> 包裹，等于放弃结构可读性：
<ul>
<li>用 <code>section：当该模块无法脱离当前页面独立存在（如“权限配置子表单”）
article：当该模块可被单独引用、RSS 抓取或分享（如“操作日志条目”“通知卡片”）section 或 article 必须有明确标题（h2 起始），且不能跳级（h2 后不能直接 h4）main > section > article > section 已超限，应考虑拆为平行模块或用 JS 动态加载Grid 区域命名必须映射真实功能，而非视觉位置
写 grid-template-areas: "header header" "nav main" "footer footer" 看似合理，但一旦侧边栏在移动端要上移，整个命名就失效。真正可靠的写法是：
立即学习“前端免费学习笔记（深入）”；
- 按功能而非坐标命名：
grid-template-areas: "topbar" "sidebar" "content" "statusbar" -
topbar对应系统顶部状态栏（含在线人数、消息提醒），不是header的视觉复制品 -
statusbar是底部常驻提示区（如“保存成功”“连接中断”），和footer无任何关系 - 所有区域名必须在 CSS 中显式绑定到元素：
grid-area: topbar，不能依赖顺序或隐式定位
嵌套路由/Tab 页面必须用 main + section 组合，禁用 iframe
后台常见“左侧菜单点击切换右侧内容”，很多人用 iframe 加载不同 HTML，这是性能与可访问性双重灾难：
-
iframe隔离了父页面的焦点管理、键盘导航和样式上下文，Tab 键无法穿透 - 每个
iframe独立加载 JS/CSS，首屏后多次白屏，LCP 指标直线下跌 - 正确做法：外层保留
main，内部用section[aria-hidden="true/false"]控制显隐，配合inert属性禁用非激活模块交互 - 若内容来自不同源，必须用
fetch+innerHTML注入，并手动重绑事件，而非依赖iframe自动执行
最容易被忽略的是：层级不是写完就固定不变的。当某个 section 被抽成 Web Component 或迁移到微前端子应用时，它的 role 和 aria-labelledby 必须随宿主环境动态调整，硬编码的结构会立刻失效。
