弹层大概是前端被重复实现最多的一种组件。每个项目上来第一件事就是拉一个 Modal 组件库，或者自己写一套：绝对定位的遮罩层、手动加的 z-index、监听 Esc 的键盘事件、点击遮罩关闭、打开时给 body 加 overflow: hidden，关闭时再删掉。写完还要处理焦点——点开弹窗之后按 Tab，焦点跑到弹窗后面的页面元素上去了，于是再补一段 intercept Tab 键的代码。
这些代码本身没问题，问题在于它们本来不该由我们写。浏览器早就有了 <dialog> 元素，后面又补上了 popover 属性，两者合起来基本能把日常遇到的弹层需求覆盖完。这篇文章不讲概念罗列，直接把两种东西的分工讲清楚，然后用一个完整的删除确认流程把它们串起来，最后把我在实际项目里踩到的坑都摊开说。
一、先分清两种弹层：要不要打断用户
选型的问题只有一个：这个弹层出现的时候，用户还能不能操作页面的其他部分。
不能操作，就是模态弹层。典型场景是删除确认、表单填写、登录框。这类需求交给 dialog 的 showModal()，浏览器会自动帮你做三件事：把元素提升到顶层渲染、给页面其余部分加上 inert 使其不可交互、把焦点锁在弹窗内部并在关闭后还给触发它的按钮。
还能操作，就是非模态浮层。典型场景是下拉菜单、气泡提示、操作面板。这类交给 popover 属性。它也会提升到顶层，但不会阻断页面，也不会抢焦点。
这个划分方法比记 API 有用得多。很多人一上来就问「dialog 和 popover 哪个更好」，其实它们解决的是两个不同的问题，混着用才是常态。
二、dialog 的三种打开方式
<dialog> 默认是隐藏的，它的默认样式里写着 display: none。打开它有三种方式，行为差别不小。
方式一：加 open 属性。这是最原始的方式，效果等同于一个普通的 display: block 的盒子。它不在顶层，会被父元素的 overflow: hidden 裁掉，也不会阻断页面交互。日常基本用不上，唯一的价值是给不支持 JS 的环境做降级展示。
方式二：show()。非模态打开，元素进到顶层，不会被裁剪，但页面其他部分照常可以点击，焦点也不会被限制。适合做那种「一边看着一边操作」的面板。
方式三：showModal()。这才是绝大多数人想要的那个。顶层渲染、页面 inert、焦点圈定、Esc 关闭、出现 ::backdrop 伪元素。
这里有个很容易忽略的细节：对一个已经打开的 dialog 再次调用 showModal()，浏览器会直接抛 InvalidStateError。如果你的触发按钮没有做防重复点击，用户手快连点两下，控制台就一片红。我在项目里的固定写法是：
function openConfirm() {
if (dialog.open) return;
dialog.showModal();
}三、用表单把用户的选择接住
确认弹窗无非是「取消」和「确定」两个结果。传统做法是给两个按钮各绑一个 click 监听，然后手动调 close()。其实 <form method="dialog"> 可以直接把这个流程吃掉。
<dialog id="confirm" aria-labelledby="confirm-title">
<h2 id="confirm-title">确定删除这个项目吗？</h2>
<p>删除后 30 天内可以在回收站找回。</p>
<form method="dialog">
<button value="cancel">取消</button>
<button value="confirm">删除</button>
</form>
</dialog>带 method="dialog" 的表单，提交时不会发请求，而是直接关闭自己所在的 dialog，并且把被点击按钮的 value 写进 dialog.returnValue。监听一个 close 事件就能拿到结果：
dialog.addEventListener('close', () => {
if (dialog.returnValue === 'confirm') {
doDelete();
}
});比绑两个监听清爽得多，而且按钮的语义也没跑偏——它本来就是提交表单。
但是这里有个坑，我在这上面浪费过半个下午。returnValue 是有记忆的。用户第一次点了「删除」，然后点了「取消」，代码逻辑没问题；但如果用户是按 Esc 关掉的，returnValue 会保留上一次的值——也就是 'confirm'。结果就是用户以为取消了，数据却被删了。
解决办法很简单，每次打开之前清一次：
trigger.addEventListener('click', () => {
dialog.returnValue = ''; // 必须清，否则 Esc 关闭会沿用旧值
dialog.showModal();
});更稳妥的做法是再加一层判断，监听 cancel 事件（Esc 触发时先派发 cancel，再派发 close），在里面显式把 returnValue 设成空。两条一起做，基本不会有漏网。
四、popover：轻量浮层的正确姿势
popover 是个全局属性，写在元素上就生效，配套一个 popovertarget 加在触发按钮上。
<button popovertarget="actions" type="button">更多操作</button>
<div id="actions" popover="auto">
<button type="button">重命名</button>
<button type="button">复制链接</button>
<button type="button">移动到</button>
</div>这段代码不需要一行 JS。点击按钮打开，再点一次关闭，点页面其他地方关闭，按 Esc 关闭。浏览器全包了。
popover 有两个值，区别很关键：
popover="auto"：轻量关闭。点击外部、按Esc都会关掉它。并且同一时刻页面上只能有一个 auto 类型的 popover 处于打开状态——打开新的会自动关掉旧的。这正是下拉菜单想要的互斥行为。popover="manual"：不做任何自动关闭。只能通过 JS 或者popovertarget主动关闭。适合做那种会停留一段时间的 toast，或者需要用户明确处理的提示条。
注意 popover 不会锁焦点，也不会让页面 inert。所以它只适合那种「看一眼就走」的内容。如果你的浮层里是一个需要填写的表单，请老老实实用 dialog。
还有一个容易被忽略的点：popover 元素默认在顶层，也就是说页面上任何 z-index 都对它无效了。这是好事，不用再为层级打架；但如果你之前靠 z-index 把某个东西盖在浮层上面，现在会失效，需要重新想想结构。
五、closedby 和 commandfor：把剩下的 JS 也拿掉
有两个比较新的属性值得关注，它们把过去必须写 JS 的两个动作变成了纯声明。
第一个是 closedby，加在 dialog 上。它让模态弹窗也能拥有 popover 那种轻量关闭的行为：
<dialog id="sheet" closedby="any">
<p>点击外部区域也能关闭这个面板。</p>
</dialog>三个取值：any（Esc 和点击外部都关）、closerequest（只响应 Esc，这是默认行为）、none（都不响应，必须由代码控制）。none 这个值在做「必须做出选择才能继续」的强制确认时特别有用。
第二个是 commandfor 配 command，加在按钮上。它相当于把 popovertarget 的能力推广到了所有可以命令的元素：
<button commandfor="confirm" command="show-modal">删除项目</button>
<dialog id="confirm">...</dialog>常用的 command 取值有 show-modal、close、request-close、toggle-popover、show-popover、hide-popover。写出来确实好看，一个按钮加一个属性就把事办了。
这两组特性的浏览器支持还在铺开的过程中，比 dialog 和 popover 要新。所以我的建议是：用在锦上添花的地方，不要用它承载唯一路径。比如删除确认这种必须能打开的功能，还是写一行 JS 调 showModal()，把 commandfor 留给那些「不支持也不影响主流程」的次要操作。这样既享受了新特性，又不会在旧浏览器上翻车。
六、完整案例：删除确认 + 撤销提示
把上面这些东西拼成一个真实流程。用户点删除，弹模态确认；确认后条目从列表消失，右下角浮出一个带「撤销」的提示条。
HTML 部分：
<button id="del-trigger" type="button">删除项目</button>
<dialog id="confirm" aria-labelledby="confirm-title">
<h2 id="confirm-title">确定删除吗？</h2>
<p>删除后 30 天内可以在回收站找回。</p>
<form method="dialog">
<button value="cancel" autofocus>取消</button>
<button value="confirm">删除</button>
</form>
</dialog>
<div id="undo-toast" popover="manual">
<span>已删除 1 个项目</span>
<button id="undo-btn" type="button">撤销</button>
</div>这里给「取消」加了 autofocus，是有意为之。危险操作弹窗的默认焦点不该落在破坏性按钮上，因为用户很可能习惯性地按回车确认，那个回车本来是冲着上一个动作去的。
JS 部分：
const dialog = document.getElementById('confirm');
const toast = document.getElementById('undo-toast');
let pendingId = null;
let undoTimer = null;
document.getElementById('del-trigger').addEventListener('click', () => {
dialog.returnValue = '';
dialog.showModal();
});
dialog.addEventListener('close', () => {
if (dialog.returnValue !== 'confirm') return;
pendingId = collectSelectedId();
markAsDeleted(pendingId);
toast.showPopover();
clearTimeout(undoTimer);
undoTimer = setTimeout(() => {
toast.hidePopover();
pendingId = null;
}, 8000);
});
document.getElementById('undo-btn').addEventListener('click', () => {
if (pendingId) restoreItem(pendingId);
clearTimeout(undoTimer);
toast.hidePopover();
pendingId = null;
});提示条用 manual 而不是 auto，因为它不该被一次无关的点击顺手关掉——用户还没来得及看那个「撤销」按钮呢。关闭的时机由我们自己用定时器控制。
另外注意 showPopover() 和 hidePopover() 这两个方法。对应的还有一个 togglePopover()，以及 beforetoggle / toggle 两个事件，用来做入场出场动画的时机控制。
七、几个必须提前知道的坑
1. display 被覆盖，dialog 永远显示
很多人想让弹窗内容用 flex 布局，顺手写：
dialog { display: flex; }然后发现页面一加载弹窗就明晃晃地摆在那儿，关不掉。原因是这行规则把 <dialog> 默认的 display: none 直接覆盖了，浏览器不再认为它是关闭状态。正确写法是限定在打开时：
dialog[open] { display: flex; }这个坑之所以常见，是因为它看起来太自然了。
2. 入场动画需要 @starting-style
给 dialog 加过渡时，直接写 transition 是没反应的。原因在于元素从 display: none 变成显示的那一帧，浏览器没有「上一帧的样式」作为过渡起点，所以动画不会触发。@starting-style 就是用来补上这个起点的：
dialog[open] {
opacity: 1;
translate: 0 0;
transition: opacity .18s ease, translate .18s ease;
}
@starting-style {
dialog[open] {
opacity: 0;
translate: 0 1rem;
}
}
dialog::backdrop {
background: rgb(0 0 0 / 0.4);
transition: background .18s ease;
}
@starting-style {
dialog::backdrop {
background: rgb(0 0 0 / 0);
}
}遮罩层的淡入需要单独写一份 @starting-style，因为 ::backdrop 和 dialog 本身是两个独立的渲染对象。这一点很容易漏，漏了的表现就是「弹窗有动画，但遮罩是硬切上去的」。
3. showModal 不会锁住页面滚动
这是很多人以为浏览器会帮忙、实际并不会的一件事。模态弹窗打开后，鼠标滚轮照样能滚动背后的页面。overflow: hidden 得自己加，而且要注意加上之后页面会因为滚动条消失而横向跳动一下，通常需要配合 scrollbar-gutter: stable 来稳住。
4. 多层弹窗的堆叠顺序
如果在 dialog 里面又开了一个 dialog，两个都会在顶层，后开的盖在上面。按 Esc 只会关掉最上面那个，这符合直觉。但 ::backdrop 会叠两层，颜色叠加后会比单层深很多。如果你的设计稿只按单层遮罩配的色，多层场景下会明显偏暗，需要提前留意。
5. 焦点归还
showModal() 关闭后，浏览器会把焦点还给打开它的那个元素。但如果你在 close 事件里删掉了触发按钮——比如删完这一行，整行的 DOM 都没了——焦点就会掉到 body 上，键盘用户会瞬间迷失位置。这种情况下需要手动指定一个落点，比如列表里的下一项。
八、顺手检查可访问性
原生元素帮你做了不少，但有几件事它做不了。
第一，给 dialog 加上 aria-labelledby 指向它的标题元素。屏幕阅读器进入弹窗时需要念出它是什么，光有个标题文字是不够的。
第二，popover 的内容如果是菜单或列表，该有的 role 还得补。popover 只负责显示和隐藏，不负责语义。
第三，如果 dialog 里的内容很长需要滚动，确保内部滚动区域是可以被键盘聚焦的，否则键盘用户滚不动。给那个容器加上 tabindex="0"。
九、什么情况下别用它们
原生 dialog 和 popover 不是万能的，有两种场景我仍然会选择组件库或者自研方案。
一是需要复杂定位的场景。比如一个气泡要精确吸附在某个元素旁边，还要根据视口边缘自动翻转方向。dialog 和 popover 都只提供居中或基础定位，偏移和翻转让位得靠 CSS Anchor Positioning，而它的支持面更窄，实际项目里可能还是引入定位库更省事。
二是需要脱离当前文档的场景。原生弹层永远在当前文档的顶层，跨 iframe 是无能为力的。
写在最后
把滚动锁、焦点管理、Esc 监听、遮罩点击这些事交还给浏览器之后，弹层这块代码量能砍掉一大半。剩下的部分主要是业务逻辑本身——什么时候打开、打开之后做什么、用户选了哪个结果。这才是应该花时间的地方。
如果你手上正好有个还在用自研 Modal 的老项目，其实不用大改。挑一个最简单的确认弹窗试水，把 dialog 换上去跑一遍，走通了再逐步替换。风险很小，收益挺直观的。
