z-index仅对定位元素生效；必须设置position为relative、absolute、fixed或sticky才起作用，static元素设置z-index无效，且其层级计算基于最近的层叠上下文。
z-index 只对定位元素生效
直接给 div 设置 z-index 却没效果？大概率是因为它没触发定位上下文。z-index 不是万能开关，它只在元素的 position 值为 relative、absolute、fixed 或 sticky 时才起作用。
常见错误：
– 给 position: static（默认值）元素设 z-index → 完全忽略
– 在 Flex 或 Grid 容器中直接给子项设 z-index，但子项没声明 position → 无效
实操建议：
- 先确认目标元素有
position: relative（最常用且不影响布局） - 若只是想微调堆叠顺序，
position: relative+z-index是安全选择 - 避免滥用
position: absolute仅为了用z-index，会脱离文档流
z-index 的层级是相对父容器的 stacking context
z-index 不是全局“层数”，而是相对于最近的 stacking context 计算的。一个元素是否创建 stacking context，取决于它的 position + z-index（非 auto）、opacity（transform、filter 等属性。
典型陷阱：
– 父容器设置了 z-index: 10 且创建了 stacking context
– 子元素设 z-index: 999，仍会被另一个 z-index: 20 的兄弟容器盖住
→ 因为子元素的 999 是在父容器的局部层叠上下文中，无法突破父级边界
实操建议：
- 用浏览器开发者工具的「Layers」面板或勾选「Show stacking order」辅助判断 stacking context 边界
- 若需跨容器控制层级，优先提升共同祖先的
z-index，而非盲目堆高子元素数值 - 慎用
opacity: 0.99或transform: translateZ(0)，它们会意外创建 stacking context
z-index 数值没有固定上限，但别用超大数
z-index 支持任意整数（正、负、0），CSS 规范未限定范围。但实际中用 z-index: 999999 并不比 z-index: 999 更“可靠”——反而暴露架构问题。
常见后果：
– 多个组件库都用 9999，冲突后难调试
– 后续新增弹窗/提示层时被迫用更大数，形成数字膨胀
– 某些旧版 Android WebView 对超大整数解析异常
实操建议：
- 按功能分层约定：比如
modal: 1000、tooltip: 500、header: 100 - 用 CSS 自定义属性统一管理：
--z-modal: 1000，便于全局调整 - 负值有用：比如遮罩层后置（
z-index: -1），但需确保父容器不是overflow: hidden导致裁剪
Flex/Grid 子项的 z-index 行为与文档流一致
在 display: flex 或 display: grid 容器中，子项即使没设置 position，也能直接使用 z-index —— 这是 CSS Box Alignment 规范明确允许的例外行为。
立即学习“前端免费学习笔记（深入）”；
但要注意：
– 该能力依赖于子项是 flex/grid item，不是普通块元素
– 若子项同时设置了 position: absolute，则回归传统定位规则（需显式 position 才认 z-index）
实操建议：
- 纯布局场景下，优先利用 Flex/Grid 的天然
z-index支持，减少冗余position - 避免混用：比如给 grid item 加
position: relative再设z-index，反而可能意外创建 stacking context - 注意浏览器兼容性：IE10/11 对 flex item 的
z-index支持不完整，需测试
z-index 高效得多。 
