window.alert() 是唯一能绝对阻塞脚本执行的原生方式，因其会挂起主线程、暂停 dom 渲染与事件监听，仅适用于删除不可逆数据等必须中断流程的极少数场景，其余情况应避免使用。
window.alert() 是唯一能实现「绝对阻塞、强制用户确认」的原生方式，但它的业务适用性极窄——只适合必须中断流程、且无交互分支的单向通知，比如关键操作前的最终确认（如删除不可逆数据）、系统级错误兜底提示。其他场景用它，大概率会引发用户反感或被浏览器拦截。
为什么 window.alert() 一定阻塞脚本执行
调用后整个主线程挂起：DOM 渲染停、事件监听停、定时器暂停、后续 JS 行完全不执行，直到用户点“确定”。这不是 UI 层面的遮罩，是浏览器内核级同步锁。
- 常见错误现象：
window.alert('提交中...');后接fetch()，结果是请求根本没发出去，用户点了确定才开始发 - 调试时容易误判：以为代码卡在某处，其实是被 alert 拦住了
- 在
setTimeout或 Promise 回调里用，依然阻塞——阻塞的是调用时刻所在的执行上下文，和异步无关
window.alert() 的参数与内容限制
只接受一个参数，类型会被强制转为字符串。传对象、数组、null、undefined 都会触发 .toString()，结果可能出人意料。
- 传
{msg: 'error'}→ 显示[object Object] - 传
['a', 'b']→ 显示a,b - 想显示多行？用
\n，但部分移动端浏览器会忽略换行符 - 不支持 HTML 标签，
window.alert('<strong>危险</strong>')会原样输出字符串，不会加粗
哪些业务场景真该用 window.alert()，哪些不该
该用的极少，但存在：后台检测到用户本地时间严重偏差（影响 token 签名），必须中断登录流程；或表单提交前发现必填字段为空，且页面已禁用所有按钮、无法通过其他方式阻止提交。
- 不该用的典型：「保存成功」——应该用非阻塞 toast
- 不该用的典型：「是否删除？」——应该用
window.confirm()，它返回布尔值可分支处理 - 不该用的典型：需要用户输入反馈——必须用
window.prompt()或自定义输入弹窗 - 移动端尤其谨慎：iOS Safari 和部分安卓 WebView 会静默拦截或折叠 alert，用户根本看不到
真正难的不是怎么调用 window.alert()，而是判断「此刻是否真的值得冻结整个页面」。多数所谓“重要通知”，其实只是开发者对用户注意力的误判——留白、颜色、动效、焦点控制，往往比强行弹窗更有效，也更尊重用户控制权。
