z-index不生效的主因是元素未处于定位上下文中。css中z-index仅对position为relative、absolute、fixed或sticky的已定位元素有效，且受层叠上下文层级限制，需检查父容器是否创建了新的层叠上下文。
z-index 不生效？先确认元素是否是定位上下文
很多情况下调了 z-index 没反应，不是值写小了，而是父容器没开启定位上下文。CSS 的 z-index 只对「已定位元素」（即 position 为 relative、absolute、fixed 或 sticky）才起作用。
常见错误现象：input 被遮挡，给它加 z-index: 999 毫无效果；或者遮挡它的弹层明明 z-index: 10，却盖不住 z-index: 20 的输入框——大概率是两者不在同一个层叠上下文里。
- 检查遮挡元素和被遮挡的
input的最近共同祖先，看有没有position: relative+z-index，它会截断层叠流 - 如果弹层用
position: absolute插在某个div里，而那个div恰好有z-index: 1，那整个弹层就被“压”在底层了 - 移动端 Safari 对
position: fixed+z-index的处理更敏感，有时需额外加transform: translateZ(0)强制创建新层叠上下文
input 被下拉菜单/日期选择器遮住？优先调整触发容器的 z-index
典型场景：点击 input 后弹出的 select 下拉、flatpickr 日历、Ant Design 的 DatePicker，经常盖不住父级导航栏或模态框。问题不在 input 本身，而在弹层的挂载位置和层级归属。
大多数 UI 库（如 Element Plus、MUI）默认把浮层挂到 body 下，但若项目用了 Shadow DOM、微前端沙箱，或全局设置了 body { z-index: 0 }，就会导致浮层层级被压制。
- 查弹层真实 DOM 位置：打开开发者工具，搜索
class="picker"或类似关键词，看它是否真的在body最外层 - 给弹层的直接父容器（通常是
div[role="dialog"]或自定义portal容器）设z-index: 2147483647（最大安全整数），比常规导航栏（z-index: 100）高足够多 - 避免对
input自己设z-index：它只是触发点，不是视觉主体；强行提它的层级可能破坏表单焦点逻辑
多个 z-index 值冲突时，别只看数字大小
z-index 不是全局排序，而是按「层叠上下文树」逐级比较。两个同级元素，即使 A 的 z-index 是 999，B 是 1，只要 B 所在的父容器 z-index 是 1000，B 就会盖过 A。
性能影响不大，但调试成本极高——你改了十处 z-index，可能只有一处真正生效。
- 用 Chrome DevTools 的「Layers」面板（需在 Rendering 面板中勾选）直观查看层叠上下文边界
- 统一项目中的层级规范：比如
header: 100、modal: 1000、tooltip: 2000，中间留空余量，避免硬编码999999 - 警惕 CSS-in-JS 库（如 styled-components）动态插入样式时，
z-index被后插入的规则覆盖（顺序即权重）
移动端软键盘弹出时 input 被顶飞？z-index 不是主因
这个现象常被误认为是层级问题，其实是 viewport 缩放和滚动行为导致的。iOS Safari 在软键盘弹出时会缩放页面、重置 scrollIntoView 行为，让 input 看似被遮挡，实际是视口偏移了。
此时调 z-index 完全无效，甚至可能干扰原生输入体验。
- 禁用缩放：
viewportmeta 中确保没有user-scalable=yes，且maximum-scale=1 - 监听
focus事件，在setTimeout中调用input.scrollIntoView({ behavior: 'smooth', block: 'nearest' }) - 对
position: fixed的输入框，加bottom: env(safe-area-inset-bottom)防止被刘海屏/键盘截断
真正难搞的是跨浏览器行为差异：Android Chrome 用 visualViewport API 更可控，iOS 还得靠 resize 事件 + 高度差判断。这类问题表面像 z-index，根子在布局响应机制上。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
