z-index 对 position: static 元素完全无效，因其被浏览器在层叠顺序计算阶段直接过滤，不参与任何 z-index 排序；规范强制要求仅 relative、absolute、fixed、sticky 定位元素才可参与层叠上下文排序。
z-index 对 position: static 元素完全不解析
浏览器在层叠顺序计算阶段会直接过滤掉所有 position: static 元素，它们被归入“普通流内容”组，不参与任何 z-index 排序。这不是兼容性问题，而是 CSS 规范强制行为——z-index 属性对 position: static 的处理等同于未声明，连解析步骤都跳过。
常见错误现象包括：
- 在 DevTools 的 «Computed» 面板中搜
z-index，显示为auto或灰色标记 «not applicable» -
z-index: 9999写在样式里，但元素仍被兄弟节点遮盖，且无任何 warning 提示 - JS 动态设置
el.style.zIndex = '999'，却没同步写el.style.position = 'relative'
为什么规范要这样设计
因为 position: static 表示“完全遵循文档流”，不脱离、不偏移、不创建新层叠上下文。如果允许它参与 z-index 计算，就会破坏文档流的可预测性——比如一个段落里的 <span></span> 突然靠 z-index 浮到整个页面顶部，这违背了静态定位的设计本意。
所以规范明确：只有 position 值为 relative、absolute、fixed 或 sticky 的元素才被视为“已定位元素”，才有资格进入层叠上下文（stacking context）的排序流程。
立即学习“前端免费学习笔记（深入）”；
检查和验证是否真被忽略
别猜，用 DevTools 实锤确认：
- 选中目标元素 → «Computed» 面板搜索
position→ 看最终值是不是static - 同一面板搜索
z-index→ 若显示为auto或带删除线，说明未激活 - 临时在 «Styles» 面板手动添加
position: relative→ 刷新后遮盖关系是否立刻变化
注意：position 不可继承，子元素必须显式声明；CSS 框架（如 Normalize.css）可能重置某些标签的 position 为 static，覆盖你之前的设置。
真正卡住人的从来不是 z-index 数字写多大
而是你盯着那个 <img alt="为什么CSS标准中static定位元素不能直接应用z-index属性" > 或 <div> 看了半天，却没拉开 DevTools 查一眼它的 <code>position 计算值是不是还安安静静地躺在 static 上。更隐蔽的是：即使你设对了 position，只要某个祖先元素用了 opacity: 0.99、transform: translateZ(0) 或 filter: blur(0)，它就静默创建了新层叠上下文，把你的 z-index 锁死在局部范围里。
