z-index失效主因是元素未定位或父级创建层叠上下文；需显式设置position（非static）并检查祖先节点是否触发stacking context（如transform、opacity
z-index 在 Safari、IE 或老版 Chrome 里“失效”，不是写错了，而是层叠上下文边界在不同浏览器中被触发的条件不一致——尤其当父元素带 transform、opacity: 0.99 或没显式设 position 时。
为什么 Safari 里 z-index 总是比 Chrome 低一层
Safari（特别是 iOS/iPadOS WebKit）对创建层叠上下文更敏感：transform: translateZ(0)、will-change: transform、甚至 opacity: 0.99 都会立刻创建新上下文，把子元素的 z-index 锁死在该局部范围内。Chrome 则常容忍这些属性共存而不截断层级。
- 用 Safari 开发者工具 → Elements → Styles 面板右侧看是否有 “Stacking Context” 标识
- 临时注释掉疑似祖先元素的
transform或opacity，观察目标元素是否突然“浮上来” - 别用
translateZ(0)做性能优化——现代 Safari 已默认启用 GPU 合成，它只带来副作用 - 若必须用
will-change，只在动画前动态设置，结束后立刻will-change: auto
IE6–7 的 z-index 默认值是 0，不是 auto
IE6/7 下，只要元素 position 不是 static（哪怕没写 z-index），就等价于 z-index: 0；而其他浏览器中，未声明 z-index 就是 auto，不参与层叠排序。这就导致：一个没设 z-index 的 position: relative 父容器，在 IE6/7 中会“挡住”所有子元素的高 z-index。
- 检查所有定位祖先，尤其是包裹弹窗或下拉框的外层
div，确保它们要么不设position，要么显式设z-index: auto（仅现代浏览器支持）或合理数值 - 兼容旧 IE 时，避免依赖“未设
z-index就透明”的假设；统一给关键容器加明确z-index值 - 不要靠“父容器不写
z-index就不会截断”来设计逻辑——IE6/7 会打破它
如何建立真正可维护的全局 z-index 规范
靠手写 z-index: 9999 或 Tailwind 的 z-50 是临时补丁，不是规范。问题不在数字大小，而在缺乏语义和单点控制。
- 用
:root自定义属性统一管理（推荐）：:root { --z-nav: 100; --z-dropdown: 200; --z-modal-overlay: 1000; --z-modal-content: 1001; --z-tooltip: 1100; }然后组件中写z-index: var(--z-modal-content); - 若需 JS 动态控制（如多层弹窗栈），同步维护单一源对象：
export const Z_INDEX = { nav: 100, dropdown: 200, tooltip: 1100, modal: 1000 } as const;并在 CSS-in-JS 或内联样式中引用Z_INDEX.modal - 禁止在组件内部硬编码数值；所有
z-index必须来自上述常量，否则 CI 可拦截 - 新增组件时，先查现有层级档位：比如下拉菜单不该高于模态框遮罩层，否则会穿透
最易被忽略的致命细节：z-index 生效的前提永远是 position
再完整的常量体系也救不了一个没设 position 的元素。z-index 对 position: static 完全无效，而很多 UI 框架组件（如某些 Dialog 内部节点）默认不设定位，只靠外层容器撑开结构。
- 用 DevTools 的 Computed 面板搜
z-index，如果显示auto且旁边没有定位标识，说明它根本没进层叠流程 - 对关键覆盖元素（如 Tooltip、DropdownPanel），手动加
position: relative或position: absolute，哪怕只是占位 - 注意
position: sticky的特殊性：它只在粘性生效区域内参与层叠，滚动出范围后行为退回到文档流顺序
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
