visibility: hidden 占空间是因为它仍参与布局计算但跳过渲染像素；display: none 则在布局阶段被剔除，不占空间、不触发 getboundingclientrect()，且两者重排重绘行为、继承性、可访问性处理均不同。
visibility: hidden 为什么还占空间
因为它根本没退出文档流——浏览器照常给它分配盒模型、计算 margin/padding/border、参与 flex/grid 布局，只是把“渲染像素”这一步跳过了。这不是 bug，是设计使然。
display: none 和 visibility: hidden 的底层差异
两者处理阶段不同：display: none 在布局（layout）阶段就被剔除，不生成盒、不占空间、不触发 getBoundingClientRect()；而 visibility: hidden 走完 layout + paint，只是在 paint 阶段把像素全设为透明，所以 getBoundingClientRect() 返回的 width/height/top/left 全都正常。
-
display: none触发 reflow（重排）+ repaint（重绘） -
visibility: hidden只触发 repaint，更轻量 -
visibility: hidden下的input仍能被el.focus()聚焦，但光标不可见 - 父元素设
visibility: hidden，子元素设visibility: visible也无效——继承性强制覆盖
什么时候你其实需要 visibility: hidden
不是“想藏东西”，而是“藏了还得留坑位”。比如：
- 轮播图预加载的下一张图容器，用
visibility: hidden防止宽高塌陷导致布局抖动 - 表单校验提示语临时隐藏，但按钮位置不能上移（
display: none会引发跳动） - Canvas 元素设
visibility: hidden可保持 WebGL 上下文不丢失；display: none可能清空 canvas 内容 - 屏幕阅读器需读取的辅助文本，用
visibility: hidden+aria-hidden="false"，比display: none更可控
容易踩的坑和替代方案
别写 visibility: false 或 visibility: off——浏览器直接忽略，回退到 visible；也别指望 transition: visibility 0.3s 能动画，它不支持过渡。
- 要渐隐渐显：用
opacity: 0+pointer-events: none，再配合transition: opacity - 要完全裁掉又保留 DOM 和可访问性：
clip-path: inset(100%)，支持 transition 且不影响焦点和语义 - 要“仅对屏幕阅读器可见”：用
position: absolute; left: -9999px+overflow: hidden父容器 - 浮动元素父容器高度塌陷？不是
visibility的问题，是没触发 BFC，加overflow: hidden或display: flow-root
真正卡住人的，从来不是属性怎么写，而是没想清楚：你要删的是视觉、是空间、是交互，还是语义——漏掉任意一环，后面 debug 就得绕一圈。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
