display: none 切换必然触发强制重排，因其跳过样式计算直接剥离渲染树；visibility + opacity 是轻量替代方案，需配合 step-end 避免透明可点击；真要彻底隐藏又不卡顿，应由 JS 层过滤 DOM 而非 CSS 隐藏。
display: none 切换必然触发强制重排
Flex 容器设 display: none 时，整个容器及其所有子元素会立刻从渲染树中被剥离——浏览器连样式计算都跳过，更别说过渡。切换回来时，它必须重新解析 HTML 结构、计算每个子项的 flex-basis、flex-grow、gap、对齐方式，再执行 layout → paint 全流程。这不是“慢”，而是同步阻塞式重排。
常见错误现象包括：getBoundingClientRect() 返回全零、动画帧直接丢失、“啪”一下闪现、滚动中突然卡顿。DevTools 的 “Layout” 面板里能看到单次耗时 >16ms，尤其当 Flex 容器内有输入框、动态列表或嵌套三层以上 flex 时，问题更明显。
- 别指望加
transition: display 0.3s——浏览器直接忽略，不报错也不警告 - 子项数量越多（比如 30+ 卡片），重排代价越接近指数增长
- 如果父容器是
display: flex，其子元素设display: none可能意外失效（因 flex 布局优先级更高），需额外包一层<div>
visibility + opacity 是最轻量的替代方案
用 visibility: hidden 替代 display: none，元素仍在渲染树中，布局盒模型完全保留，只跳过绘制阶段；再配合 opacity: 0 和 transition，就能实现视觉上的淡入淡出。
关键点在于：必须同时控制两个属性，并用 step-end 确保 visibility 在过渡结束瞬间切换，避免中间帧出现“透明但可点击”的状态。
立即学习“前端免费学习笔记（深入）”；
示例 CSS：
.fade-container {
opacity: 0;
visibility: hidden;
transition: opacity 0.3s ease, visibility 0.3s step-end;
}
.fade-container.show {
opacity: 1;
visibility: visible;
}
-
visibility: hidden不触发重排，但依然占文档流空间 - 若需释放空间（比如弹窗收起后不撑开滚动条），必须在
transitionend事件里检查event.propertyName === 'opacity'，再设element.style.display = 'none' - 记得同步更新
aria-hidden="true"和移除tabindex，否则屏幕阅读器或键盘用户会卡在不可见元素上
真要彻底隐藏又不卡顿？得靠 JS 层过滤 DOM
当 Flex 容器承载的是筛选列表、权限按钮组、多步骤表单区域等场景，频繁显隐意味着大量无效布局计算。此时纯 CSS 方案已到瓶颈——visibility 占位、display 卡顿、position: absolute 易受父容器 overflow 干扰。
最优解是：不在 CSS 层“隐藏”，而在 JS 层“不渲染”。即根据状态过滤数据源，只把当前需要的子项写入 DOM。
- 适用于同级兄弟结构（如多个
<section class="step">），且所有步骤初始就存在于 DOM 中 - 利用
hidden属性（element.hidden = true）可提速，它不触发重排，保留焦点和输入值 - 避免用
innerHTML替换内容——会丢焦点、清输入值；而display切换虽卡顿，却能保留状态，这是它被沿用的唯一合理原因
容易被忽略的 DOM 卸载时机问题
即使你用 visibility + opacity 实现了淡出动画，只要没在 transitionend 回调里判断 event.propertyName 并补上 display: none，那个元素就一直挂在 DOM 里：占文档流、拖慢后续重排、干扰可访问性 API、甚至让 document.querySelectorAll 返回意外结果。
真正难处理的不是动画本身，而是“动画完成”和“DOM 状态清理”之间的毫秒级错位。一次漏掉，就可能引发连锁布局抖动或焦点陷阱。
