不过，想用好它，有几个关键点必须注意：

• 务必使用showModal()方法来打开弹窗。如果只是简单地设置open属性，弹窗将失去模态特性，背后的内容依然可以操作。
• 点击弹窗外的灰色遮罩（backdrop）默认会关闭弹窗，但前提是
  必须是的直接子元素。如果嵌套在其他容器里，遮罩可能无法正常渲染。
• 关闭弹窗时，close()方法会触发close事件，方便你进行后续清理；而按Esc键或点击遮罩关闭，则会触发cancel事件。
• 需要注意浏览器支持度。Safari从15.4版本才开始完整支持，更老的版本可能需要额外添加dialog::backdrop样式来补全遮罩效果。

  
这是弹窗内容
  确定


打开弹窗

用 CSS + Ja vaScript 模拟弹窗（兼容性兜底）

当项目需要兼容IE或者较老版本的Safari时，我们就得退一步，手动搭建一套弹窗系统。这不仅仅是显示和隐藏一个div那么简单，它考验的是对交互完整性的把控。

• 遮罩层：必须使用position: fixed并设置足够高的z-index来覆盖页面内容，宽高通常设为100vw和100vh。
• 弹窗定位：同样建议使用position: fixed进行居中，这样可以避免受到父容器transform或overflow属性的影响，导致定位偏移。
• 焦点管理：这是最容易忽略的一环。弹窗打开后，必须用focus()方法将焦点移动到弹窗内的第一个可交互元素上，并且要拦截Tab键，让焦点在弹窗内部循环，而不是跳回背景页面。
• 键盘交互：监听keydown事件来实现Esc关闭功能时，要格外小心，避免干扰弹窗内输入框的正常行为（比如用户可能想用Esc清空搜索框）。

示例关键逻辑：

立即学习“前端免费学习笔记（深入）”；

function openModal() {
  document.getElementById('overlay').style.display = 'block';
  const modal = document.getElementById('customModal');
  modal.style.display = 'block';
  modal.querySelector('button, input')?.focus();
}

阻止背景滚动但保留弹窗内滚动

弹窗打开后，如果用户滚动鼠标或滑动屏幕，导致背景页面也跟着滚动，体验会非常割裂。但简单地给body加上overflow: hidden，又会把弹窗内部的长内容滚动也一并禁掉。

怎么解决这个矛盾？业内常用的思路是：

• 在打开弹窗前，先记录下body当前的scrollTop值，然后给body设置position: fixed; top: -${scrollTop}px。这样页面就被“钉”在了当前位置。
• 关闭弹窗时，再恢复body的position为static，并手动将scrollTop设置回之前记录的值。
• 还有一种更稳妥的方案：只给body设置overflow: hidden来禁止背景滚动，同时为弹窗容器设置overflow-y: auto和一个固定的最大高度，让其内部可以独立滚动。
• 在移动端，尤其是Safari上，position: fixed有时会表现异常，可能需要额外添加touch-action: none来防止拖拽动作穿透到背景页面。

为什么不用 alert() / confirm()

可能有人会问，既然浏览器自带了alert()和confirm()，为什么还要大费周章地自定义弹窗呢？原因很简单：它们太“原始”了，与现代Web开发的需求格格不入。

• 它们是阻塞式的，对话框弹出期间，整个页面的Ja vaScript执行都会被冻结，用户体验极差。
• 样式和内容完全不可定制，无法融入你的设计体系，也无法承载复杂的交互结构或动画效果。
• 在现代前端框架（如React、Vue）中，它们无法与组件状态流集成，alert()甚至不提供“取消”的选项。
• 在移动端Safari等环境中，confirm()的按钮文案可能不受控制，出现中英文混杂的尴尬情况。
• 浏览器出于用户体验考虑，正在逐步限制这些原生对话框的调用频率，频繁触发可能导致被静默拦截。
• 最重要的是，它们完全不具备可访问性（A11Y）支持。而自定义弹窗可以方便地添加aria-modal="true"、aria-labelledby等属性，让屏幕阅读器用户也能感知到弹窗的存在和内容。

说到底，实现一个弹窗，难点从来不在让它“显示出来”。真正的挑战在于那些看不见的细节：精细的焦点管理、无感的滚动锁定、闭环的键盘导航，以及对屏幕阅读器的友好支持。漏掉其中任何一环，都可能导致用户“卡”在某个交互环节，而开发者却浑然不觉。这才是衡量一个弹窗是否合格的关键所在。