需要明确的是，`dialog` 的 `open` 属性并非简单的布尔开关，它不等同于 `display: block` 或 `visibility: visible`。其中存在一个容易被忽视的陷阱。该属性本质上是“激活态”的触发器：将其设为 `true` 或空字符串，浏览器才会真正激活原生模态行为——自动提升层级、锁定焦点、拦截外部交互。而移除这个属性，才是真正的关闭。如果仅通过 CSS 将对话框隐藏，焦点锁定并不会随之解除：用户无法点击页面其他区域，Tab 键也无法跳出，整个页面仿佛被冻结。
## dialog 元素的 `open` 属性不是布尔开关，而是"激活态"触发器
它不等价于 `display: block` 或 `visibility: visible`。设置 `open` 属性——即便写成 `open=""` 或 `open="true"`——才能激活原生模态行为：浏览器自动提升层级、锁定焦点、拦截外部点击和 Tab 键跳出。移除该属性（`el.removeAttribute('open')` 或 `el.open = false`）才真正关闭。常见的一个错误是使用 `dialog.style.display = 'none'` 隐藏对话框，之后用户仍无法用 Tab 键切换到页面其他元素，控制台虽不报错，但交互已卡死。
- `dialog.open = true` 和 `dialog.setAttribute('open', '')` 效果一致，推荐前者：更语义化，可读性更好。
- `dialog.open = false` 会立即移除 `open` 属性并退出模态状态；`el.removeAttribute('open')` 同样有效，但需要确保属性确实存在。
- 首次显示前无需手动执行 `focus()`，浏览器会在 `open` 设置后自动将焦点移到 `dialog` 内的第一个可聚焦元素（或自身，若无可聚焦子元素）。
## 焦点锁定逻辑依赖 `open` 状态，且默认不包含 `body` 或 `html`
当 `dialog` 处于 `open` 状态时，浏览器原生实现焦点围栏：Tab / Shift+Tab 只在 `dialog` 内部循环，按 Esc 可关闭，点击 backdrop 也可关闭。但这个围栏并不自动排除 `body` 上的事件监听器——如果你在 `body` 上绑了 `keydown` 监听，该监听仍会触发，例如全局快捷键可能干扰模态框行为。
- 必须手动禁用或通过条件判断跳过全局键盘监听，尤其注意除 `Escape` 之外的键（如 `Enter` 触发表单提交）。
- `dialog` 不会接管 `document.activeElement` 的初始值；如果打开前焦点位于某个 input 上，关闭后焦点不会自动回退——需自行保存并恢复。
- 若 `dialog` 内无任何可聚焦元素（比如全是 `div`），焦点会落在 `dialog` 自身，此时按 Tab 会直接跳出——这是浏览器的默认 fallback 行为，并非 bug。
## 层级（z-index）由浏览器隐式管理，不可靠覆盖
`dialog` 在 `open` 状态下会被浏览器插入一个高优先级的伪 backdrop（`::backdrop`），其 z-index 由 UA 样式指定（Chrome 中约为 `2147483647`），远高于常规 CSS 值。试图用 `z-index: 9999` 给父容器强行提层，大概率失败，还可能导致 backdrop 不显示或出现点击穿透。
- 唯一可控的样式入口是 `dialog::backdrop`，可用于调整遮罩背景色或动画，但不能更改 z-index。
- 若页面已存在第三方弹窗库（如 Bootstrap Modal），它们常依靠强制 z-index + body class 控制层级，与 `dialog` 并存时极易冲突——不要混用。
- 移动端 Safari 对 `dialog` 的 backdrop 支持较弱（iOS 16.4+ 才完整），部分机型点击 backdrop 不触发 `close` 事件，需额外监听 `click` 事件判断是否点击在 backdrop 区域。
## 关闭时的焦点归位容易被忽略
关闭 `dialog` 后，浏览器不会自动将焦点还原到打开前的元素。用户从键盘操作进入模态框，关闭后焦点丢失（停留在 body），这对屏幕阅读器和键盘用户极不友好。
- 应在 `dialog.showModal()` 前记录 `document.activeElement`，关闭后调用 `.focus()` 回归该元素。
- 注意元素可能已被移除（如列表项被删除），需做存在性判断，并 fallback 到页面主内容区（如 `main` 或 `h1` 元素）。
- `dialog.close()` 不触发 `focusout`，但会触发 `close` 事件，这是唯一可靠的关闭钩子。
真正棘手的问题不是如何打开，而是如何关闭得干净、焦点不丢失、不与现有逻辑冲突。原生 `dialog` 的约束比想象中更多，尤其在老项目中叠加使用时，细节处理比语法本身更关键。
