原生 popover 属性目前不可直接用于移动端下拉菜单，因 safari 完全不支持、chrome for android 行为不一致，且所有浏览器均缺失键盘导航、焦点管理、滚动隔离等关键能力。
原生 popover 属性在移动端下拉菜单中目前不可直接用于替代自定义下拉逻辑，因为 Safari（iOS/iPadOS）尚未支持该属性，Chrome for Android 虽已实现但行为不一致，且所有浏览器均不支持键盘导航与焦点管理的完整语义链。
popover属性在移动端的实际兼容性现状
截至 2026 年 9 月，popover 是一个仍在演进中的实验性功能。它在桌面 Chrome 114+ 和 Edge 115+ 中可用，但移动端仅 Chrome for Android 123+ 有限支持，Safari 完全未实现（包括 iOS 17.6 和 iPadOS 17.6），Firefox 仍处于提案阶段。
更关键的是：即使渲染成功，popover 元素默认不接管 Tab 焦点、不响应 Arrow 键、不自动设置 aria-expanded 或同步 aria-haspopup，也**不会阻止点击穿透或滚动穿透**——这些恰恰是移动端下拉菜单最常出问题的地方。
- 用
<button popovertarget="menu"></button>+<div id="menu" popover> 在 iOS 上直接静默失效，无报错也无回退 <li>Android Chrome 中点击按钮可触发显示，但快速连点易触发两次 <code>togglePopover()导致状态错乱 - 所有平台下，
popover元素内部的ul无法通过键盘上下键导航，Enter也不触发选中 - 焦点流控制：不自动将焦点移入 popover 内容，也不在关闭时恢复上一个焦点元素
-
手势适配：不处理
touchstart/pointerdown的延迟与穿透，iOS 下仍会触发 300ms 延迟 -
滚动隔离：不自动对
html或body设置overscroll-behavior: none，背景仍可被拖动 - 检测
'popover' in document.documentElement且!/iPhone|iPad|iPod/.test(navigator.userAgent)，否则跳过 popover 初始化 - 保持
<button aria-expanded="false"></button>和<div role="menu"> 结构不变，仅用 JS 控制显隐和焦点 <li>移动端绑定 <code>pointerdown替代click，并手动调用e.preventDefault()防止链接提前跳转 - 打开时立即执行：
document.documentElement.style.overscrollBehavior = 'none'，关闭后还原
为什么不能把popover当“开箱即用”的下拉组件用
原生 popover 的设计目标是轻量提示（如 tooltip、form validation hint），不是功能完整的菜单控件。它缺少三类必需能力：
这意味着：哪怕你在 Android Chrome 中让它显示出来，用户用手指滑动菜单列表时，页面依然会跟着滚；用屏幕阅读器访问时，焦点卡在按钮上，读不出选项；按 Tab 直接跳出菜单——这根本不符合 WCAG 2.1 A 级要求。
可行的过渡方案：渐进增强而非替换
如果你已在用 popover 做桌面端优化，可在移动端主动降级为传统实现，并复用同一套 DOM 结构和事件逻辑：
这样既保留了桌面端的语义简洁性，又确保移动端行为可控——而不是寄希望于一个尚未成熟、各端表现割裂的原生属性。
真正容易被忽略的点是：popover 不是“更高级的 dropdown”，它是“更受限的 tooltip”。想靠它省掉键盘导航、滚动锁、焦点管理这些工作，只会让移动端体验比手写代码还差。
