do
{
i=i+1
if(i===6)
}
先让i+1再判断就可以了
js渲染数据太大，导致浏览器崩溃是JS中大量的DOM操作也会导致事件响应缓慢甚至真正卡死浏览器，在IE6下一次插入大量的HTML。解决方法如下：1、优化循环，循环体中包含太多的操作和循环的次数过多都会导致循环执行时间过长，直接导致锁死浏览器。
2、优化函数，函数体内有太多不相干的进行拆分。
3、优化递归操作，需要小心处理。
为什么页面会卡顿呢，以60Hz为例，即一秒钟的动画就是由60张静态图片连在一起。60fps是动画播放比较理想、比较基础的要求，windows系统有个刷新频率也是这个意思。60fps就要求一帧的时间为1s/60=16.67ms。浏览器显示页面的时候，要处理js逻辑，还要做渲染，每个执行片段的时间不能超过16.67ms。实际上，浏览器内核自身支撑体系运行也需要消耗一些时间，所以留给我们的时间差不多只有10ms。并且在处理js计算时，浏览器不会响应用户的操作，所以就造成了页面“假死”。 Web Work，就是为JavaScript创造多线程环境，允许主线程创建Web Worker线程，将一些任务分配给后台运行。在主线程运行的同事，Work线程在后台运行，两者互不干扰。等到Work线程完成计算任务再把结果返回给主线程。这样的好处是，一些密集或者高延迟的计算任务，被Work线程给分担了，这样主线程就会很流程。 Worker线程一旦创建成功，就会始终运行，不会被主线程上的活动打断取消。这样有利于随时响应主线程的通信。但是，这也造成了Worker比较耗费资源，不应该过度使用，所以一旦使用完毕，就应该关闭。 1.同源限制：分配给Worker线程运行的脚本文件，必须与主线程的脚本文件同源。 2.DOM限制：Work线程所在的全局对象和主线程不一样，所以无法读取主线程所在网页的DOM对象，也无法使用document，window，parent这些对象。但是可以使用navigator和location。 3.通信联系：Worker线程和主线程不在同一个上下文环境，他们不能直接通信，必须通过消息完成。 4.脚本限制：Worker线程不能执行alert和confirm方法，但是可以使用XMLHttpRequest对象发出的AJAX请求。 5.文件限制：Work线程不能读取本地文件，它所加载的脚本必须来自网络。
