在 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（如模态框
- 兼容性：requestAnimationFrame 在所有现代浏览器中均受支持（IE10+），无需 polyfill。
总结：requestAnimationFrame 是协调 JS 逻辑与浏览器渲染节奏的关键 API。面对“更新了 DOM 却看不到”的问题，优先考虑是否需要让出渲染控制权——而非猜测事件循环细节。一帧之隔，便是视觉反馈是否及时的分水岭。
