z-index必须配合position属性（relative/absolute/fixed/sticky）才生效；若元素为static定位则z-index被完全忽略，且父级触发层叠上下文（如opacity
z-index 值必须配合定位属性才生效
直接给元素写 z-index: 1000 却没效果？大概率是因为它没设置 position。z-index 只对 position 为 relative、absolute、fixed 或 sticky 的元素起作用。静态定位（position: static，即默认值）下 z-index 完全被忽略。
预览浮层和编辑器控制面板通常都需脱离文档流，推荐统一用 position: fixed 或 position: absolute，再配以明确的 z-index 数值。别依赖父容器“顺带”继承层级——每个需要参与叠放竞争的容器自己得有定位 + z-index。
避免 z-index 值随意堆高导致维护失控
常见做法是把浮层设成 z-index: 9999，控制面板设成 z-index: 9998……这种写法短期有效，长期会崩：新组件一加，又得翻出所有 z-index 值重排，极易冲突或覆盖失败。
建议按功能域分层建模：
-
z-index: 10—— 编辑器基础 UI（工具栏、侧边栏） -
z-index: 20—— 模态对话框（如设置弹窗） -
z-index: 30—— 预览浮层（含缩放、拖拽、关闭按钮） -
z-index: 40—— 全局提示/Toast（需压过一切）
数值留足间隙（比如每层差 10），方便后续插入中间层级。别用 100、101 这种紧挨着的值。
注意 stacking context 对 z-index 的截断效应
如果预览浮层嵌在某个设置了 transform、opacity: 0.99、filter 或 will-change 的父容器里，该父容器就创建了新的 stacking context——此时浮层的 z-index 只在该上下文内有效，无法越过父级去和外部控制面板比高低。
典型踩坑场景：
- 编辑器容器用了
transform: translateZ(0)做硬件加速 → 意外创建 stacking context - 预览浮层被包裹在
div里，而这个div有opacity: 0.999→ 浮层再高的z-index也盖不过同级的控制面板
排查方法：打开浏览器开发者工具，选中浮层元素，看“Computed”面板里 z-index 是否显示为 “auto”，同时检查其最近的 stacking context 父节点是谁。必要时把浮层移出有副作用的父容器，挂到 body 下。
编辑器控制面板与预览浮层的 DOM 插入顺序仍有影响
即使两者都有正确的 position 和 z-index，若它们属于同一 stacking context，DOM 后出现的元素仍会默认压在前面元素之上（前提是 z-index 相同）。所以不要假设“只要 z-index 大就一定在上”。
实操建议：
- 确保预览浮层（
z-index: 30）和控制面板（z-index: 10）不在同一个局部 stacking context 内 - 若必须共存于同一父容器，显式指定不同
z-index，且避免相等 - 在 Vue/React 中动态挂载浮层时，用
createPortal或Teleport把它直接塞进body，彻底规避 DOM 顺序干扰
最易被忽略的是 stacking context 的隐式创建——它不报错、不警告，只默默让 z-index 失效。调样式时如果发现“明明写了更高值却盖不住”，第一反应不该是改数字，而是查父级有没有触发 stacking context 的 CSS 属性。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
