html弹窗无法真正强制不可关闭，所有绕过用户控制的方案均不可靠且违反可访问性标准；window.close()仅对同源且用户激活打开的窗口有效，移动端尤其受限；合规做法是用配合close事件校验并重显，强化视觉与交互设计而非技术封锁。
没有真正“强制不可关闭”的 HTML 弹窗。所有声称“关不掉”的方案，要么违反浏览器安全策略、被拦截，要么在特定条件下失效（尤其是移动端）。强行绕过用户控制，既不可靠，也违反可访问性与 WCAG 标准。
为什么 window.close() 在多数场景下根本不起作用
浏览器只允许脚本关闭由当前页面用 window.open() 主动打开、且未导航到其他域名的窗口。常见失效场景：
- 弹窗后跳转到外部 URL（如
popup.location.href = 'https://example.com'），再调window.close()→ 触发同源限制，静默失败 - 在
fetch回调、setTimeout或页面加载完成（DOMContentLoaded）后才调window.open()→ 被标记为“非用户激活”，直接被 Chrome/Firefox/Safari 拦截，控制台报Blocked opening 'xxx' in a new window because the request was made without user activation. - iOS Safari 完全禁用脚本调用
window.close()，无论怎么构造，都无效
dialog 元素的 close 事件不能被阻止，但可以控制逻辑
<dialog></dialog> 的 close 事件是可监听的，但无法真正阻止关闭动作本身（比如按 Esc、点 backdrop、调 dialog.close()）。试图用 event.preventDefault() 或 stopPropagation() 拦截，会导致键盘和屏幕阅读器行为异常。
实操建议：
- 把业务校验逻辑放在
dialog.addEventListener('close', handler)里，而不是拦截关闭 - 如果校验不通过，可立即重新调用
dialog.showModal()—— 这是唯一合规的“挽留”方式 - 别删掉关闭按钮或隐藏
::backdrop，否则会破坏焦点管理与无障碍支持 - 降级兼容旧浏览器时，用
<div role="dialog" aria-modal="true"> 替代，并手动处理 <code>Esc和 backdrop 点击所谓“强提醒”，本质是视觉+交互强化，不是技术封锁
真正可用的强提醒，靠的是设计约束，而非技术封锁：
- 遮罩层背景设为深灰+高透明度（如
rgba(0,0,0,0.85)），内容区加阴影和边框，确保视觉压倒主页面 - 弹窗内不提供“取消”按钮，只放“确认”或“已知晓”，按钮文字明确（如“我已阅读并同意”）
- 首次弹出时禁用页面滚动（
document.body.style.overflow = 'hidden'），关闭后恢复 - 移动端必须适配：避免固定宽高，改用
max-width: 90vw+margin: clamp(1rem, 5vh, 2rem) auto，防止小屏溢出 - 焦点必须自动落入弹窗内第一个可聚焦元素（
dialog.querySelector('button, input, [tabindex]')），关闭后还给触发源
最易被忽略的一点：任何“强提醒”若没做焦点管理和
aria-hidden切换，对使用读屏软件的用户就是不可用的——这不仅是体验问题，更是法律风险点。 - 遮罩层背景设为深灰+高透明度（如
