如何用 alert confirm 与 prompt 处理最基础的用户交互逻辑

这三种方法是浏览器强制同步阻塞的交互入口，confirm仅返回true或false（无null），prompt返回字符串或null（空串与null不同），alert返回undefined且不可中断。

这三种方法不是“可选”，而是浏览器强制提供的同步阻塞式交互入口——只要调用，JS 执行就停住，页面完全冻结，直到用户点完按钮。别想着绕开这个机制，得顺着它设计逻辑。

confirm 返回布尔值，但 null 不会出现

confirm 只返回 true 或 false，不会返回 null。这点和 prompt 有本质区别，常被误判导致逻辑分支出错。

• 用户点“确定” → 返回 true
• 用户点“取消”或按 Esc → 返回 false
• 不要写 if (result === null) 这类判断，它永远不成立
• 移动端 Safari 在某些 iOS 版本中会把“取消”按钮文字本地化为“取消”，但返回值不变

prompt 的第二个参数不是摆设，IE 和旧版 Edge 会把它当 undefined 渲染

prompt(title, default) 的 default 参数必须显式传，哪怕传空字符串 ''。否则在 IE 或旧版 Edge 中，输入框会显示 undefined 字样，不是留空。

• 正确写法：prompt('用户名', '') 或 prompt('用户名', 'guest')
• 错误写法：prompt('用户名') → IE 显示 “undefined” 文本，用户可能误以为是提示
• 返回值只有两种：用户输入的字符串（含空格），或 null（点取消 / Esc）
• 注意：空字符串 '' 和 null 是不同值，if (input) 会把 '' 当作 false，需用 input !== null 显式判断

alert 没有返回值，但滥用会导致页面卡死

alert 返回 undefined，但它最危险的地方不在返回值，而在它的不可中断性。连续调用多个 alert，用户必须一个个点完，中间无法跳过或关闭全部。

• 调试时慎用：alert 会打断异步流程，比如放在 setTimeout 或 Promise 回调里，容易掩盖真实执行顺序
• 禁止在循环中调用：for (let i = 0; i 会弹出 10 次，且无法批量关闭
• 移动端上，部分 Android 浏览器会把连续 alert 合并或静默丢弃，行为不一致
• 替代方案：开发阶段用 console.log，上线前删掉所有 alert，真要提示请用 DOM 自定义弹层

真正难处理的不是语法，而是它们对执行流的绝对控制——你没法监听关闭事件，没法加 loading，没法阻止重复触发。一旦进入 prompt，连 beforeunload 都被挂起。所以别试图“增强”它们，该用就用，该换就得换。