这里有相互矛盾的点赞答案，没有证据，就无法知道该相信谁。这里证明@DVK是正确的，@SalvadorDali是不正确的。后者声称:

这就是为什么:它不可能有一个时间setTimeout 延迟0毫秒。最小值由 而不是0毫秒。历史上浏览器会设置这个 至少10毫秒，但HTML5规格和现代浏览器 把它设置为4毫秒。”

4毫秒的最小超时与正在发生的事情无关。实际发生的情况是setTimeout将回调函数推到执行队列的末尾。如果在setTimeout(callback, 0)之后，阻塞代码需要几秒钟才能运行，那么回调将在几秒钟内不执行，直到阻塞代码完成。试试下面的代码:

function testSettimeout0 () {
    var startTime = new Date().getTime()
    console.log('setting timeout 0 callback at ' +sinceStart())
    setTimeout(function(){
        console.log('in timeout callback at ' +sinceStart())
    }, 0)
    console.log('starting blocking loop at ' +sinceStart())
    while (sinceStart() < 3000) {
        continue
    }
    console.log('blocking loop ended at ' +sinceStart())
    return // functions below
    function sinceStart () {
        return new Date().getTime() - startTime
    } // sinceStart
} // testSettimeout0

输出是:

setting timeout 0 callback at 0
starting blocking loop at 5
blocking loop ended at 3000
in timeout callback at 3033

setTimeout有用的其他一些情况:

你想要把一个长时间运行的循环或计算分解成更小的组件，这样浏览器就不会出现“冻结”或说“页面上的脚本正在忙”。

您希望在单击时禁用表单提交按钮，但如果禁用onClick处理程序中的按钮，则表单将无法提交。setTimeout的时间为0，允许事件结束，表单开始提交，然后可以禁用按钮。

Javascript是单线程应用程序，因此不允许同时运行函数，因此使用事件循环来实现此目标。setTimeout(fn, 0)所做的就是在调用栈为空时将它推入任务任务。我知道这个解释很无聊，所以我建议你看一下这个视频，这将帮助你在浏览器中如何工作。 看看这个视频:- https://www.youtube.com/watch?time_continue=392&v=8aGhZQkoFbQ

如果你不想看完整个视频，这里有一个简单的解释，你需要理解的东西，为了能够理解这个问题的答案:

JavaScript是单线程的，这意味着它在运行时一次只做一件事。 但是JavaScript运行的环境可以是多线程的。例如，浏览器通常是多线程生物，也就是说，能够在同一时间做多件事情。所以他们可以运行JavaScript，同时也可以跟踪处理其他东西。

从这一点开始，我们讨论的是“浏览器中的”JavaScript。像setTimeout这样的东西确实是浏览器的东西，而不是JavaScript本身的一部分。

允许JavaScript异步运行的是多线程浏览器!除了Javascript用来放置每行代码并逐个运行的主要空间(称为调用堆栈)之外，浏览器还为Javascript提供了另一个空间来放置内容。

现在我们称另一个空间为第二个空间。

假设fn是一个函数。这里需要理解的重要一点是fn();调用不等于setTimeout(fn, 0);调用，下面将进一步解释。

不是0延迟，让我们先假设另一个延迟，例如，5000毫秒:setTimeout(fn, 5000);。重要的是要注意，这仍然是一个“函数调用”，所以它必须放在主空间上，并在完成时从主空间中删除，但请等待!我们不喜欢冗长无聊的5秒延迟。这将阻塞主空间，并且不允许JavaScript在此期间运行任何其他内容。

值得庆幸的是，这并不是浏览器设计者设计它们工作的方式。相反，这个调用(setTimeout(fn, 5000);)是立即完成的。这一点非常重要:即使有5000毫秒的延迟，这个函数调用也会在瞬间完成!接下来会发生什么?它被从主空间中移除。演出地点在哪里?(因为我们不想失去它)。您可能猜对了:浏览器听到这个调用并把它放在第二个空格上。

浏览器会跟踪5秒的延迟，一旦它过去了，它就会查看主空间，“当它是空的”，把fn();回调它。这就是setTimeout的工作方式。

回到setTimeout(fn, 0)，即使延迟为0，这仍然是对浏览器的调用，浏览器会立即听到它并接收它，把它放在第二个空间上，只有当主空间再次为空时才把它放回主空间，而不是真正的0毫秒后。

我真的建议大家也去看看那个视频，因为他解释得非常好，而且更多地讲解了技术方面的东西。

关于执行循环和在其他代码完成之前呈现DOM的答案是正确的。JavaScript中的零秒超时有助于使代码成为伪多线程，尽管它不是。

我想补充的是，JavaScript中跨浏览器/跨平台零秒超时的最佳值实际上是20毫秒而不是0(零)，因为由于AMD芯片的时钟限制，许多移动浏览器无法注册小于20毫秒的超时。

此外，不涉及DOM操作的长时间运行的进程现在应该发送给Web Workers，因为它们提供了JavaScript的真正多线程执行。

这两个排名靠前的答案都是错的。查看关于并发模型和事件循环的MDN描述，应该会清楚发生了什么(MDN资源是一个真正的珍宝)。除了“解决”这个小问题之外，简单地使用setTimeout可能会在代码中添加意想不到的问题。

