overflow: hidden是下拉列表被截断的头号元凶；只要父容器同时满足overflow: hidden（或auto/scroll）且position非static，就会成为绝对定位下拉菜单的裁剪边界和包含块，导致超出部分被强制裁剪。
overflow: hidden 是下拉列表被截断的头号元凶
不是 z-index 没设高，也不是 position: absolute 写错了——只要父容器同时满足两个条件：overflow: hidden（或 auto/scroll） + position 不是 static，它就会成为绝对定位下拉菜单的「裁剪边界」和「包含块」。此时无论子元素 top 设多大、z-index 写 99999，内容超出父容器内边框的部分都会被直接砍掉。
常见触发位置包括：.header、.navbar、.el-dialog__body、甚至某些用了 transform 或 will-change 的 wrapper 容器——它们会隐式创建层叠上下文 + 裁剪行为，双重封杀下拉面板。
把下拉菜单移出问题容器是最稳的解法
不改父容器样式，也不碰全局 overflow，直接让下拉菜单脱离它的 DOM 管辖范围。这在框架组件中尤其关键：
- Element UI：启用
popper-append-to-body属性，强制把.el-select-dropdown挂到body下 - Element Plus：用
teleported属性，等效于popper-append-to-body - 原生或自定义下拉：用
ReactDOM.createPortal（React）或document.body.appendChild（原生 JS），再通过getBoundingClientRect()动态计算弹出位置
注意：挂到 body 后，z-index 必须足够高（比如 z-index: 2100），且确保没有更外层容器因 transform 或 opacity 创建了新层叠上下文把它又框住。
立即学习“前端免费学习笔记（深入）”；
不改 DOM 时，如何临时绕过 overflow 截断
如果无法调整结构或使用 Portal，可尝试从 CSS 层面松动裁剪限制，但需逐层排查生效点：
- 给问题父容器加
overflow: visible !important，并确认它没被更上层的overflow: hidden覆盖 - 若父容器依赖
position: relative做布局，可尝试改为position: static，让下拉菜单向上找更外层的包含块（前提是不影响其他定位逻辑） - 用
clip-path: inset(0)替代overflow: hidden实现视觉裁剪——它不触发包含块，也不裁剪绝对定位子元素，但 Safari 对含transform的元素支持不稳定
别碰 max-height + overflow-y: auto 组合来“修复”下拉菜单本身——这是治标不治本，反而可能让滚动条出现在错误层级。
z-index 不起作用？先看它有没有“资格”生效
z-index 只对已定位元素有效，且效果受限于最近的层叠上下文。检查这三点：
- 下拉菜单本身是否设置了
position: absolute或fixed？static元素设了z-index等于白写 - 它的直接父容器（如
.dropdown）是否设了z-index？只要它有position: relative+z-index: 0，就自动创建层叠上下文，子菜单的z-index: 9999就只能在它内部比大小 - 有没有更外层容器带
transform、filter、opacity ？这些属性也会悄悄创建层叠上下文，把下拉菜单“关小黑屋”
安全做法是：触发容器（如 .dropdown）只设 position: relative，不设 z-index；下拉菜单设 position: absolute + 明确 z-index（如 1000）；全站统一层级体系，避免数字乱堆。
真正难处理的不是单个 overflow: hidden，而是它和 transform、will-change、filter 这些属性叠加后形成的“隐形牢笼”。调试时优先用浏览器开发者工具的“渲染”面板勾选「层叠上下文」和「裁剪边界」，一眼就能看出哪一层在偷偷截断你的下拉菜单。
