首先要纠正一个常见的理解误区：不少人以为 CSS 过渡（transition）在 display: none 和 display: block 之间切换时，是“卡住了”或者“动画没执行好”——实际上，浏览器根本没有机会运行这段过渡。当你在样式表里写下 transition: display 0.3s 时，渲染引擎在解析阶段就直接丢弃了这条规则。即使你去 DevTools 的“Computed”面板仔细查找，也找不到它的任何痕迹。
背后的原理其实很直白：display 是一个离散（discrete）属性——它只有几个固定的取值（none、block、flex 等），这些取值之间没有数值关联，浏览器无法进行插值计算。更要命的是，一旦元素被设为 display: none，它就会彻底脱离渲染树。脱离渲染树之后，别说 display 自身的过渡，就连 opacity、transform 这些本可以正常过渡的属性，也会因为元素“不存在”而完全失效。
display 为什么无法参与 transition
这个问题的核心在于 display 没有中间状态。浏览器需要知道过渡过程中“从 A 到 B 的每一帧长什么样”，但 display 只有“显示”和“隐藏”两种极端状态，不存在 50% 的 display: half-block。因此，规则直接被丢弃。
几个典型场景可以帮助理解：
- 即便写上
transition: all 0.3s也没用——只要涉及 display 切换，整个过渡链就会断裂 - 用 JS 同步设置
el.style.display = 'block'后立即加上el.classList.add('fade-in')，浏览器会把这两步合并到同一帧重绘，导致起始帧丢失，动画完全不可见 - 父元素设为
display: none后，子元素即使写了transition: opacity 0.3s也完全不会触发，因为父容器已经不在渲染树里了
正确的方案：opacity + visibility 协同控制
既然 display 这条路走不通，那么业界标准的思路是使用 opacity 和 visibility 配合控制。但这也不是随便写两个属性就完事了——关键点在于过渡的时机必须错开。如果 visibility 和 opacity 同时切换，就会出现“闪一下”的尴尬效果，或者元素在鼠标悬停时看不见但依然可点击。
正确的做法分步骤来看：
- 初始隐藏态：
opacity: 0+visibility: hidden+pointer-events: none - 过渡声明：
transition: opacity 0.3s ease, visibility 0s 0.3s（visibility 延迟 0.3 秒才生效，正好等 opacity 动画结束） - 显示类中：
opacity: 1+visibility: visible+pointer-events: auto+transition-delay: 0s - 如果动画结束后确实需要释放布局空间（比如下拉菜单折叠后要收回高度），需要监听
transitionend事件，检查event.propertyName === 'opacity'，再执行el.style.display = 'none'并加上aria-hidden="true"
这套方案已成为行业共识，尤其适合折叠面板、弹窗遮罩、工具提示等常见交互场景。
如果非要用 display，JS 强制触发布局的方法
现实中确实会遇到框架约束严格、无法修改 CSS 的情况。这时可以尝试用 JS 强制打断浏览器的批量优化，让它“感知”到元素已经就位。步骤如下：
- 先设
parent.style.display = 'block' - 立即读取一次
parent.offsetHeight（注意必须使用这个属性，不能用getComputedStyle——只有能触发 layout 计算的属性才有效） - 然后再操作子元素的
opacity或transform
但必须提醒：这种方法在滚动过程中高频展开/收起时要谨慎使用，因为每次强制读取 offsetHeight 都会引发重排（reflow），性能代价不低。
容易被忽略的 DOM 生命周期细节
这里想特别强调一组容易被忽视的因素：所有上述方案都依赖元素始终保留在渲染树中。一旦你提前删除了 DOM 节点，或者过早设置了 display: none，过渡就彻底没戏了——不是效果不好，而是根本没启动。
另外还有更隐蔽的陷阱：动画结束后如果没有清理 tabindex 或焦点状态，键盘用户可能会被卡在不可见元素上无法继续导航；如果父容器设置了 overflow: hidden，visibility: hidden 的元素仍然占据布局空间，可能引发滚动条抖动。这些都是实际开发中容易踩的坑，值得多加留意。
