在 Web 开发实践中，一个看似直观的预期是：html 元素按源码顺序逐个解析、渲染，随后才执行其后的 。但当你运行如下代码时，实际行为却令人困惑：
1111 22222 Hello World 你会发现：所有 alert() 对话框先于任何 文本出现在页面上——即使 标签写在
浏览器并非单线程“流水线”，而是多引擎协作系统
现代浏览器（如 chrome、firefox）内部由多个独立但紧密协作的子系统组成：
- HTML 解析器：负责将 HTML 字节流转换为 DOM 树（同步、逐步构建）；
- css 引擎：解析样式并构建 CSSOM；
- 渲染引擎（如 Blink/Gecko）：合并 DOM + CSSOM 生成渲染树，进行布局（Layout）与绘制（Paint）；
- javaScript 引擎（如 V8）：执行 js 代码，但不直接负责 ui 渲染；
- 浏览器核心（Native Layer）：用 c++ 实现，管理窗口、事件循环、原生 API（如 alert、confirm、setTimeout）等。
关键点在于：alert() 并非 javascript 语言内置函数，而是 window 对象提供的原生 API，由浏览器核心直接调用。当 JS 引擎执行到 alert(“1”) 时，它立即向浏览器核心发起同步阻塞调用——该调用会：
立即学习“Java免费学习笔记（深入）”；
- 暂停 JS 执行线程；
- 阻塞整个主线程（包括 HTML 解析与渲染更新）；
- 弹出模态对话框，强制用户交互；
- 此时 DOM 树虽已部分构建（1111 已入 DOM），但尚未完成渲染（Paint），因为渲染任务被挂起，等待 alert 关闭后才继续。
因此，你看到的不是“ 没执行”，而是“ 已解析入 DOM，但未绘制到屏幕”——这是渲染滞后（render lag），本质是JS 同步阻塞导致渲染管线中断。
✅ 正确解法：用 setTimeout 让出渲染时机
要确保 先渲染再弹窗，需将 alert 推迟到下一个宏任务（macro-task），从而让浏览器有机会完成当前微任务队列后的渲染更新。推荐方案如下：
1111 22222 Hello World ? 为什么 setTimeout(…, 0) 有效？ 尽管延迟为 0，setTimeout 仍会将回调放入任务队列（Task Queue），等待当前执行栈清空、且浏览器完成本次渲染（即 requestAnimationFrame 后、下一帧前）。此时 DOM 已就绪，渲染引擎会自然绘制 内容，之后才执行 alert。
⚠️ 注意事项与最佳实践
- alert 是强阻塞 API，应避免在生产环境使用，尤其不可用于调试 DOM 状态；
- 若需调试渲染结果，优先使用 console.log(document.body.innerHTML) 或开发者工具 Elements 面板；
- 真实项目中，UI 更新应通过状态驱动（如 react/vue 的响应式更新）+ requestAnimationFrame 优化；
- setTimeout(…, 0) 并非精确计时，而是“尽快在下一轮事件循环执行”，这是跨浏览器兼容的可靠模式。
总结
HTML 标签的“执行”分两阶段：解析（Parsing）→ 渲染（Rendering）；而