浏览器按 html 文档顺序解析和执行，但 `<script>`（尤其是 `alert()`）会阻塞渲染，导致脚本逻辑先于视觉元素呈现——这并非优先级“错乱”，而是浏览器多引擎协同下的同步阻塞行为。</script>
在 HTML 渲染流程中，浏览器并非“单线程逐行绘制”，而是由多个子系统协同工作：HTML 解析器负责构建 DOM 树，CSS 引擎计算样式，渲染引擎（如 Blink/WebKit） 负责布局与绘制，而 JavaScript 引擎（如 V8） 则同步执行脚本。关键在于：当遇到 <script> 标签（尤其是内联、未加 async 或 defer 的脚本）时，HTML 解析会<strong>暂停，等待脚本完全执行完毕后才继续解析后续 HTML —— 这就是所谓的 <strong>parser-blocking behavior。</script>
而 alert() 是一个由浏览器原生实现的 同步阻塞式 API，它直接调用底层 UI 线程弹出模态对话框，并强制冻结整个页面的渲染更新（包括 DOM 绘制、样式应用、重排重绘）。因此，即使 1111 在源码中位于 <script> 之前，它虽已被解析并插入 DOM，却<strong>尚未完成渲染上屏；一旦 JS 执行到 alert("1")，UI 线程立即被抢占，渲染队列被挂起，用户便先看到弹窗，待点击确认后，浏览器才恢复渲染流程，将已存在的 <span> 元素真正绘制出来。</script>
✅ 验证这一点的简单方式是使用 console.log 替代 alert：
<span>1111</span>
<script>
console.log("DOM 已存在:", document.querySelector("span").textContent); // ✅ 输出 "1111"
// 此时 span 已在 DOM 中，但尚未渲染可见
</script>⚠️ 注意事项：
立即学习“前端免费学习笔记（深入）”；
- alert() 不属于 JavaScript 语言规范，而是宿主环境（浏览器）提供的 Web API，其行为具有强 UI 阻塞性，绝不适用于现代生产环境（影响用户体验、可访问性及调试）；
- 即使添加 setTimeout(..., 0)，也不能保证渲染完成——因为微任务/宏任务调度不等同于渲染帧提交；
- 若需确保元素“已渲染可见”后再执行逻辑，应使用 requestAnimationFrame() + offsetHeight 触发重排，或监听 DOMContentLoaded 后结合 window.getComputedStyle() 验证。
? 推荐替代方案（非阻塞、可预测）：
<span id="msg1">1111</span>
<script>
// 延迟至下一个渲染帧前执行（更可靠 than setTimeout）
requestAnimationFrame(() => {
// 此时 span 极大概率已完成首次绘制
console.log("✅ 可见元素已渲染");
// 替代 alert：用非模态提示（如 toast）
showCustomToast("1");
});
</script>? 总结：HTML 元素的“出现顺序”取决于解析 → DOM 构建 → 样式计算 → 布局 → 绘制 → 合成这一完整管线，而 alert() 在 JS 执行阶段就中断了后续管线推进。理解浏览器的多引擎协作模型与渲染生命周期，才能正确预期和控制前端行为——不是 HTML 和 JS 在“抢优先级”，而是它们本就运行在不同阶段、不同线程（或同一线程的不同阶段）上。
