应使用 event.target.closest('.my-btn') 替代 event.target.matches('.my-btn')，并确保监听器在组件卸载时正确移除；closest() 向上查找最近匹配祖先，解决子元素触发导致匹配失败的问题，且需配合生命周期管理防止重复绑定。
element.matches 为什么在全局 click 里经常失灵
直接在 document.addEventListener('click', ...) 里用 element.matches('.my-btn') 判断，却总匹配不到——多数是因为事件目标是子元素（比如按钮里的 span 或 i），而非按钮本身。此时 event.target 不是你要的按钮节点，.matches() 自然返回 false。
真正要匹配的是“点击路径中最近的符合选择器的祖先”，不是死盯 event.target。
- 用
event.target.closest('.my-btn')替代event.target.matches(...)，它会向上查找，天然适配嵌套结构 -
closest()在 IE 中不支持，若需兼容 IE，得自己写遍历逻辑或引入 polyfill - 避免用太宽泛的选择器如
button，业务按钮务必加专属 class（如.order-submit-btn），否则容易误触
如何防止多次绑定或重复响应
全局 click 监听器如果在组件重复挂载时没清理，就会累积多个监听器，导致一次点击触发多次逻辑。这不是 matches 的问题，但常和它一起出现。
jQuery点击事件遮罩弹出层可移动特效代码
下载
"jQuery点击事件遮罩弹出层可移动特效代码下载。一款jquery弹出层插件制作注册表单点击按钮弹出层表单提交效果，可支持拖到的jQuery弹出层效果。标题、高度、宽度等可以自定义弹出层js插件。
- 监听器必须有明确的销毁时机，例如 Vue 的
onBeforeUnmount、React 的useEffect清理函数中调用document.removeEventListener - 给监听器函数命名（不要用箭头函数），否则无法精确移除：
const handleClick = (e) => { ... }; document.addEventListener('click', handleClick); document.removeEventListener('click', handleClick); - 可加一层防抖或标记位（如
if (e.handledByBusinessBtn) return），避免被其他逻辑二次处理
匹配带动态状态的业务按钮（如 disabled 或 loading）
有些按钮在 loading 状态下仍保留 class，但你不希望此时响应点击。仅靠 closest('.my-btn') 不够，得叠加状态判断。
- 用
el.matches('.my-btn:not(:disabled):not(.loading)')可以一步过滤，但注意：:disabled仅对原生表单控件有效，自定义按钮需靠 class 控制 - 更稳妥的方式是先
closest()找到按钮，再显式检查：if (btn && !btn.classList.contains('loading') && !btn.hasAttribute('disabled')) { ... } - 避免用
getComputedStyle(btn).opacity === '0.5'这类样式判断——不可靠，且性能差
为什么不用事件委托到父容器而坚持 document？
看起来把监听器挂到某个业务模块的 wrapper 上更安全，但实际中，弹窗、浮层、Tooltip 等 DOM 常是 body 级插入，不在局部容器内。挂太深会导致监听失效。
-
document是最稳妥的捕获点，只要确保closest()选择器足够精确，就不会泛化 - 如果项目用了 Shadow DOM，
event.composedPath()可能需要手动遍历，closest()默认不跨 shadow boundary - 性能上无需担心：现代浏览器对
closest()优化很好，比手写while (el && !el.matches(...)) el = el.parentElement快得多
closest 代替 matches」和「监听器生命周期管理」上，其余都是围绕这两条展开的细节。漏掉任意一个，都会让看似简单的全局按钮捕获变得不可靠。 
