原生select下拉面板不属网页DOM，无法直接测量其高度；可测的只有control框高度或手动计算option数量×行高，自定义下拉才可测ul的scrollHeight。
下拉列表没展开时看不到真实高度
浏览器默认的 <select></select> 元素在未激活状态下，DOM 中只存在一个“控制框”，<option></option> 选项不会渲染进主文档流——所以你在 Elements 面板里点开 <select></select> 标签，根本看不到子节点，更别提测高度了。这不是工具问题，是浏览器原生行为限制。
必须先触发下拉：点击 <select></select> 框，让操作系统级下拉菜单弹出（注意不是自定义组件），再立刻按 Ctrl+Shift+C（Windows/Linux）或 Cmd+Shift+C（macOS）选中刚出现的选项区域——此时才能定位到实际渲染的 DOM 节点（部分浏览器会临时注入 shadow DOM 或 iframe，需留意顶部上下文切换）。
Chrome/Firefox 对原生 select 的 DOM 处理差异
Chrome 在下拉展开后，<option></option> 仍不进入主 DOM 树，而是由浏览器进程直接绘制；Firefox 则可能将选项渲染为 <div role="option"> 类似结构并挂载到页面内（取决于版本和是否启用 accessibility 模式）。这意味着：<ul>
<li>在 Chrome 里用 <code>document.querySelector('option') 始终返回 null，哪怕下拉已展开
option 并查看其 computed height，但该值未必反映真实视觉高度（受系统字体、缩放影响）真正能测的高度只有两种
如果你的目标是调试或适配，能实际获取并用于逻辑判断的只有：
立即学习“前端免费学习笔记（深入）”；
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
-
select.offsetHeight：控制框自身高度（含 border/padding），始终可读 - 手动计算
option数量 × 单项行高（需假设每项固定高度，且忽略首尾留白、滚动条占位） - 对自定义下拉（如用
<div class="dropdown"> + <code><ul></ul>实现）：展开后直接选中ul节点，在右侧 Computed 面板看height或scrollHeight别试图用
getBoundingClientRect()去捕获原生下拉面板——它返回的height是 0 或不可靠值，因为那个面板压根不在当前 document 的坐标系里。为什么“检查元素”有时点不到下拉选项
常见原因不是快捷键失灵，而是交互时机不对：
- 鼠标悬停时没等高亮稳定就点击 → 误点到背景或相邻元素
- 下拉弹出后，鼠标移出
<select></select>区域导致菜单收起 → 必须在菜单保持展开状态时操作 - 页面用了
pointer-events: none或z-index层级遮挡 → 先在 Styles 面板临时禁用这些规则再试 - 某些企业内网页面禁用右键和 DevTools 快捷键 → 改用顶部工具栏的「选择元素」图标（箭头图标），避免键盘劫持
最稳的路径永远是：确保下拉可见 → 按快捷键进入选择模式 → 鼠标缓慢移动直到目标选项高亮 → **单击，不拖拽** → 看 Elements 是否跳转。其他所有“找不到”的抱怨，90% 出在这一环没卡准。
