Esc关闭dialog时event.returnValue恒为""，非bug；区分关闭方式需提前记录状态；读取用户输入必须在close()调用前完成，而非close事件中；showModal()返回Promise的resolve值同returnValue，仅显式close(value)才非空。
Esc 关闭时 event.returnValue 总是空字符串
按下 Esc 键关闭 <dialog> 会触发 close 事件，但此时 event.returnValue 固定为 ""（空字符串），不是 undefined，也不是 null。这是标准行为，不是 bug。
原因很简单：只有显式调用 dialog.close("value") 时传入的参数，才会被写入 event.returnValue；Esc、点击 backdrop 或其他隐式关闭方式，都不会提供这个值。
- 不要在
close事件里依赖event.returnValue区分“用户点了取消”和“手滑按了 Esc” - 如果你需要区分这两种操作，必须主动记录关闭前的状态或来源，比如给按钮加
data-action="cancel"，并在点击时提前设置上下文 - 想统一处理所有关闭路径？那就把清理逻辑（如重置表单）放在
close事件里，但别指望靠returnValue判断意图
如何安全获取 Esc 关闭后的用户输入数据
Esc 关闭本身不携带数据，但用户可能已在对话框内填写或选择内容。关键在于：**必须在调用 close() 前读取，而不是等 close 事件触发后再读**。
因为 close 事件发生时，<dialog> 的 open 属性已变为 false，部分浏览器会暂停焦点或重置某些状态，导致 input.value 或 form.elements 读取不准（尤其配合 autofocus 或动态渲染时）。
立即学习“前端免费学习笔记（深入）”；
- 监听 Esc 键本身不可靠（容易和页面其他快捷键冲突），应放弃
keydown拦截 - 正确做法：在
close事件回调中不做 DOM 读取，而是在所有可能触发关闭的操作（按钮点击、表单提交）里，先采集数据，再调用dialog.close() - 示例：给“取消”按钮绑定点击事件，读取当前
input值后调用dialog.close("cancelled")，这样至少能保证event.returnValue === "cancelled" - 如果用户真按了 Esc，你就当没有输入——这是合理预期，不是缺陷
dialog.showModal() 返回的 Promise 能捕获 Esc 关闭吗
能，但返回值仍是空字符串。
dialog.showModal() 返回一个 Promise，resolve 值就是 dialog.close(value) 的 value 参数。但如果用户按 Esc 或点 backdrop，Promise 也会 resolve，只是值为 ""。
- 不能靠 Promise resolve 值区分关闭方式，它只反映是否显式传参
- 如果你用 Promise 链处理后续逻辑，记得检查
result === ""并当作“未确认”处理 - 不要写
if (result) { /* 成功 */ }—— 这会把"confirmed"和"0"（字符串零）都判为真，但""是唯一 falsy 字符串返回值 - 推荐显式判断：
if (result === "submit") { ... } else if (result === "") { /* Esc or backdrop */ }
为什么不能监听 keydown 拦截 Esc 来自定义行为
可以监听，但不推荐，而且无法真正“拦截”模态框的默认关闭逻辑。
showModal() 启动后，浏览器原生接管 Esc 键处理：按下即触发关闭 + close 事件。你在 document 或 dialog 上监听 keydown 并调用 e.preventDefault()，最多阻止一次默认行为，但无法阻止后续的关闭流程——close 事件仍会照常触发，且 event.returnValue 仍是 ""。
- 强行阻止 Esc 会破坏可访问性，屏幕阅读器用户依赖它退出模态框
- 若真有强业务需求（比如表单未保存时弹二次确认），应在
close事件里检查状态，然后调用dialog.showModal()重新打开——而不是拦 Esc - 注意：重复调用
showModal()不会报错，但需确保 DOM 状态干净（比如清空上次的提示文案）
实际最常被忽略的一点：很多人以为 dialog.returnValue 是个“数据出口”，其实它只是个轻量动作标识。真正要拿用户填的数据，得靠你自己在关闭前那一瞬间抓取——那一下时机，比怎么关更重要。
