浏览器渲染 html 元素与执行 `<script>` 中的 `alert()` 并非按源码顺序“逐行渲染”，而是受解析、执行、渲染三阶段异步机制影响：`alert()` 作为原生 api 会立即阻塞 ui，导致 dom 渲染滞后。</script>
在 HTML 文档中，元素（如 ）和脚本（如 <script>）虽按顺序书写，但它们的处理流程分属不同引擎，<strong>并不共享同一执行时序。具体来说：</script>
- 标签由 HTML 解析器读取并构建 DOM 节点，随后交由 渲染引擎（如 Blink 或 WebKit） 进行布局与绘制——这一过程是渐进式、异步且可中断的；
- <script> 标签中的 JavaScript 代码（如 alert("1")）则由 <strong>JS 引擎（如 V8） 解析执行，而 alert() 本身并非纯 JS 逻辑，而是 <strong>浏览器内核提供的原生同步阻塞 API，它直接调用底层 UI 线程弹出模态对话框，并<strong>强制暂停整个主线程（包括 HTML 解析与页面渲染）。</script>
因此，尽管 1111 出现在 <script> 之前，浏览器仍会在解析到 <script> 时：</script>
- 暂停 HTML 解析；
- 执行 JS 代码；
- 触发 alert() —— 此时 UI 线程被独占，DOM 尚未完成渲染或重绘；
- 用户关闭弹窗后，解析继续，后续 才真正“浮现”在页面上。
这就是为何你观察到“先弹窗、后显示文字”的现象——不是 HTML 渲染慢，而是 alert() 抢占并冻结了渲染通道。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
✅ 解决方案：让渲染“抢跑”于 alert
若需确保 在 alert() 前可见，可利用事件循环机制，将 alert() 推迟到下一个宏任务（macro-task），从而让当前渲染帧有机会提交：
<span>1111</span>
<script>
// ✅ 推迟 alert 至下一个事件循环，允许 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(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）是掌握前端执行时序的关键。<script> 的同步执行与 alert() 的原生阻塞性，决定了它天然“优先于”视觉渲染——这不是 bug，而是设计使然；而通过 setTimeout 等异步调度，我们可主动协调渲染与交互的节奏。</script>
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
