main 不能嵌套，因它是页面唯一主导航语义容器，W3C 明确禁止嵌套，否则导致辅助技术跳过、SEO 权重稀释及 Lighthouse 标为严重可访问性缺陷。
为什么嵌套没问题，但嵌套另一个会出问题
因为 main 是页面中**唯一**代表主导航内容的语义容器，W3C 明确规定它不能嵌套使用。浏览器、屏幕阅读器和搜索引擎都依赖这个约束做逻辑判断——嵌套会导致语义坍塌：辅助技术可能跳过内层 main，SEO 权重被稀释，甚至 Lighthouse 检测直接标为「严重可访问性缺陷」。
常见错误场景：
- 把「文章列表页」里的每篇卡片用
<main><article>…</article></main>包裹——应该用article，不是main - 在组件库中定义
<m-card><main>…</main></m-card>——组件外层不该抢夺页面级语义权 - SSR 渲染时动态插入
main标签，没校验父级是否已存在——需在服务端加 guard 判断
Flex 布局里 flex: 1 失效，八成是忘了设 display: flex
现代主结构（header + main + aside + footer 垂直排列）靠 Flex 实现最稳，但 flex: 1 不是魔法：它只在 Flex 容器的直接子元素上生效。很多人写了 .content { flex: 1 } 却没给父级设 display: flex，结果还是块级流式布局。
正确做法：
立即学习“前端免费学习笔记（深入）”；
- 根容器（如
<body>或包裹层）必须设display: flex+flex-direction: column+min-height: 100vh - 侧边栏固定宽？用
flex: 0 0 240px，比width: 240px更可靠（避免 margin/padding 干扰） - 内容区自适应？
flex: 1放在main上，不是放它内部的div - 防撑破：所有 flex 子项加
min-width: 0，否则长 URL 或连续中文不换行会溢出
类名命名冲突时，stylelint 比口头约定管用
团队里争论「用 m-button 还是 btn-primary」本质是没建立机器可执行的边界。靠人记住规则不如让工具在提交前报错。
实操配置要点：
- 在
.stylelintrc中启用selector-class-pattern，正则写死为"^[a-z][a-zA-Z0-9-]*$"，拒绝下划线、大写、数字开头 - 强制 BEM 前缀：
m-表示模块，g-表示全局基础样式（如g-mt-16），禁止出现bigRedBtn这类表现型类名 - 禁用 ID 选择器：
id-selector规则设为never，避免与 JS 的getElementById隐式耦合 - 配合 husky，在
pre-commit钩子里跑stylelint "**/*.css"，不通过就阻断提交
响应式不是加 @media 就完事，而是结构层预留弹性
很多项目到测试阶段才发现移动端侧边栏压不住、卡片高度崩塌，根源不在媒体查询漏写，而在初始 HTML 结构和 CSS 布局没预留收缩空间。
关键动作：
-
main和aside不要用固定width，优先用 Flex 的flex-basis+min-width组合 - 图片容器加
max-width: 100%+height: auto，别信width: 100%能自动等比缩放 - 文字流内容（如
p、ul）避免设min-width，否则小屏会触发横向滚动 -
@media块前空两行，且只改布局属性（flex-direction、display），不动字体大小或颜色——后者交给设计系统变量控制
真正难的不是写多少媒体查询，而是判断哪些结构该在移动断点里退化为单列、哪些交互区域必须保留最小触控尺寸。这些决策得在组件设计阶段定死，而不是等联调时补 !important。
