cancel事件是通知而非拦截机制，无法preventdefault；esc关闭仅在showmodal()激活且有焦点时生效；需通过控制激活时机、聚焦策略、改用show()、绕开file input bug、分别监听cancel/close事件来防止误关闭。
dialog 的 cancel 事件不是用来“防止关闭”的，而是用来响应关闭
很多人误以为监听 cancel 事件可以阻止 Esc 键关闭，其实它只是浏览器在用户按 Esc 或点击 backdrop 时派发的**通知事件**，且无法被 preventDefault() 阻止——这是规范强制行为，不是 bug。想“防意外关闭”，得从源头控制触发条件，而不是拦截事件。
Esc 键关闭无法禁用，但可限制触发前提
Esc 关闭只在 dialog 处于模态激活状态（即调用了 showModal()）且有焦点时才生效。常见误关往往源于焦点失控或过早激活。以下操作能有效收窄触发面：
- 确保
dialog只在真正需要交互时才调用showModal()，避免在页面加载或表单校验失败后立即激活 - 打开前手动聚焦到 dialog 内第一个可聚焦元素（如
dialog.querySelector('button, input, select')），否则焦点可能留在背景按钮上，导致 Esc 作用于 body 而不触发 cancel - 若 dialog 用于纯提示（无操作），改用
show()而非showModal()—— 它不启用 Esc 关闭，也不渲染 backdrop
文件选择导致的 cancel 误触发必须单独处理
Chromium 系列（Chrome、Edge）存在已知 Bug（#1449848）：当 <input type="file"> 在 dialog 内取消选择或重复选相同文件时，会错误触发 cancel 事件。这不是 Esc 导致，但现象一致，容易混淆。
应对方式不是堵 cancel，而是绕开原生 input：
- 用隐藏的
<input type="file" id="realFileInput" style="display:none"> - 绑定自定义按钮的
click事件，调用realFileInput.click() - 监听
realFileInput的change事件，拿到文件后更新 UI，并移除旧 input、插入新实例（避免复用触发 cancel）
这样既保留文件选择功能，又切断了 Chromium 的误关链路。
cancel 和 close 事件必须分开监听，否则会漏掉来源
cancel 事件只由 Esc 和 backdrop 点击触发；close 事件仅由显式调用 dialog.close() 触发。如果只监听 close，你将完全收不到 Esc 关闭的通知，也就无从做任何响应。
典型错误写法：
dialog.addEventListener('close', () => { /* 这里永远收不到 Esc 关闭 */ })
正确做法是两者都监听，并根据 dialog.returnValue 和触发时机区分逻辑：
-
cancel中：可重置表单、记录“用户放弃”行为、恢复背景滚动 -
close中：读取dialog.returnValue判断是确认还是取消（如dialog.close('confirm')），再执行对应提交或清理
最易忽略的一点：Safari 在快速连续开关 dialog 后，dialog.open 属性可能不同步，建议在 cancel 或 close 回调末尾加一句 console.assert(!dialog.open, 'dialog still open after close') 做运行时校验。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
