open 属性仅控制 <dialog> 可见性，不触发模态行为；它不生成遮罩、不锁定焦点、不响应 Esc，也不触发 close 事件，仅将 display 改为 block。
open 属性不是“默认弹窗开关”，它只让 <dialog> 元素可见，不激活任何模态行为——写了 <dialog open> 却没遮罩、Esc 无反应、背景能滚动，这完全正常，不是 bug。
为什么 open 不等于“一进页面就弹出来”
open 是纯渲染控制属性：浏览器解析 HTML 时，若遇到 open，会把 <dialog> 的 display 从 none 改为 block，仅此而已。它不触发以下任一行为：
-
::backdrop不生成（灰色遮罩根本不存在） - 焦点不会锁定在 dialog 内，Tab 键照常穿透到背景元素
-
Esc按键监听未注册，按下毫无反应 -
close事件不会被触发（因为没真正“打开”，只是“露出来”） - 移动端 Safari（iOS 16.3 及更早）直接忽略
open，渲染成普通<div>
open 的合法写法和 DOM 操作陷阱
open 是布尔属性，HTML 中写成 <dialog open>、<dialog open=""> 或 <dialog open="open"> 效果一致；XHTML 中必须用 open="open"。
但 JS 操作时极易误用：
-
dialog.open = true只设置 DOM 属性，**不会显示元素**（除非原本就有open属性） -
dialog.open = false不会隐藏元素，也不移除遮罩（因为本来就没有） -
dialog.hasAttribute('open')才是判断是否带open属性的可靠方式，dialog.open返回的是布尔值，但不可控显隐 - 想用 JS 控制开关，请用
dialog.showModal()或dialog.close()，别碰open属性
什么时候该用 open，什么时候必须写 JS
open 唯一合理场景是：无 JS 环境下的降级展示，或服务端渲染（SSR）后需要“先看见再交互”的静态 fallback。
- GDPR 弹窗、维护提示页等需强制用户首屏看到内容，且可接受无遮罩/无焦点管理时，
<dialog open>是唯一不依赖 JS 的方案 - 只要要求“真正模态”（锁背景、Esc 关闭、焦点捕获、屏幕阅读器支持），就必须调用
showModal() - 调用时机很关键：
showModal()必须在 DOM 就绪后执行，DOMContentLoaded是安全底线，放在<script>标签内直接调用大概率失败 - 不要试图用 CSS 强行覆盖：
display: block对<dialog>无效，浏览器硬编码了渲染逻辑
真正麻烦的不是怎么写 open，而是误以为写了它就万事大吉——它解决的是“能不能看见”，而用户要的是“能不能用”。模态交互的完整性，JS 调用绕不开，且必须处理好浏览器兼容和 DOM 就绪时机。
