position: absolute 配合 JS 动态定位需确保父容器设 position: relative，top 应基于输入框相对于父容器的偏移计算；滚动时须重算位置而非缓存；z-index 失效常因 stacking context 断层；iOS 键盘弹出需 focus 事件延迟重定位并区分环境。
position: absolute 配合 JS 动态计算 top/left 的坑
搜索建议框必须紧贴输入框底部，但 position: absolute 默认相对最近的 position: relative 祖先定位——如果父容器没设 position: relative，它就往上一直找，可能错位到 body 顶部。
- 输入框父级（比如
.search-wrapper）必须显式加position: relative，否则 top 计算再准也没用 - 不要依赖
getBoundingClientRect()返回的top值直接赋给style.top：它返回的是相对于视口的值，而absolute定位需要相对于其定位上下文（即那个relative父容器）的偏移 - 正确做法是：先拿到输入框相对于其
position: relative父容器的 offset，再加输入框高度作为建议框的top
示例关键逻辑：
const rect = inputEl.getBoundingClientRect();<br>const wrapperRect = wrapperEl.getBoundingClientRect();<br>dropdownEl.style.top = `${rect.bottom - wrapperRect.top}px`;
滚动时建议框脱离输入框的根源
只要页面或局部容器可滚动，且建议框父级不是该滚动容器本身，滚动就会导致位置错乱——因为 getBoundingClientRect() 每次都重算，但如果你只在 focus 或 keyup 时算一次并固定 top/left，那就彻底失效。
- 必须监听滚动事件，但别直接绑
window.onscroll：现代页面常有局部滚动（如侧边栏、弹窗内滚动），得监听所有可能影响定位的滚动容器 - 更稳妥的做法是：在每次显示建议框前重新计算位置，而不是“计算一次、长期缓存”
- 避免在
input事件里高频重算位置；改用requestAnimationFrame节流，防止卡顿
z-index 不生效？检查 stacking context 断层
建议框被遮挡，往往不是 z-index 设小了，而是它和遮挡元素分属不同 stacking context，彼此不可比。
立即学习“前端免费学习笔记（深入）”；
- 常见断层点：父容器有
opacity 、<code>transform、filter、will-change，都会创建新 stacking context - 确认建议框和输入框是否在同一 stacking context 下——最简单办法：把建议框临时 append 到
document.body，看是否正常显示 - 如果必须保留在原 DOM 结构中，就让它的直接父容器也参与 stacking 层级控制，比如加
position: relative; z-index: 1
移动端 iOS Safari 键盘弹起后定位漂移
iOS Safari 弹出软键盘会触发 viewport 缩放和滚动，getBoundingClientRect() 返回值瞬间失真，且键盘收起后不会自动回弹建议框。
- 不能只监听
resize：iOS 下键盘弹起不触发 resize，要监听focusin和focusout事件来主动重定位 - 键盘弹起后，
window.innerHeight变小，但document.documentElement.scrollTop可能为 0，需结合visualViewportAPI（较新）或 fallback 到 scrollY + clientHeight 判断可见区域 - 简单兜底：focus 后延迟 100ms 再重算位置，避开 Safari 键盘动画帧干扰
容易被忽略的是：同一个输入框在 PC 和 iOS 上可能走两套定位逻辑，别指望一套 CSS + JS 通吃；动态位置计算必须带环境判断，而不是只靠 CSS 的 position: fixed 偷懒——fixed 在 iOS 键盘场景下根本不可靠。
