alert执行时机和js线性模型事件循环

  <div class="test">测试内容</div>
  <script>
    $('.test').text('内容改变')
    alert($('.test').text())
    // 页面加载后首先时alert弹出，alert的内容为 ‘内容改变’，而dom此时还未发生变化，dom的内容是‘测试内容’
    // 然后会一直堵塞，直到我们点击确认，alert消失时，页面内容才会变成‘内容改变’
    // 所以alert prompt confirm等提示框都会跳过页面渲染先执行
  </script>

解决这个问题之前先了解一下它是怎么导致的，而要了解它需要从 JavaScript 的线程模型说起。

JavaScript 引擎是单线程运行的，浏览器无论在什么时候都只且只有一个线程在运行 JavaScript 程序，初衷是为了减少 DOM 等共享资源的冲突。可是单线程永远会面临着一个问题，那就是某一段代码阻塞会导致后续所有的任务都延迟。又由于 JavaScript 经常需要操作页面 DOM 和发送 HTTP 请求，这些 I/O 操作耗时一般都比较长，一旦阻塞，就会给用户非常差的使用体验。

于是便有了事件循环（event loop）的产生，JavaScript 将一些异步操作或有I/O 阻塞的操作全都放到一个事件队列，先顺序执行同步 CPU代码，等到 JavaScript 引擎没有同步代码，CPU 空闲下来再读取事件队列的异步事件来依次执行。

这些事件包括：

setTimeout() 设置的异步延迟事件；
DOM 操作相关如布局和绘制事件；
网络 I/O 如 AJAX 请求事件；
用户操作事件，如鼠标点击、键盘敲击。

明白了原理，再解决这个问题就有了方向，我们来分析这个问题：

由于页面渲染是 DOM 操作，会被 JavaScript 引擎放入事件队列；
alert() 是 window 的内置函数，被认为是同步 CPU代码；
JavaScript 引擎会优先执行同步代码，alert 弹窗先出现；
alert 有特殊的阻塞性质，JavaScript 引擎的执行被阻塞住；
点击 alert 的“确定”，JavaScript 没有了阻塞，执行完同步代码后，又读取事件队列里的 DOM 操作，页面渲染完成。

由上述原因，导致了诡异的 “Alert执行顺序问题”。我们无法将页面渲染变成同步操作，那么只好把 alert() 变为异步代码，从而才能在页面渲染之后执行。

解决方法：

etTimeout() 使用它，可以延迟执行某些代码。而对于延迟执行的代码，JavaScript 引擎总是把这些代码放到事件队列里去，再去检查是否已经到了执行时间，再适时执行。代码进入事件队列，就意味着代码变成和页面渲染事件一样异步了。由于事件队列是有序的，我们如果用 setTimeout 延时执行，就可以实现在页面渲染之后执行 alert 的功能了。

setTimeout 的函数原型为 setTimeout(code, msec)，code 是要变为异步的代码或函数，msec 是要延时的时间，单位为毫秒。这里我们不需要它延时，只需要它变为异步就行了，所以可以将 msec 设置为 0；

  <div class="test">测试内容</div>
  <script>
    $('.test').text('内容改变')
    setTimeout(function(){
      alert($('.test').text())
    },0)
    // 由于使用setTimeout操作，使alert被放入到事件队列 ，
    // 同时 $('.test').text('内容改变')也是在事件队列
    // 所以 dom和alert的内容都是 ‘内容改变’

alert执行时机和js线性模型 事件循环

解决方法：

alert执行时机和js线性模型事件循环