在 HTML 文档中，元素（如 ）和脚本（如
- 标签由 HTML 解析器读取并构建 DOM 节点，随后交由 渲染引擎（如 Blink 或 WebKit） 进行布局与绘制——这一过程是渐进式、异步且可中断的；
因此，尽管 1111 出现在
- 暂停 HTML 解析；
- 执行 JS 代码；
- 触发 alert() —— 此时 UI 线程被独占，DOM 尚未完成渲染或重绘；
- 用户关闭弹窗后，解析继续，后续 才真正“浮现”在页面上。
这就是为何你观察到“先弹窗、后显示文字”的现象——不是 HTML 渲染慢，而是 alert() 抢占并冻结了渲染通道。
✅ 解决方案：让渲染“抢跑”于 alert
若需确保 在 alert() 前可见，可利用事件循环机制，将 alert() 推迟到下一个宏任务（macro-task），从而让当前渲染帧有机会提交：
立即学习“Java免费学习笔记（深入）”；
1111 22222 Hello World
? 提示：setTimeout(fn, 0) 并非精确 0ms 延迟，而是将回调注册为宏任务，确保其在当前执行栈清空、渲染帧更新之后运行。实践中 1–10ms 延迟（如 setTimeout(..., 1)）更稳妥，尤其在低端设备上。
⚠️ 注意事项与替代建议
- alert() 已被现代 Web 开发普遍弃用：它破坏用户体验（强制中断、无法样式化、不支持异步）、阻碍自动化测试，且在某些上下文（如 iframe 或弹窗拦截策略下）可能被静默屏蔽；
- 更优实践：使用非阻塞 UI 组件，例如自定义 modal、console.log 调试，或 Promise + await 模拟等待（配合 requestAnimationFrame 实现渲染后回调）；
- 若需调试 DOM 状态，推荐 console.log(document.body.innerHTML) 或开发者工具的 Elements 面板实时观察，而非依赖 alert()。
总之，理解浏览器多引擎协作模型（HTML Parser / JS Engine / Renderer）是掌握前端执行时序的关键。
