flex布局本身不解决html嵌套冗余，反而掩盖结构问题；5层嵌套会导致首屏延迟30–60ms、可访问性下降、js查询变慢，应优先删减无语义wrapper，启用fragment、改用语义化标签，并慎用display: contents。
现代弹性盒布局（flex）本身不解决HTML结构臃肿问题，反而容易掩盖嵌套冗余——你给一个五层 <div> 套娃容器加 <code>display: flex，它照样跑，但首屏渲染慢、可访问性差、JS查询慢，这不是布局问题，是结构病。
为什么 flex 容器里还套着三层 <div>？
<p>常见于组件库封装、模板引擎默认输出或“为了 class 命名整齐”硬加 wrapper。比如 Vue 单文件组件中未启用 <code>fragment，每个组件强制返回一个根节点；React 17+ 虽支持 fragment，但开发者仍习惯写 <div classname="wrapper"> 包住所有内容。
<ul><li>浏览器每解析一层 <code><div>，就要创建 DOM 节点、计算样式、参与布局重排——5 层嵌套比 2 层多出约 30–60ms 首屏延迟（实测低端安卓机）
<li>
<code>display: flex 只作用于直接子元素，父级多余包裹不提供任何布局能力，纯属负收益
<div> 当作语义节点遍历，导致导航效率下降
<h3>用 <code>display: contents 替代 wrapper 的真实代价
它能让父容器“消失”在盒模型中，子元素直接成为 flex 项目，看似完美。但它不是银弹：
- IE 完全不支持，
display: contents在 Edge 16+ 才可用，若需兼容旧企业系统，必须 fallback - 该元素从可访问性树中被移除——如果 wrapper 上有
role="group"或aria-labelledby，这些语义会丢失 - 某些 CSS 属性（如
border、padding、background）失效，不能靠它“透传”样式 - 调试时 DevTools 中看不到该节点，排查布局错位更困难
真正减少 DOM 节点的实操路径
别只盯着 CSS，先动 HTML 结构：
- Vue 项目开启
compilerOptions.fragmen（v3.4+ 默认启用），在.vue文件中直接写多个根节点，避免无意义<div> <li>React 组件返回 <code>或<fragment></fragment>，尤其在列表项、表单项等高频复用场景 - 把
<div class="btn-group"> 换成语义化 <code><div role="group" aria-label="操作按钮组">，既精简又提升可访问性 <li>检查构建产物 HTML：用 Lighthouse “DOM size” 审计项，单页 DOM 节点超 1500 个就该介入；重点看 class 名含 <code>__wrapper、inner、container的节点是否真有必要 - 禁用开发期自动注入的 debug wrapper——比如某些 UI 库的
dev-only边框装饰层，上线前务必剔除
flex 和 grid 不是万能解药，但能暴露结构问题
当你发现“非得套三层 <div> 才能让 flex 对齐生效”，大概率是设计没对齐，而不是技术限制：
<ul><li>用 <code>justify-content: space-between 实现两端对齐，就别再用一个空 <div> 占位
<li>垂直居中不用 <code><div class="flex-center"><div class="inner">…</div></div>，直接在父级设 display: flex; align-items: center; justify-content: center;
display: grid，让 <article></article> 直接成为 grid item，跳过所有 col / row wrapper最易被忽略的点：性能优化不是“加功能”，而是持续删减——删掉一个没被 JS 查询的 id，删掉一个仅用于撑开 margin 的 <div>，删掉一个只为满足 BEM 命名而存在的 wrapper，比加十个 <code>flex 属性更有效。
