popovertarget仅支持可聚焦、可激活的语义化交互元素，如<button>、<input type="button">等，不支持<div><span><p>等非交互元素；强行在<div>上使用会被浏览器忽略，且无法触发原生弹窗生命周期。
popovertarget 只能在可聚焦、可激活的交互元素上生效
它不是通用属性，浏览器只允许写在语义上“能被用户主动触发”的元素上。写在 <div>、<span> 或 <p> 上完全无效，解析时会被忽略，控制台也不会报错——这是最常被误用的点。
真正支持 popovertarget 的 HTML 标签只有：<button>、<input type="button">、<input type="submit">、<input type="reset">，以及实验性支持中的 <summary>（仅部分 Chromium 版本）。
-
<button>是最稳妥的选择，语义清晰、无障碍友好、默认可聚焦 -
<input type="button">可用，但缺乏语义表达力，屏幕阅读器可能朗读为“按钮”，不如<button>明确 -
<input type="submit">和<input type="reset">虽然支持，但行为易与表单提交冲突，不建议用于纯弹窗触发 -
<a href="#">不支持 —— 即使加了role="button"也不行，浏览器硬性限制
为什么 <div> 加 popovertarget 没反应
因为 <div> 默认不可聚焦、不可激活，不符合 WAI-ARIA 中“interactive element”的定义。浏览器在解析 DOM 时直接跳过该属性，连尝试匹配目标 ID 的步骤都不会执行。
有人试图用 tabindex="0" + role="button" 强行模拟，但这只是骗过了屏幕阅读器，无法触发原生 popover 生命周期（比如焦点捕获、Esc 关闭、::backdrop 渲染等）。结果就是：点击有视觉反馈，但弹窗不出现，且无障碍逻辑完全断裂。
立即学习“前端免费学习笔记（深入）”；
- 即使目标
<div popover>存在且 ID 匹配，<div popovertarget="xxx">也永远静默 - 用 JS 动态设置
element.popoverTargetElement = targetEl可以绕过此限制，但这已脱离声明式设计初衷，需自行补全焦点管理 - 若必须用非标准标签触发，应改用 JS 控制
showPopover()/hidePopover()，而非硬套 HTML 属性
input 元素使用 popovertarget 的注意事项
<input type="button"> 支持 popovertarget，但它天生没有 innerText，按钮文案得靠 value 属性，而 value 在某些 CSS 重置下可能被截断或不可访问。相比 <button>，它对多语言、动态文案、图标+文字组合的支持更弱。
-
value是唯一可写文案的位置，不能嵌入 HTML（如图标<svg>），否则会被当作纯字符串渲染 - 若需 aria-label 或自定义无障碍描述，必须显式加
aria-label，<button>则可直接包裹文本或元素 -
type="submit"触发 popover 时，若父<form>无onsubmit阻止默认行为，会引发页面刷新 —— 这不是 popover 的问题，而是表单提交逻辑干扰
跨 shadow DOM 或 iframe 场景下 popovertarget 失效
popovertarget 的 ID 匹配仅在同一个 DOM 树上下文中有效。它无法穿透 shadow boundary，也不能跨 iframe 指向另一个文档里的元素。这种限制是浏览器安全模型决定的，不是 bug，也无法通过 polyfill 绕过。
- 目标
<div id="x" popover>若在 shadow root 内，外部<button popovertarget="x">无效 - iframe 内的按钮无法控制主文档的 popover，反之亦然
- 若组件封装在 Web Component 中，需确保触发器和目标都在同一 shadow root 下，或全部放在 light DOM
- 服务端渲染（SSR）后注入的 popover 元素，若未在首屏 DOM 中静态存在，Safari 17.4+ 会拒绝识别其 popover 属性 —— 这与 popovertarget 是否可用直接相关
<button popovertarget="xxx"> 触发同文档内静态存在的 <div id="xxx" popover>。其他路径看似灵活，实则每一步都藏着兼容性、无障碍或运行时状态的坑。 
