在 HTML 渲染流程中，浏览器并非“单线程逐行绘制”，而是由多个子系统协同工作：HTML 解析器负责构建 DOM 树，CSS 引擎计算样式，渲染引擎（如 Blink/WebKit） 负责布局与绘制，而 JavaScript 引擎（如 V8） 则同步执行脚本。关键在于：当遇到
而 alert() 是一个由浏览器原生实现的 同步阻塞式 API，它直接调用底层 UI 线程弹出模态对话框，并强制冻结整个页面的渲染更新（包括 DOM 绘制、样式应用、重排重绘）。因此，即使 1111 在源码中位于
✅ 验证这一点的简单方式是使用 console.log 替代 alert：
1111
⚠️ 注意事项：
立即学习“前端免费学习笔记（深入）”；
- alert() 不属于 JavaScript 语言规范，而是宿主环境（浏览器）提供的 Web API，其行为具有强 UI 阻塞性，绝不适用于现代生产环境（影响用户体验、可访问性及调试）；
- 即使添加 setTimeout(..., 0)，也不能保证渲染完成——因为微任务/宏任务调度不等同于渲染帧提交；
- 若需确保元素“已渲染可见”后再执行逻辑，应使用 requestAnimationFrame() + offsetHeight 触发重排，或监听 DOMContentLoaded 后结合 window.getComputedStyle() 验证。
? 推荐替代方案（非阻塞、可预测）：
1111
? 总结：HTML 元素的“出现顺序”取决于解析 → DOM 构建 → 样式计算 → 布局 → 绘制 → 合成这一完整管线，而 alert() 在 JS 执行阶段就中断了后续管线推进。理解浏览器的多引擎协作模型与渲染生命周期，才能正确预期和控制前端行为——不是 HTML 和 JS 在“抢优先级”，而是它们本就运行在不同阶段、不同线程（或同一线程的不同阶段）上。
