invisible 不是真正隐藏占位，因它仅设 visibility: hidden，元素仍占布局空间、响应事件且屏幕阅读器可读；需配合 pointer-events-none 和 aria-hidden="true" 才能禁交互并隐藏语义。
为什么 invisible 不是真正的“隐藏占位”？
它只是把元素视觉上变透明，但依然占据文档流空间——这点常被误当成 hidden 或 display: none 的替代方案。实际项目里，用错会导致布局错位、点击穿透、无障碍阅读异常。
-
invisible对应的是visibility: hidden，不是display: none - 元素仍响应事件（比如
click、focus），除非额外加pointer-events: none - 屏幕阅读器默认仍会读取内容，需配合
aria-hidden="true"控制
什么场景下该用 invisible 而不是 hidden？
核心判断标准：是否需要保留占位 + 同时禁用交互 + 保持语义可访问性。
- 加载中占位：按钮点击后变
invisible，但保持尺寸防止布局抖动 - 过渡动画中间态：比如
opacity-0→opacity-100过程中，用invisible避免回流 - 条件渲染前的“预留槽位”：服务端返回数据前，先用
invisible占住位置，避免骨架屏跳动
invisible 和 opacity-0 有什么关键区别？
两者都“看不见”，但底层机制和副作用完全不同。
-
invisible：设置visibility: hidden，不触发重绘（paint），但参与布局计算（layout） -
opacity-0：设置opacity: 0，仍触发重绘，且可能被硬件加速（尤其在动画中） - 性能敏感场景（如列表滚动）优先选
invisible；需要 CSS 动画连贯性时选opacity-0 -
opacity-0元素仍可接收 pointer 事件，invisible默认不可，但两者都需手动处理焦点逻辑
容易忽略的兼容性和组合陷阱
Tailwind 默认的 invisible 是安全的，但和某些工具类混用时会出问题。
立即学习“前端免费学习笔记（深入）”；
- 不要和
absolute/fixed同时用：invisible在脱离文档流后失去“占位”意义 - 慎用
invisible+transition：Visibility 不支持 CSS 过渡，会直接跳变 - SSR 场景下，如果服务端渲染了
invisible，客户端 hydrate 时可能因状态不同导致闪烁 - 若需“隐藏但保留占位 + 禁用交互 + 屏幕阅读器忽略”，得写成：
invisible pointer-events-none aria-hidden="true"
真正难的不是加个 class，而是每次加之前想清楚：这个元素要不要参与 tab 键导航？会不会被爬虫或读屏软件误读？有没有动画衔接需求？这些细节一漏，就从“快速实现”变成“快速翻车”。