这里实际发生的事情并不是“由于并发性，浏览器可能还没有完全准备好”，或者基于“每一行都是一个被添加到队列后面的事件”。

DVK提供的jsfiddle确实说明了一个问题，但他的解释是不正确的。

在他的代码中所发生的事情是，他首先将一个事件处理程序附加到#do按钮上的单击事件。

然后，当您实际单击按钮时，将创建引用事件处理程序函数的消息，该消息被添加到消息队列中。当事件循环到达这条消息时，它在堆栈上创建一个框架，并调用jsfiddle中的click事件处理程序。

这就是有趣的地方。我们习惯于认为Javascript是异步的，以至于我们很容易忽略这个小事实:在执行下一帧之前，任何一帧都必须完整地执行。不要并发，伙计们。

What does this mean? It means that whenever a function is invoked from the message queue, it blocks the queue until the stack it generates has been emptied. Or, in more general terms, it blocks until the function has returned. And it blocks everything, including DOM rendering operations, scrolling, and whatnot. If you want confirmation, just try to increase the duration of the long running operation in the fiddle (e.g. run the outer loop 10 more times), and you'll notice that while it runs, you cannot scroll the page. If it runs long enough, your browser will ask you if you want to kill the process, because it's making the page unresponsive. The frame is being executed, and the event loop and message queue are stuck until it finishes.

So why this side-effect of the text not updating? Because while you have changed the value of the element in the DOM — you can console.log() its value immediately after changing it and see that it has been changed (which shows why DVK's explanation isn't correct) — the browser is waiting for the stack to deplete (the on handler function to return) and thus the message to finish, so that it can eventually get around to executing the message that has been added by the runtime as a reaction to our mutation operation, and in order to reflect that mutation in the UI.

This is because we are actually waiting for code to finish running. We haven't said "someone fetch this and then call this function with the results, thanks, and now I'm done so imma return, do whatever now," like we usually do with our event-based asynchronous Javascript. We enter a click event handler function, we update a DOM element, we call another function, the other function works for a long time and then returns, we then update the same DOM element, and then we return from the initial function, effectively emptying the stack. And then the browser can get to the next message in the queue, which might very well be a message generated by us by triggering some internal "on-DOM-mutation" type event.

浏览器UI不能(或选择不)更新UI，直到当前执行的帧已经完成(函数已经返回)。我个人认为，这与其说是限制，不如说是有意为之。

Why does the setTimeout thing work then? It does so, because it effectively removes the call to the long-running function from its own frame, scheduling it to be executed later in the window context, so that it itself can return immediately and allow the message queue to process other messages. And the idea is that the UI "on update" message that has been triggered by us in Javascript when changing the text in the DOM is now ahead of the message queued for the long-running function, so that the UI update happens before we block for a long time.

Note that a) The long-running function still blocks everything when it runs, and b) you're not guaranteed that the UI update is actually ahead of it in the message queue. On my June 2018 Chrome browser, a value of 0 does not "fix" the problem the fiddle demonstrates — 10 does. I'm actually a bit stifled by this, because it seems logical to me that the UI update message should be queued up before it, since its trigger is executed before scheduling the long-running function to be run "later". But perhaps there're some optimisations in the V8 engine that may interfere, or maybe my understanding is just lacking.

使用setTimeout有什么问题，对于这种特殊情况有什么更好的解决方案?

首先，在任何这样的事件处理程序上使用setTimeout来试图缓解另一个问题的问题，很容易与其他代码混淆。下面是我工作中的一个现实例子:

一个同事，在对事件循环的错误理解中，试图通过让一些模板呈现代码使用setTimeout 0进行呈现来“线程化”Javascript。他不再问这个问题了，但我可以推测，也许他插入了计时器来测量呈现速度(即函数返回的即时性)，并发现使用这种方法将使该函数的响应速度非常快。

First problem is obvious; you cannot thread javascript, so you win nothing here while you add obfuscation. Secondly, you have now effectively detached the rendering of a template from the stack of possible event listeners that might expect that very template to have been rendered, while it may very well not have been. The actual behaviour of that function was now non-deterministic, as was — unknowingly so — any function that would run it, or depend on it. You can make educated guesses, but you cannot properly code for its behaviour.

The "fix" when writing a new event handler that depended on its logic was to also use setTimeout 0. But, that's not a fix, it is hard to understand, and it is no fun to debug errors that are caused by code like this. Sometimes there's no problem ever, other times it concistently fails, and then again, sometimes it works and breaks sporadically, depending on the current performance of the platform and whatever else happens to going on at the time. This is why I personally would advise against using this hack (it is a hack, and we should all know that it is), unless you really know what you're doing and what the consequences are.

但是我们能做什么呢?好吧，正如引用的MDN文章所建议的那样，要么将工作拆分为多个消息(如果可以的话)，这样其他排队的消息就可以与你的工作交织在一起，并在它运行时执行，要么使用web worker，它可以与你的页面一起运行，并在计算完成时返回结果。

哦，如果你在想，“我能不能在长时间运行的函数中加入一个回调，使它异步?，然后没有。回调并没有使它异步化，在显式调用回调之前，它仍然必须运行长时间运行的代码。