在问题中，存在以下之间的竞争条件:

浏览器尝试初始化下拉列表，准备更新其选择的索引 设置所选索引的代码

您的代码总是在这场竞赛中胜出，并试图在浏览器准备好之前设置下拉选择，这意味着会出现错误。

这种竞争的存在是因为JavaScript有一个与页面呈现共享的执行线程。实际上，运行JavaScript会阻塞DOM的更新。

你的解决方案是:

setTimeout(callback, 0)

使用回调调用setTimeout，并将0作为第二个参数，将在尽可能短的延迟之后调度回调异步运行——当选项卡有焦点且JavaScript执行线程不忙时，大约为10ms。

因此，OP的解决方案是将所选索引的设置延迟约10ms。这让浏览器有机会初始化DOM，修复bug。

每个版本的ie浏览器都表现出古怪的行为，这种变通方法有时是必要的。或者，它可能是OP代码库中的一个真正的错误。

请参阅Philip Roberts的“到底什么是事件循环?”以获得更详细的解释。

setTimeout()即使设置为0，也会在DOM元素加载之前为您争取一些时间。

看看这个:setTimeout

这样做的一个原因是将代码的执行推迟到单独的后续事件循环。在响应某种类型的浏览器事件(例如鼠标单击)时，有时有必要仅在处理完当前事件后执行操作。setTimeout()工具是最简单的方法。

编辑现在是2015年，我应该注意到还有requestAnimationFrame()，这并不完全相同，但它足够接近setTimeout(fn, 0)，值得一提。

这两个排名靠前的答案都是错的。查看关于并发模型和事件循环的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，它可以与你的页面一起运行，并在计算完成时返回结果。

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

在问题中，存在以下之间的竞争条件:

浏览器尝试初始化下拉列表，准备更新其选择的索引 设置所选索引的代码

您的代码总是在这场竞赛中胜出，并试图在浏览器准备好之前设置下拉选择，这意味着会出现错误。

这种竞争的存在是因为JavaScript有一个与页面呈现共享的执行线程。实际上，运行JavaScript会阻塞DOM的更新。

你的解决方案是:

setTimeout(callback, 0)

使用回调调用setTimeout，并将0作为第二个参数，将在尽可能短的延迟之后调度回调异步运行——当选项卡有焦点且JavaScript执行线程不忙时，大约为10ms。

因此，OP的解决方案是将所选索引的设置延迟约10ms。这让浏览器有机会初始化DOM，修复bug。

每个版本的ie浏览器都表现出古怪的行为，这种变通方法有时是必要的。或者，它可能是OP代码库中的一个真正的错误。

请参阅Philip Roberts的“到底什么是事件循环?”以获得更详细的解释。

这是一个有老答案的老问题。我想重新审视这个问题，并回答为什么会发生这种情况，而不是为什么这种方法有用。

所以你有两个功能:

var f1 = function () {    
   setTimeout(function(){
      console.log("f1", "First function call...");
   }, 0);
};

var f2 = function () {
    console.log("f2", "Second call...");
};

然后按如下顺序调用它们f1();f2 ();看看第二个先执行。

原因如下:不可能让setTimeout的时间延迟为0毫秒。最小值由浏览器决定，不是0毫秒。历史上浏览器将这个最小值设置为10毫秒，但HTML5规范和现代浏览器将其设置为4毫秒。

如果嵌套级别大于5，并且超时时间小于4，则 将timeout增加为4。

同样来自mozilla:

要在现代浏览器中实现0毫秒超时，可以使用 window.postMessage()如下所述。

附注:信息是在阅读以下文章后获取的。