当此应用的用户对字段进行更改时，需要在其他字段中进行大量更改。通常，即使使用优化的脚本，浏览器也会在IE中阻止用户输入超过1秒。为了防止发生，我这样做：
var i = 100;
GetTextInputs().filter('[' + name + ']').each(function()
{
setTimeout("DoWork('" + this.id + "', '" + v + "', '" + name + "');", i);
i += 25;
});
对我来说这感觉很讨厌，但效果很好。
答案 0 :(得分：3)
现在，我认为你实际上没有多少选择。
我没有检查你的功能是否正常工作，但是使用setTimeout并将工作分成小块可能是要走的路。
但是，将来你可能会使用Web Workers;引自Mozilla's webpage：
工作人员为网络提供了一种简单的方法 在后台运行脚本的内容 线程。一旦创建，工人就可以 通过发送消息到产卵任务 将消息发布到事件处理程序 由创作者指定。
工作线程可以执行任务 不干扰用户 接口。另外，他们可以 使用XMLHttpRequest执行I / O. （虽然responseXML和频道 属性始终为null）。
并且：
工人有用的一种方法是允许 你的代码要执行 处理器密集型计算 不阻止用户界面 线程。
这些已在Firefox 3.5中提供，我认为它们也是由Google Gears提供的 - 但它们还没有广泛使用，所以你可能不应该在几年前使用它们，至少对于一个应用程序由“任何人”使用： - （
答案 1 :(得分：3)
可能出现严重错误的一件事是，拥有太多高频定时器可能会[讽刺地]使ui迟缓/反应迟钝。来自http://googlecode.blogspot.com/2009/07/gmail-for-mobile-html5-series-using.html：
使用低频定时器 - 定时器 延迟一秒或更长时间 - 我们可以创建许多计时器 显着降低性能 任一设备。即使有100个计时器 预定，我们的应用程序并不明显 反应迟钝。随着高频率 然而，计时器的确如此 相反的。一些计时器射击 每100-200毫秒就足够了 让我们的UI感觉迟钝。
答案 2 :(得分：1)
为了获得更好的用户体验，我使用了setTimeout，以便尽可能多地在后台进行工作。
在Windows中类似于在主事件线程上运行所有内容。将应用程序从该线程中移除是更多的工作，但最终用户将获得更好的体验。
唯一可能出错的事情是，如果你在setTimeout中实际使用变量之前有变量，那么动作可能会有所不同。
所以如果你看到一些奇怪的行为，你至少可以意识到这一点。理想情况下，您的设计不应该允许它，但它可能会发生。