visibility: hidden 是标准解法，仅隐藏元素但保留布局空间，不触发重排、不影响无障碍访问；而 display: none 会移出文档流、清空 canvas 上下文、破坏 JS 尺寸检测且屏幕阅读器默认跳过。
直接用 visibility: hidden 就行，这是标准解法，不是权宜之计。
为什么不能用 display: none 替代
它会让元素彻底退出文档流，后续元素立刻上移——页面“抖一下”，布局跳变。轮播图预加载项、表单错误提示、canvas 容器一旦误用 display: none，轻则 UI 闪动，重则 canvas 上下文被清空、动画中断。
display: none 触发重排（reflow）+ 重绘（repaint），开销大；getBoundingClientRect() 返回全 0，offsetHeight 为 0，JS 检测逻辑容易崩；屏幕阅读器默认跳过，无障碍支持弱（除非补 aria-hidden="false"）。
visibility: hidden 的行为边界在哪
它只让元素“不画出来”，但盒模型照常计算：宽高、margin、padding、伪元素都参与布局，offsetParent 仍有效，getClientRects() 返回真实尺寸。
立即学习“前端免费学习笔记（深入）”；
- 子元素默认继承
visibility: hidden；想单独显示某个子元素，必须显式写visibility: visible - 父级设了
visibility: hidden，子元素再设visibility: visible也无效——这是强制继承，不是层叠覆盖 - 它不创建新的层叠上下文，
z-index行为不受干扰（这点比opacity: 0更干净） - 不支持
transition: visibility动画——浏览器忽略该声明，需搭配opacity或transform实现渐变
交互和可访问性怎么处理
visibility: hidden 下的 <input> 仍能被 focus() 调用，document.querySelectorAll('input') 会包含它，键盘 Tab 键也能聚焦——这对表单控件可能是 bug，不是特性。
- 禁用鼠标交互：加
pointer-events: none - 屏蔽屏幕阅读器：加
aria-hidden="true"（注意别和display: none混用） - 若需完全移出可访问性树，
display: none+aria-hidden="true"是更稳妥组合 -
canvas/video元素在visibility: hidden下可能持续解码，CPU 占用偏高，需监控
真正容易被忽略的是继承链和事件穿透
一个 visibility: hidden 的父容器里，哪怕子元素写了 visibility: visible，只要中间某层祖先也设了 hidden，它就永远看不见——这不是样式没生效，是渲染引擎的强制继承规则。
