下拉框被 overflow: hidden 裁剪的根本原因是原生 弹出层在父容器 stacking context 内绘制，且不参与常规文档流和 z-index 层级计算，故 css 无法干预，必须用 js 创建自定义下拉并绝对/固定定位到 body。
下拉框被 overflow: hidden 裁剪的根本原因
根本不是下拉框“不听话”，而是浏览器渲染机制决定的：原生 <select></select> 的弹出层（popup）默认是**在父容器的 stacking context 内绘制**，一旦父容器设了 overflow: hidden 或 overflow: auto 且内容溢出，弹出部分就会被裁掉。这不是 bug，是规范行为——连 Chrome、Firefox、Safari 都一致这么干。
为什么不能只靠 CSS 把下拉框“撑出来”
很多人试过给 <select></select> 加 position: relative、z-index，甚至 transform: translateZ(0)，都没用。因为原生下拉弹层**不参与常规文档流和 stacking context 层级计算**，它像一个“模态浮层”，但又没 modal 那么自由——它的定位锚点死死绑在 <select></select> 元素本身，且无法用 CSS 改变其挂载位置。
-
z-index对原生下拉弹层完全无效 -
transform、will-change等触发新 stacking context 的属性也不起作用 -
clip-path或mask更不行，它们只影响元素自身，不干预弹层渲染
必须用 JS + 绝对定位把 <select></select> 替换为自定义下拉的典型场景
当你的表单嵌在 modal、card、table cell 或任何带 overflow: hidden 的容器里，且你无法修改该容器样式（比如第三方 UI 库组件、遗留布局），那就只能接管渲染逻辑。
- 监听
click或focus，阻止原生下拉展开：event.preventDefault() - 动态创建一个
<div class="custom-select-dropdown">，插入到 <code>document.body - 用
getBoundingClientRect()计算原<select></select>位置，再结合window.scrollY和document.documentElement.scrollTop（兼容 IE）算出绝对坐标 - 注意滚动时要重新定位：监听
scroll事件（建议节流），或用IntersectionObserver监测是否移出视口
示例关键计算：
const rect = selectEl.getBoundingClientRect();
const top = rect.bottom + window.scrollY;
const left = rect.left + window.scrollX;
dropdownEl.style.cssText = `position: absolute; top: ${top}px; left: ${left}px;`;
用 position: fixed 替代 absolute 的坑与取舍
如果页面有横向滚动或 transform 父容器，position: absolute 定位会偏移——因为它的参考系是最近的 position: relative/absolute/fixed 祖先，而你早把它扔到 body 下了。这时候改用 fixed 更稳，但代价是：
- 不再跟随页面滚动自动调整：需监听
scroll并手动更新top/left - 如果页面用了
zoom或transform: scale()，fixed元素可能错位（尤其在 Safari） - 移动端键盘弹起时，
fixed元素可能被顶出可视区（iOS Safari 尤其明显）
真正难的不是定位计算，而是处理所有这些边界情况时的判断优先级：先保位置准，再保不遮挡，最后保滚动同步——三者冲突时，往往得牺牲“完美同步”，换“视觉稳定”。
