原生 popover 的 beforetoggle 事件不能替代 toggle 事件，因其仅提供切换后的 opened 状态，无法区分触发源、不可取消、不响应用户交互，仅适用于同步 ARIA 或 UI 状态；焦点管理需手动实现。
原生 popover 没有 toggle 事件，只有 beforetoggle —— 它不表示“用户点了关闭”，而是“状态即将切换”，且无法取消、不能区分打开/关闭意图。
为什么 beforetoggle 不能当 toggle 用
这个事件名有误导性。它在每次 showPopover() 或 hidePopover() 调用时触发一次，但事件对象只带一个 opened 布尔值（切换后的状态），不提供“之前是什么状态”或“谁触发的”。比如你连续点两次打开按钮，beforetoggle 会触发两次，opened 分别为 true、false，但你无法知道第二次是用户点了关闭按钮，还是脚本误调了 hidePopover()。
- 它不是“点击触发事件”，不响应
click、blur等用户交互源 - 监听后不能
event.preventDefault()，关不了、拦不住、改不了 - 嵌套 popover 场景下，多个
beforetoggle可能乱序触发，难以绑定到具体元素
beforetoggle 唯一靠谱的用途：同步 DOM 状态
它适合做“副作用同步”，比如更新 ARIA 属性、切换按钮文字、记录日志——前提是不依赖“这是第几次”或“用户想干啥”。示例：
popover.addEventListener("beforetoggle", (e) => {
// ✅ 安全：只读取最终状态，设置对应属性
trigger.setAttribute("aria-expanded", e.opened);
trigger.textContent = e.opened ? "收起" : "展开";
});
- 不要在里面调用
showPopover()或hidePopover()，会引发循环 - 不要依赖
e.target判断来源，因为showPopover()是在目标元素上调用的，e.target总是那个[popover]元素 - 若需区分打开/关闭逻辑，必须在外层手动维护状态变量，而不是靠事件判断
真正可控的焦点管理，得靠显式 JS 绑定
原生 popover 不自动处理焦点链（focus trap）或关闭后焦点回归。你必须自己补：
立即学习“前端免费学习笔记（深入）”；
- 打开时：用
popover.focus({ preventScroll: true })或聚焦内部第一个可聚焦元素 - 关闭时：保存触发元素（如按钮），在
hidePopover()后trigger.focus() - Esc 关闭：虽然 popover 自动响应 Esc，但焦点回归仍需手动写，否则焦点可能丢失到 body
- 遮罩点击关闭：原生 popover 没有遮罩层，
[popover]是独立定位元素，点击外部不会自动关闭 —— 必须自己监听click并判断是否在 popover 外
例如关闭逻辑：
document.addEventListener("click", (e) => {
if (!popover.contains(e.target) && e.target !== trigger) {
popover.hidePopover();
trigger.focus(); // ✅ 关键：手动回归焦点
}
});
Chrome 128+ 的 :has() + focus-within 可简化部分逻辑
如果你只支持最新 Chromium，可以用 CSS 捕获 popover 内部聚焦状态，避免部分 JS 监听：
[popover]:has(:focus-within) {
outline: 2px solid #007aff;
}
-
:focus-within在 popover 内任一子元素获得焦点时生效，可用于视觉反馈 - 但不能替代 JS 焦点管理：它不触发回调，也不能阻止失焦后 popover 残留
-
:has([popover]:focus-within)这类写法目前无效，:has不支持伪类嵌套
真正难的不是监听，而是让焦点在打开 → 内部 → 关闭 → 触发器之间无缝流转。浏览器没帮你做完这件事，beforetoggle 只是通知你“状态变了”，剩下的全是你的活。
