display:none会触发重排，频繁切换导致卡顿；应优先用opacity:0+visibility:hidden组合替代，或用class控制、content-visibility优化，兼顾性能与可访问性。
display: none 触发重排，频繁切换会卡顿
只要元素从渲染树中被移除或重新插入，浏览器就必须计算整个受影响区域的几何信息，这就是 reflow。用 display: none 切换显隐时，每次设置都会触发它——哪怕只是临时隐藏一个按钮再显示，也可能拖慢动画帧率。
常见错误是把 display: none 用在轮播图、下拉菜单、Tab 面板这类高频交互区域。用户快速点击时，页面可能出现肉眼可见的“卡一下”。
- 能用
opacity: 0+visibility: hidden组合替代的，就别单用display: none - 如果必须用 JS 控制，优先改 class（比如
is-hidden），而不是直接操作element.style.display，避免覆盖媒体查询规则 - 长列表折叠场景可考虑
content-visibility: hidden（Chrome 85+），它跳过布局和绘制，比display: none更轻量
visibility: hidden 不释放空间，但子元素能“钻出来”
visibility: hidden 看似温和，实际埋着两个典型坑：一是父元素隐藏后，子元素设 visibility: visible 仍能显示；二是它不阻止 tab 键聚焦，键盘用户可能“掉进黑洞”。
比如表单校验失败后想临时屏蔽某个 <input>，若只加 visibility: hidden，用户按 Tab 还会停在那里，光标消失但屏幕阅读器仍在读——这违反 WCAG 2.1。
立即学习“前端免费学习笔记（深入）”；
- 禁用交互必须配对：
visibility: hidden+pointer-events: none+tabindex="-1" - 不要指望它“真隐藏”：它仍参与表单提交，
form.elements里照常存在 - 动画过渡可用，但只对
visible → hidden有延迟生效效果；反向切换不触发 transition
hidden 属性语义干净，但 CSS 能轻易覆盖它
hidden 是 HTML5 原生布尔属性，语义明确、写法简洁，且默认对屏幕阅读器不可见。但它不是 CSS 的“免死金牌”——一条 [hidden] { display: block; } 就能让它彻底失效。
尤其在大型项目中，第三方 UI 库或全局 reset.css 里常带这类通配规则，导致 <div hidden></div> 突然又冒出来。
- 用前先检查 DevTools 的 Computed 样式，确认
display确实是none - Vue/React 中绑定
hidden={condition}是安全的；Svelte 则需配合 class 和 CSS 规则，不能直传布尔值 - 服务端渲染（SSR）场景下，
hidden比 JS 控制更可靠，能避免 FOUC（内容闪现）
opacity: 0 不是隐藏，是“透明但活着”
opacity: 0 最常被误当作隐藏手段。它只改变像素透明度，DOM 节点、事件监听、焦点能力、布局占位全都在。用户看不见，但鼠标悬停、点击、Tab 导航照常进行。
典型翻车：轮播图淡出旧图时没关 pointer-events，用户手快连点两下，触发两次回调；或者图标按钮里用 opacity: 0 隐藏文字，结果键盘用户 tab 过去却卡住。
- 真正要“视觉不可见 + 交互隔离”，必须三件套：
opacity: 0+pointer-events: none+tabindex="-1" - 搭配
transition: opacity 0.3s流畅，且只触发 repaint，不影响布局性能 - SEO 和屏幕阅读器仍可能读取内容，如需辅助技术也忽略，得额外加
aria-hidden="true"
display: none 最彻底但最重，visibility: hidden 留位但易出 accessibility 漏洞，opacity: 0 动画友好却默认“假死”，而 hidden 属性看着省事，实际依赖 CSS 环境是否干净。选哪个，得看你在乎的是布局稳定性、动画流畅度、键盘导航路径，还是 SSR 下的首屏一致性。 
