我希望我不会自欺欺人，但我试图了解这两行代码中发生的事情：
document.body.innerHTML = 'something';
alert('something else');
我观察到的是，警报在 HTML 更新之前显示（或者可能已经更新，但页面尚未刷新/重新绘制/无论如何）
查看此代码笔以了解我的意思。
请注意，即使将alert在setTimeout(..., 0)没有帮助。看起来innerHTML实际更新页面需要更多的事件循环。
编辑：
我忘了提到我正在使用 Chrome 并且没有检查其他浏览器。看起来它只在 Chrome 中可见。尽管如此，我仍然对为什么会发生这种情况感兴趣。
设置innerHTML 是同步的，您可以对DOM 进行的大多数更改也是如此。但是，呈现网页是另一回事。
（请记住，DOM 代表“文档对象模型”。它只是一个“模型”，一种数据的表示。用户在屏幕上看到的是该模型的外观图片。因此，更改模型不会立即发生更改图片 - 更新需要一些时间。）
运行 JavaScript 和呈现网页实际上是分开进行的。把它简单地说，首先是所有的JavaScript代码的页面运行（从事件循环-看看这个优秀的视频更多的细节），然后后，浏览器呈现的网页进行任何更改用户看到的。这就是“阻塞”如此重要的原因——运行计算密集型代码可防止浏览器通过“运行 JS”步骤并进入“渲染页面”步骤，从而导致页面冻结或卡顿。
Chrome 的管道如下所示：
如您所见，所有 JavaScript 都首先发生。然后页面被样式化、布局、绘制和合成——“渲染”。并非所有这些管道都会在每一帧执行。这取决于更改了哪些页面元素（如果有）以及它们需要如何重新呈现。
注意：alert()也是同步的并在 JavaScript 步骤期间执行，这就是为什么在您看到网页更改之前会出现警报对话框的原因。
您现在可能会问“等等，在管道中的‘JavaScript’步骤中到底运行了什么？我的所有代码每秒运行 60 次吗？” 答案是否定的，这要追溯到 JS 事件循环的工作原理。JS 代码只有在堆栈中时才会运行 - 来自事件侦听器、超时等。看以前的视频（真的）。
https://developers.google.com/web/fundamentals/performance/rendering/
是的，它是同步的，因为这是有效的（继续，在您的控制台中输入）：
document.body.innerHTML = 'text';
alert(document.body.innerHTML);// you will see a 'text' alert
您在看到页面更改之前看到警报的原因是浏览器呈现需要更多时间并且不如您的 javascript 逐行执行快。
该innerHTML财产实际并得到同步更新，但视觉重绘，这种变化会导致异步发生。
DOM 的可视化渲染在 Chrome 中是异步的，只有在当前 JavaScript 函数堆栈清除并且浏览器可以自由接受新事件后才会发生。其他浏览器可能使用单独的线程来处理 JavaScript 代码和浏览器呈现，或者当警报停止另一个事件的执行时，它们可能会让某些事件获得优先级。
您可以通过两种方式看到这一点：
如果您for(var i=0; i<1000000; i++) { }在警报之前添加，您已经给了浏览器足够的时间进行重绘，但它没有，因为函数堆栈尚未清除（add仍在运行）。
如果您alert通过 asynchronous延迟您的setTimeout(function() { alert('random'); }, 1)，重绘过程将在 setTimeout 延迟的函数之前进行。
0，可能是因为 Chrome 将事件队列优先于0任何其他事件之前的超时（或至少在重绘事件之前）。