display: none切换会触发重排重绘，因其彻底移除元素出渲染树，浏览器需重新计算布局、尺寸与层级；而visibility: hidden仅跳过绘制，保留盒模型，只触发重绘。
为什么 display: none 切换会触发重排重绘
直接用 display: none 和 display: block 控制元素显隐，看似简单，但每次切换都会让浏览器丢弃该元素的布局信息，重新计算位置、尺寸、层级——这不只是“画一遍”，而是从 layout → paint 全流程重来。尤其在列表项、弹窗、折叠面板中频繁切换时，卡顿感明显。
常见错误现象：transition 对 display 无效；getBoundingClientRect() 在 display: none 后返回全零；动画中间帧掉帧。
- 根本原因：
display是 layout 级别属性，浏览器无法对其做增量更新 - 替代思路：保持元素在文档流中占位，只控制视觉可见性与交互可达性
- 优先级顺序建议：
visibility: hidden+pointer-events: none>opacity: 0>display: none
用 visibility + pointer-events 替代 display 的实操细节
visibility: hidden 不触发重排，元素仍占据空间，DOM 结构和布局树完全保留。配合 pointer-events: none 可屏蔽鼠标事件，避免误触——这是最轻量、兼容性最好的“伪隐藏”方案。
使用场景：下拉菜单收起状态、Tab 面板未激活页、表单校验提示暂存区。
立即学习“前端免费学习笔记（深入）”；
- 注意
visibility会继承，子元素需显式设为visible（除非你真想一并隐藏） -
pointer-events: none不影响focus或键盘导航，如需完全禁用交互，得加tabindex="-1"和aria-hidden="true" - 若需动画过渡，
visibility本身不可过渡，但可搭配opacity或transform实现淡入/缩放效果
什么时候必须用 display: none？怎么最小化代价
并非所有场景都能绕开 display: none。比如：服务端渲染首屏无需的模块、权限过滤后彻底移除的按钮、异步加载前的占位容器——这些需要真实脱离布局流，避免空隙或样式干扰。
关键不是“不用”，而是“延迟用”和“精准用”：
- 避免在 scroll / resize / input 事件中动态切换
display，改用节流或 requestIdleCallback 延后执行 - 批量操作时，先用
documentFragment组装 DOM，再一次性插入，减少触发次数 - 对长列表，用虚拟滚动（如
react-window）代替全量display切换，把隐藏逻辑下沉到渲染层
hidden 属性和 aria-hidden 的分工误区
hidden 是 HTML5 原生布尔属性，等效于 display: none，同样触发重排。它不是性能优化手段，而是语义化辅助工具，用于表达“当前不应被任何用户看到”。
而 aria-hidden="true" 仅影响无障碍读屏器，对渲染毫无影响——它不隐藏，也不释放空间，纯粹是告诉 AT（辅助技术）跳过该节点。
- 错误写法：
<div hidden aria-hidden="true">—— 重复且矛盾，hidden已隐含aria-hidden="true" - 正确组合：
<div style="visibility: hidden; pointer-events: none;" aria-hidden="true">—— 视觉隐藏 + 交互屏蔽 + 无障碍隔离 - JS 控制时，优先操作
element.hidden = true（比 class 切换更语义），但要知道它背后仍是display: none
真正影响流畅度的，从来不是“要不要隐藏”，而是“以什么代价隐藏”。结构上保布局、CSS 上选非 layout 属性、JS 上控触发时机——三者缺一不可。最容易被忽略的是：父容器的 overflow 或 transform 层叠上下文，可能让本该 cheap 的 visibility 变成强制重绘的诱因。
