如何在显示 alert 前强制浏览器刷新界面？

在 javascript 中，alert 会阻塞主线程并阻止渲染，导致 dom 更新（如棋子移动）无法及时呈现在屏幕上。解决方法是利用 requestanimationframe 延迟 alert 至下一帧渲染之后执行，确保视觉更新先完成。

在开发棋类网页（如国际象棋）时，一个常见痛点是：当玩家走完决定性一步后，程序立即调用 alert(‘Black wins!’)，但浏览器却未显示该步的棋子位置变化——直到用户关闭弹窗，画面才“闪现”更新。这是因为 alert() 是同步阻塞操作，它会暂停 javaScript 执行和页面渲染，而浏览器的 DOM 修改（例如更新 的 src 或修改 className）虽已生效，却尚未被绘制到屏幕上。

根本原因在于：浏览器的渲染流程（样式计算 → 布局 → 绘制 → 合成）与 js 执行是分离的，且只有在 JS 调用栈清空后，才会进入下一帧的渲染周期。alert() 把 JS 线程卡死，渲染线程自然无法推进。

✅ 正确解法：使用 requestAnimationFrame() 将 alert 推迟到下一帧绘制之前执行（注意：不是“之后”，而是“在绘制前触发，确保此前所有 DOM 变更已被纳入当前帧渲染队列”）。由于 alert 本身会中断后续帧，我们需将其置于 rAF 回调中，让浏览器有足够时间完成当前帧的渲染准备：

// ✅ 推荐写法：等待 1 帧，确保 DOM 更新可见后再弹窗 function showWinAlert(message) {   requestAnimationFrame(() => {     alert(message);   }); }  // 在胜负判定逻辑末尾调用 if (isCheckmate()) {   updateBoardui(); // 已更新棋盘 DOM   showwinAlert(`${winner} wins!`); }

⚠️ 注意事项：

• 不要使用 setTimeout(…, 0)：它仅将任务推入宏任务队列，无法保证在渲染前执行，可能跨多帧，延迟不可控；
• 避免嵌套多层 rAF：本例只需 1 帧延迟，requestAnimationFrame(() => alert(…)) 已足够；
• 现代替代方案：强烈建议用非阻塞 UI（如模态框
  或自定义 toast）替代 alert，既可完全避免阻塞，又能保持交互一致性；
• 兼容性：requestAnimationFrame 在所有现代浏览器中均受支持（IE10+），无需 polyfill。

总结：requestAnimationFrame 是协调 JS 逻辑与浏览器渲染节奏的关键 API。面对“更新了 DOM 却看不到”的问题，优先考虑是否需要让出渲染控制权——而非猜测事件循环细节。一帧之隔，便是视觉反馈是否及时的分水岭。