监听 dialog 的 close 事件是最可靠方式，可准确获知关闭原因并执行清理；轮询 open 状态或误用 closed 属性均不可靠，自定义弹窗需统一管理关闭标志并确保异步操作完成后再更新状态。
监听 dialog 的 close 事件是最可靠方式
原生 元素关闭后会触发 close 事件，且 dialog.returnValue 可反映关闭原因。这是唯一被标准支持、无需轮询或定时检测的方案。
常见错误是只监听点击按钮，却忽略 Esc 键、点击遮罩层、浏览器后退等合法关闭路径，导致状态不同步。
-
dialog必须已挂载到 DOM，否则addEventListener('close', ...)不生效 - 事件回调中读取
dialog.returnValue：值为'confirmed'/'canceled'表示用户主动点按钮；为空字符串则代表 Esc 或蒙层关闭 - 不要在
close回调里再调用dialog.close()，会报错 “Failed to execute 'close' on 'HTMLDialogElement': The element is not in an open state.”
closed 属性只适用于 window.open() 打开的窗口
如果你用 window.open() 弹出一个独立页面（非模态框），可用 newWin.closed 检测是否被关掉。但该属性对 、alert()、confirm() 完全无效。
注意：closed 是只读属性，返回布尔值；它不会自动更新，需手动轮询（不推荐）或结合 beforeunload 做兜底。
- 仅当
newWin是由当前脚本调用window.open()创建时才有效 - 主窗口、iframe、
都没有closed属性 - 某些浏览器（如 Safari）在弹窗被拦截后，
newWin可能为null，直接访问.closed会报Cannot read property 'closed' of null
别用 setInterval 轮询 dialog.open 状态
dialog.open 是一个布尔属性，但它只是反映当前渲染状态，不是“是否刚被关闭”的信号。轮询既低效又不可靠——用户可能在两次检查间隙完成打开→关闭→再打开。
更严重的是，dialog.open 在 showModal() 后立即变为 true，但此时动画可能未结束；关闭后它变 false，但 close 事件尚未触发，清理逻辑放这里容易出竞态。
- 轮询频率设太高（如
100ms）会拖慢主线程，尤其在低端设备上 - 轮询无法区分“用户刚关掉”和“还没来得及打开”，状态语义模糊
- 真正需要响应“关闭完成”的场景（如清空表单、释放资源），必须用
close事件
自定义弹窗需自己维护关闭状态标志
若回退到 div + z-index 实现的弹窗（兼容旧浏览器），没有原生事件可依赖，就得手动管理状态。
关键不是“怎么判断”，而是“谁负责设置这个判断依据”。建议在所有关闭入口统一写入一个标志位，并确保异步操作（如 API 请求）完成后才允许关闭。
- 声明一个变量如
let isDialogOpen = false，在show()时设为true，在所有关闭路径（按钮、Esc、蒙层、close()方法）末尾设为false - 避免在多个地方重复写
isDialogOpen = false，应封装成hideDialog()函数统一处理 - 如果弹窗内有异步提交，关闭前要加防抖或等待 Promise settle，否则
isDialogOpen可能提前变false，导致后续逻辑误判
真正的难点不在“检测是否关闭”，而在于**关闭动作是否真正完成**：DOM 是否移除、焦点是否归还、内存是否释放、可访问性状态是否同步。很多 bug 来自假设“dialog.close() 调用完就结束了”，其实清理工作必须放在 close 事件里做，且要覆盖所有关闭路径。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
