原生 select 下拉层由系统/ua 直接绘制，不参与 css 布局流，故不受窗口尺寸影响且无法响应 resize；自定义下拉需用 div+ul+li 实现，通过 js 监听 resize 并用 requestanimationframe 动态更新 ul 的 max-height。
原生 select 的下拉弹出层高度完全不受窗口尺寸影响，也无法响应 resize 事件做自适应；真正可行的路径是用 div+ul+li 自定义下拉，并在 JS 中监听窗口变化、动态重算 max-height。
为什么 window.resize 对原生 select 下拉无效
浏览器把 select 的“选中区”和“弹出菜单”视为两个独立渲染单元：前者受 CSS 影响（有限），后者由操作系统或 UA 直接绘制，不参与 CSS 布局流，也不响应任何 JavaScript 尺寸监听。你绑了 window.addEventListener('resize', ...)，对弹出层高度毫无作用。
-
select本身没有getBoundingClientRect()可用于弹出层——它根本不在 DOM 中实时存在 - 移动端（尤其是 iOS Safari）会强制缩放整个弹出区域以满足触摸热区 ≥44px，覆盖任何 CSS 计算
- 即使你用
size属性模拟列表模式，它的高度也只取决于行数 × 浏览器默认行高，和窗口宽度/高度无关
自定义下拉如何响应窗口尺寸变化
关键不是“让下拉随窗口变”，而是“在窗口变化时，重新计算内容容器能撑多高”。这需要两步配合：CSS 约束 + JS 动态更新。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
-
ul必须设max-height（如max-height: 200px），不能设height或min-height；否则失去弹性 - 监听
window.resize时，先清空ul.style.height（避免旧内联样式锁死高度），再读取ul.scrollHeight获取真实内容高度 - 为防 iOS Safari scrollHeight 更新延迟，用
requestAnimationFrame包一层：requestAnimationFrame(() => ul.style.maxHeight = ul.scrollHeight + 'px') - 若需按比例缩放（如窗口宽 font-size，而是用
calc(50vh - 120px)这类视口单位写在 CSS 里，JS 只负责触发重排
移动端窗口变化的隐藏陷阱
iOS Safari 在键盘弹出/收起、地址栏显隐时也会触发 resize，但此时 document.documentElement.clientHeight 并不准确，直接用来算 max-height 会导致下拉被截断或留白。
- 不要用
window.innerHeight减去固定值（如 -80px）来算可用高度——Safari 地址栏高度不固定 - 更稳妥的做法：用
ul的父容器（如.dropdown-menu）做相对定位，设max-height: calc(100vh - var(--trigger-offset))，再用 JS 动态更新--trigger-offsetCSS 变量 - IE11 不支持 CSS 变量，需 fallback 到内联
style.maxHeight，并手动处理\r\n换行符导致的scrollHeight偏差（统一替换为\n） - 所有滚动容器必须声明
box-sizing: border-box，否则 padding 和 border 会让计算结果和视觉脱节
真正难的不是监听 resize，而是意识到：下拉高度从来不是“跟着窗口变”，而是“在当前可用空间里，尽可能展示完整内容”。一旦你开始写 ul.style.height = window.innerHeight * 0.6 + 'px'，就已经掉进不可靠的假设里了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
