原生 dialog 模态框点击遮罩不会自动关闭，需手动监听 click 事件并判断 e.target === dialogEl 才调用 close()；close() 触发 close 事件，Esc 或点击遮罩触发 cancel 事件，二者均需监听。
很多开发者第一次接触原生 dialog 元素时，都会踩到同一个坑：为什么点击了模态框外部的灰色遮罩，弹窗却纹丝不动？其实，答案很简单——它本来就没有这个默认行为。你必须手动调用 close() 方法，弹窗才会关闭。这一点，是理解 dialog 交互逻辑的起点。
为什么点了遮罩没反应？
原因在于，那个半透明的 backdrop（遮罩层）本身只是个视觉元素，并不附带任何交互逻辑。即使用 showModal() 方法打开了模态框，点击遮罩也不会触发任何关闭动作，除非你显式地编写监听代码。
- 一个典型的误区：开发者常常只写了
结构，然后调用showModal()，就理所当然地认为“点击外部应该关闭”。结果就是，用户除了按键盘上的 Esc 键，或者点击弹窗内部预设的关闭按钮，别无他法。 - 正确的做法是什么？ 你需要监听整个
dialog元素的click事件，并且进行一个严格的判断：只有当事件的目标（e.target）就是dialog元素本身时，才调用close()。这个判断至关重要，它能确保点击弹窗内部的任何子元素（比如按钮、图片、输入框）时，不会误触发关闭。 - 还有一个隐藏的坑：如果你的
dialog不是的直接子元素（例如，被嵌套在某个容器里），那么 backdrop 可能根本不会被正确渲染。在这种情况下，e.target === dialogEl这个条件可能永远无法成立，导致你的关闭逻辑失效。
close() 触发什么事件？
这里涉及到两个容易混淆的事件：close 和 cancel。当你通过代码主动调用 dialog.close() 时，会同步触发一个 close 事件。但是，如果用户按下 Esc 键，或者通过你编写的逻辑点击了 backdrop 关闭，触发的则是 cancel 事件。
- 想统一处理关闭后的清理工作？ 稳妥起见，两个事件都应该监听：
dialog.addEventListener('close', handler)和dialog.addEventListener('cancel', handler)。 - 别掉进这个陷阱：只监听
close事件，就以为能覆盖所有关闭场景。结果用户按 Esc 关闭时，你的清理代码根本没执行。 - 关于返回值：通过
dialog.returnValue可以读取到关闭时传递的值（例如，当表单设置method="dialog"并提交后）。但需要注意的是，通过cancel路径关闭时，这个返回值会是空字符串。
怎么阻止点击 backdrop 关闭？
有时候，你可能希望禁止用户通过点击遮罩来关闭弹窗。注意，千万不要使用 event.stopPropagation() 来阻止事件冒泡。这种做法副作用很大，它会同时禁用 Esc 键关闭和影响屏幕阅读器的焦点管理，属于对可访问性的严重破坏。
立即学习“前端免费学习笔记（深入）”；
- 真正安全的做法其实更简单：依然监听
click事件，当判断到e.target === dialogEl（即点击了遮罩）时，什么都不做，不调用close()就可以了。 - 记住，不要阻止事件传播，也不要调用
preventDefault()。必须保留 backdrop 原有的交互语义，以确保键盘导航和辅助技术的正常工作。 - 如果仅仅是想在视觉上“禁用”遮罩的点击感，可以尝试 CSS 方案：
dialog::backdrop { pointer-events: none; }。但要注意，Safari 浏览器对这个伪类的支持可能有限，而且即便这样做了，你仍然需要监听cancel事件来响应 Esc 键的操作。
最后，分享一个最容易被忽略的细节：弹窗关闭后，最好检查一下 dialog.open 属性是否已经变回了 false。在某些旧版本的 Safari 浏览器中，如果用户非常快速地连续开关弹窗，可能会出现状态不同步的问题，这可能会影响后续对 showModal() 的调用。
