本文深入剖析浏览器中 html 渲染与 `<script>` 同步执行的底层机制，解释为何 `alert()` 会阻塞 dom 渲染、导致 `<span>` 等元素延迟显示，并提供可落地的异步延时解决方案。</script>
在 Web 开发实践中，一个看似直观的预期是：HTML 元素按源码顺序逐个解析、渲染，随后才执行其后的 <script> 中的逻辑</script>。但当你运行如下代码时，实际行为却令人困惑：
<body>
<span>1111</span>
<script> alert("1"); </script>
<span>22222</span>
<script> alert("2"); </script>
<span>Hello World</span>
<script> alert("Hello World"); </script>
</body>你会发现：所有 alert() 对话框先于任何 文本出现在页面上——即使 标签写在 <script> 之前。这不是浏览器 Bug，而是由浏览器多引擎协同工作模型决定的。</script>
浏览器并非单线程“流水线”，而是多引擎协作系统
现代浏览器（如 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免费学习笔记（深入）”；
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- 暂停 JS 执行线程；
- 阻塞整个主线程（包括 HTML 解析与渲染更新）；
- 弹出模态对话框，强制用户交互；
- 此时 DOM 树虽已部分构建（1111 已入 DOM），但尚未完成渲染（Paint），因为渲染任务被挂起，等待 alert 关闭后才继续。
因此，你看到的不是“ 没执行”，而是“ 已解析入 DOM，但未绘制到屏幕”——这是渲染滞后（render lag），本质是JS 同步阻塞导致渲染管线中断。
✅ 正确解法：用 setTimeout 让出渲染时机
要确保 先渲染再弹窗，需将 alert 推迟到下一个宏任务（macro-task），从而让浏览器有机会完成当前微任务队列后的渲染更新。推荐方案如下：
<span>1111</span>
<script>
// 使用 setTimeout 将 alert 推迟到下一个事件循环周期
// 即使 delay 设为 0，也能确保 DOM 渲染完成后再执行
setTimeout(() => alert("1"), 0);
</script>
<span>22222</span>
<script>
setTimeout(() => alert("2"), 0);
</script>
<span>Hello World</span>
<script>
setTimeout(() => alert("Hello World"), 0);
</script>? 为什么 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）；而 <script> 中的 alert() 属于<strong>同步原生调用，直接劫持主线程，导致渲染被挂起。理解浏览器多引擎分工（HTML 解析器 ≠ 渲染引擎 ≠ JS 引擎 ≠ 浏览器核心）是解开此类疑惑的关键。通过 setTimeout 主动让出控制权，即可优雅实现“先见内容，后弹提示”的预期效果——这不仅是技巧，更是对浏览器运行时本质的尊重与驾驭。</script>
