多实例弹窗防抖需按实例隔离状态，每个弹窗维护独立timer并支持cancel；打开前清理旧任务，触发时捕获状态快照校验执行条件，移动端防touch/click重复触发。
多实例弹窗连续触发时防抖的核心矛盾
多个弹窗实例（比如不同 ID 的模态框）被快速连续打开又关闭，若共用同一个防抖逻辑或未隔离状态，容易出现“关错窗”“该关没关”“残留定时器干扰后续操作”等问题。根本原因不是防抖本身失效，而是防抖函数未按实例维度做状态隔离——所有调用共享一个 timer 变量，后一次关闭会清除前一次的计时，导致前一个弹窗失去关闭机会。
按弹窗实例绑定独立防抖状态
每个弹窗应拥有专属的防抖控制权，不能靠全局函数一刀切。关键做法是：把防抖逻辑封装进弹窗类或 Hook 内部，让每个实例维护自己的 timer 和配置参数。
- 使用闭包或类字段保存当前实例的 timer，避免跨实例污染
- 关闭弹窗方法（如
close()）必须调用本实例的防抖包装函数，而非外部统一 debounce - 示例：给弹窗构造时传入唯一 id，并在内部创建
debouncedClose = debounce(() => this.hide(), 300)
关闭前主动取消挂起的防抖任务
用户快速连点“关闭”后又立刻点击“打开”，若旧的防抖定时器仍在等待执行，可能在新弹窗已显示时错误触发隐藏——造成闪退或状态错乱。因此每次打开新弹窗前，必须清理上一个实例遗留的防抖任务。
- 增强防抖函数，支持
cancel()方法（清除当前 pending 的 setTimeout） - 在弹窗
show()或open()中，先调用上一个debouncedClose.cancel() - 组件卸载（如 React useEffect cleanup、Vue beforeUnmount）时也需 cancel，防止内存泄漏
区分“关闭触发”与“关闭执行”的时机
防抖只控制“执行”，不改变“触发意图”。用户点了 3 次关闭，你不需要响应 3 次，但必须确保最后一次点击对应的是当前可见弹窗——这就要求在触发防抖前做状态快照。
- 在事件回调中立即读取弹窗当前的
isOpen状态或 DOM 存在性 - 将该快照作为参数传入防抖函数，执行时校验状态是否仍匹配，不匹配则跳过
- 避免用
this直接引用可能已被销毁的上下文；推荐捕获关键标识（如弹窗 id、ref）
移动端需额外处理 touch 事件穿透
在 iOS 或部分安卓机型上，连续点击可能触发 touchstart + click 双重事件，导致同一操作被防抖两次——一次在 touch 阶段，一次在 click 阶段，最终关闭逻辑被抵消。
- 统一监听
touchstart并preventDefault()，禁用 click 冗余触发 - 或在防抖函数入口加标记：首次触发设
isTouchHandled = true，后续 click 若检测到该标记则忽略 - 对弹窗关闭按钮，优先用
pointerdown替代 click，兼容性更好且不易重复
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
