display: none彻底移除元素于渲染树，跳过布局与绘制，不占空间、不响应事件；visibility: hidden仅跳过绘制，仍保留布局和事件响应能力。
display 属性本身不直接触发图层提升，但它通过改变元素是否进入渲染树、是否参与布局，间接决定该元素能否被浏览器选为独立合成层。
display: none 为什么完全绕过渲染流程
当设置 display: none，该元素及其子树在构建渲染树（Render Tree）阶段就被剔除，后续的 Layout、Paint、Composite 全部跳过。它不占空间、不响应事件、不参与任何样式计算——不是“隐藏了”，而是“根本没被浏览器当作要显示的东西处理”。
- 常见误用：用
display: none切换菜单后立刻读取offsetHeight，结果得到 0 —— 因为 DOM 节点还在，但渲染树里已经没了，JS 拿不到布局信息 - 对比
visibility: hidden：后者仍保留在渲染树中，会触发 Paint（重绘），但不触发 Layout（回流） - 动画场景慎用：反复切换
display会强制触发整棵子树的重建，比opacity: 0+pointer-events: none开销高得多
display: contents 的合成层陷阱
display: contents 让容器“消失”，只保留子元素在渲染树中的位置，但它不会自动让子元素升层。很多开发者以为这样能减少包裹节点、便于 GPU 加速，实际恰恰相反：
- 子元素失去父级 stacking context，可能意外降层（例如被后面兄弟元素遮盖）
- Chrome 115+ 中，
display: contents容器无法作为will-change: transform的生效载体，子元素需单独加提示 - 若子元素本身没有触发合成的条件（如
transform、opacity、filter），它们仍和文档层混在一起，无法独立绘制
哪些 display 值可能间接促成图层提升
真正影响合成层创建的是「是否形成 stacking context + 是否有合成触发属性」，但某些 display 值是前置门槛：
立即学习“前端免费学习笔记（深入）”；
-
display: block/inline-block/flex/grid：可正常建立 stacking context，配合transform: translateZ(0)或will-change: transform更大概率触发合成 -
display: table-cell或display: list-item：在旧版 Safari 中曾因 stacking context 行为异常导致合成失败，现基本修复，但仍建议避开 -
display: flow-root：虽不直接提升图层，但能隔离内部浮动/清除影响，避免意外 Layout 波动，间接减少不必要的重排重绘
最易被忽略的一点：浏览器对合成层的决策是 lazy 的——即使你写了 will-change: transform，若该元素当前没被标记为 dirty（比如没发生过样式变更），它也不会立刻建新层。display 的变化只是起点，后续是否真分层，取决于有没有紧接着的、能被 GPU 加速的视觉变更。
