toggle事件本身不触发Promise，它只是普通DOM事件；需手动用Promise封装showModal()与用户交互（如按钮点击）来实现等待逻辑。
toggle 事件本身不触发 Promise，别误以为它能“等待”
HTML 的 toggle 事件（比如 <dialog></dialog> 元素上触发的）只是个普通 DOM 事件，它不会自动返回 Promise，也不会暂停执行。你写 dialog.addEventListener('toggle', () => {...})，里面仍是同步回调——想让它“等用户点完再继续”，得自己包 Promise。
常见错误是直接在 toggle 回调里 return 一个值，指望调用方能 await 到；结果是 return 无效，外层代码早已执行完毕。
- 触发
toggle的时机 ≠ 用户操作完成的时机（比如 dialog.open 可能还没渲染完，或用户点了 backdrop 关闭但没触发预期逻辑） -
toggle事件只告诉你 open 状态变了，不告诉你“用户点了哪个按钮”或“是否确认了” - 真正需要 Promise 的，是“弹出 dialog → 等用户选择 → 返回结果”这个完整链路，不是事件本身
用 Promise 封装 dialog.open() + 用户交互才是正解
核心是把 dialog.showModal() 当作起点，把“用户点击确定/取消”作为 resolve/reject 的触发点。不能依赖 toggle 事件做判断，因为：用户可能按 Esc、点遮罩、甚至直接关闭标签页——这些都会触发 toggle，但你无法区分意图。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 调用
dialog.showModal()前，先创建new Promise((resolve, reject) => {...})，把resolve和reject存到闭包或组件状态里 - 给 dialog 内部的“确认”按钮绑定 click，调用
resolve('confirmed')；“取消”按钮调用reject('canceled') - 必须手动调用
dialog.close()，否则 dialog 会一直挂着，Promise 永远不 settle - 加一层
try/catch包住showModal()，捕获如"Failed to execute 'showModal' on 'HTMLDialogElement'"这类 DOM 异常（比如 dialog 不在 body 下）
async/await 调用时容易忽略的边界情况
你以为写个 const result = await showDialog() 就万事大吉？实际有三个坑常被跳过：
- 用户关掉页面或切走标签页，Promise 既不 resolve 也不 reject —— 需要加超时控制，比如
Promisetimeout(10000, showDialog()) - dialog 被多次快速调用，旧的 Promise 还没 settle，新的又来了 —— 要么加防重（如禁用按钮），要么用 AbortController 清理前序状态
- resolve/reject 传入的值类型不一致（比如有时传字符串，有时传对象），后续 .then() 里容易报
Cannot read property 'xxx' of undefined—— 建议统一返回结构，例如{ type: 'confirm' | 'cancel', value?: any }
不要用 toggle 事件监听 dialog 关闭状态来驱动流程
有人试图这样写：dialog.addEventListener('toggle', () => { if (!dialog.open) doSomething() })，然后在 doSomething 里再 resolve Promise。这会导致 race condition：用户点了确认按钮，你先触发了 click 处理器 resolve，紧接着 toggle 又触发，再次执行 doSomething，造成重复逻辑或状态错乱。
正确做法是：所有用户动作（按钮、Esc、backdrop 点击）都统一收口到同一个 resolve/reject 调用点，并在调用后立即移除事件监听器或清空引用。避免任何“状态变化 → 触发事件 → 执行逻辑”的间接链条。
最简健壮模式就是：showModal → 绑定一次按钮 click → 点击即 close + resolve/reject → Promise 结束。其余路径（Esc、backdrop）可通过 dialog.addEventListener('close', ...) 单独处理，但别让它参与主流程决策。
