原生select元素因属操作系统级控件而不参与CSS层叠上下文，z-index对其无效；可行方案包括将其挂载到body并绝对定位、改用自定义下拉组件或对遮挡元素降级处理。
下拉框被其他元素遮挡，z-index 无效？
HTML 原生 元素在多数浏览器（尤其是 Chrome、Edge、Firefox）中属于“操作系统级控件”，它不参与 CSS 层叠上下文（stacking context）的常规计算。这意味着给 或其父容器设置 z-index 几乎总是无效的——不是你写错了，而是浏览器根本不管。
哪些场景下 z-index 对 select 失效最明显？
常见于以下组合：
- 页面有固定定位（
position: fixed）的导航栏或弹窗 - 使用了
transform、opacity 、will-change等触发新层叠上下文的父容器 - 下拉框位于 Modal、Drawer、Tooltip 等浮层组件内部
- Vue/React 框架中用
v-if或useState控制显隐，但 DOM 插入位置没避开层级冲突
真正可行的绕过方案（非 hack）
没有银弹，但有稳定可用的路径：
-
把
移出遮挡它的父容器：例如将下拉框用document.body.append()动态挂载到 body 底部，再用position: absolute+top/left定位到视觉原位（需监听滚动和 resize 修正位置） - 改用自定义下拉组件（如 +
select的渲染限制，可自由控制z-index和样式。注意需手动实现键盘导航（Tab、ArrowDown）、焦点管理、ARIA 属性（aria-expanded、aria-controls）等可访问性细节- 对遮挡方做降级处理：比如把遮挡它的
fixed导航栏改为sticky，或临时移除其transform样式（仅在 select 展开时）/* 示例：临时解除 transform 遮挡（慎用） */ .select-open .header { transform: none !important; }为什么不要用 overflow: hidden + z-index 强行压？
有人尝试给遮挡容器加
overflow: hidden再调z-index，这反而会让select下拉菜单被直接裁剪——因为overflow: hidden会截断子元素的溢出内容，而原生下拉菜单正是以“溢出”方式渲染的。这不是层级问题，是渲染边界被物理切掉了。立即学习“前端免费学习笔记（深入）”；
原生
select的层级行为是浏览器内建机制，强行对抗只会引入更多兼容性问题。优先考虑移出 DOM 结构或替换为可控组件，比纠结z-index数值更省时间。 - 对遮挡方做降级处理：比如把遮挡它的
