是，漏了position属性——z-index仅对relative、absolute、fixed或sticky生效，static下被忽略；需先设position: relative等，并排查堆叠上下文及窗口元素限制。
按钮加z-index没反应，是不是漏了position？
直接给
实操建议：
- 先加
position: relative（最安全，不脱离文档流） - 若需悬浮效果（如固定在右下角），用
position: fixed+z-index - 避免给
button设position: absolute，除非它真要脱离布局上下文；否则容易和表单其他元素错位 - 检查开发者工具「Computed」面板，确认
position最终值不是static，且z-index显示为数字而非auto
为什么按钮z-index: 999还是被遮住？查堆叠上下文
数值再大也没用，如果按钮和遮罩层（比如弹窗蒙层）分属不同堆叠上下文。常见“小 boss”父容器包括：
-
opacity: 0.99（哪怕只是0.99，也触发新上下文） -
transform: translateZ(0)或will-change: transform（iOS Safari尤其敏感） -
position: relative+z-index: 1的父容器（它自己成了局部上下文根）
排查方法：打开 DevTools → 「Computed」→ 搜索stacking context，看按钮或它的某个父级是否被标为「Stacking Context」；临时注释掉疑似父级的opacity或transform，观察按钮是否突然浮出。
按钮和select/iframe重叠时z-index完全失效
这不是你代码的问题，是浏览器限制：select、iframe、object属于“有窗口元素（windowed element）”，天然渲染在所有CSS层之上，z-index对其无效。
可行方案：
- 遮盖
select：用visibility: hidden临时隐藏它（比display: none更安全，不破坏布局） - 替代
select：改用div+ul实现的自定义下拉，完全受z-index控制 - 覆盖
iframe：不能靠父页面设高z-index，必须在同级DOM插入遮罩层，并确保该遮罩的父容器没有创建新堆叠上下文
按钮层级设计建议：别堆数字，分梯度预留
盲目写z-index: 999999会掩盖结构问题，也难维护。按功能意图分段更可靠：
- 基础交互层（按钮、输入框）：
z-index: 10–50 - 弹窗/下拉菜单：
z-index: 100–200 - 全局遮罩/Toast：
z-index: 1000+
注意负值：z-index: -1会让按钮沉到父容器背景色下面，可能被边框盖住；同级按钮z-index相同或未设时，后写的HTML元素自然在前一个之上。
真正卡住人的从来不是数值大小，而是谁悄悄当了“小 boss”——那个带opacity或transform的父容器，它一出现，子按钮的z-index就只能在它肚子里比大小了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
