visibility: hidden 是最直接、最可靠的隐藏方案，它让元素视觉消失但保留盒模型、文档流位置和尺寸计算，不触发重排，且子元素可设 visible 单独显示。
visibility: hidden 是最直接、最可靠的方案，它让元素视觉消失，但盒模型、文档流位置、尺寸计算（如 getBoundingClientRect()）全部保留，不会触发重排。
为什么 visibility: hidden 能占位而 display: none 不能
浏览器对 visibility: hidden 的处理是“绘制阶段跳过”，但布局（layout）和尺寸计算照常进行；display: none 则在渲染树构建阶段就剔除节点，后续所有流程都不参与。这意味着：
-
offsetHeight、scrollHeight、margin等属性在visibility: hidden下仍返回有效值 - 父容器高度不会塌缩，周围元素位置完全不动
- JS 动态切换时无 layout thrashing，适合高频 toggle 场景
- 子元素可设
visibility: visible单独显示——这点display: none做不到
visibility 的三个取值实际表现差异
visible 和 hidden 行为明确，但 collapse 容易误用：
-
visible：默认值，正常渲染 -
hidden：隐藏 + 占位，适用于任意元素 -
collapse：仅对<tr>、<code><col>、<tbody> 等表格相关元素生效，隐藏且不占空间；用在 <code><div> 上等同于 <code>hidden，毫无优势别为了“听起来更专业”写
visibility: collapse—— 对非表格元素纯属冗余。容易被忽略的交互与无障碍问题
visibility: hidden不等于“不可交互”，也不等于“对辅助技术不可见”：- 元素仍响应
click、focus事件（除非加pointer-events: none） - 屏幕阅读器默认仍会读取内容，需手动加
aria-hidden="true" - 若用 JS 控制，推荐直接操作
el.style.visibility，避免依赖 class 切换带来的 CSS 优先级干扰 - 过渡动画只对
visible → hidden生效（比如配合transition: visibility 0.1s），反向切换无过渡——这不是 bug，是规范行为
真正麻烦的不是怎么写这行 CSS，而是记住：占位 ≠ 隔离，隐形 ≠ 无感。交互控制和无障碍支持必须显式补全，否则上线后用户点不到、读不出、测不出来，问题才刚开始。
- 元素仍响应
