基于IE下ul li 互相嵌套时的bug,排查,解决过程以及心得介绍

检查bug的步骤

1. bug定位

在js脚本中，按照脚本执行的顺序，你可以用console或alert，来确定bug发生的代码区间，然后在区间内进一步来查找bug发生的具体代码段。

2. bug fix

通过排除，就是在插入节点内容的时候导致了bug，我用的是kissy的DOM.html()方法，其功能类似于DOM元素节点innerHTML方法，我起初认为是这个方法导致的IE6/7渲染出错，然后我换成了innerHTML方法，结果还是有误。

这时候我想到了内存泄露，看看是不是在循环拼接字符串的过程中，有循环引用或者其他原因造成内存泄露，然后在一些方法结束的时候，我把一些变量赋值null，来防止内存泄露（虽然不知道是否有效，但是至少我这么尝试过了），结果还是不行。

是不是数据过多，导致一下子渲染的时候崩溃呢？于是我减少了拼接的数据长度，这个起效了。1~3条数据的时候，可以渲染上，那就说明方法是没有错的；但是3条以上的数据，IE6/7还是无法响应。于是我又试着一条一条数据取持续插入，因为一次插入1条数据没有问题的话，我大不了多插入几次吧，但是IE还是有问题。其实，这时候我的思路已经偏离了。

后来找同事来看看，说之前也碰到过这个问题，是IE6/7下，标签没有正确闭合的原因导致的。没错，这就是这个bug的真正原因啦。后来，我把拼接的字符串打印出来，然后再使用格式化工具进行格式化，变很快发现了我拼接字符串的时候出现的这个问题，于是很快fix掉这个bug。我用的在线格式化工具：http://tool.chinaz.com/Tools/JsFormat.aspx

3. 测试

测试时候，我们写上一串html代码，并对一些标签不闭合，看看IE和chrome对比情况。

代码如下，在第二个li标签里，我们对ul标签中的其中一个<span>标签，做不闭合处理

接下来通过开发工具调试看看。

在IE7~9下面，dom结构错乱，发送错误的地方就在那个没有闭合的<span>标签那里，原来的第三个<li>节点的内容直接插到了<span>节点下面。

我们再来看看chrome下面的情况吧：第三个li正常的渲染到dom树里面，在发生错误的span标签那里，自动补上了一个span的闭合标签

4. 总结

各个浏览器在渲染html的时候表现不一样，尤其是IE浏览器同其他的浏览器。chrome和FF的容错性能很好，即使页面中存在html标签没有正常闭合，它也会智能的进行识别，并使其在浏览器中看上去无恙，且最终的DOM结构也没有问题，然而不好的一面就是你不知道你的代码有错，还以为一切正常。而IE8/9现在也可以这样处理，看上去页面内容没有问题，但是呢，通过开发工具，你可以看到错误的html代码没有正常的DOM结构。但是IE6/7就不会给你这样的机会，要么就直接崩溃了。

chrome可以容许我们犯错，而IE却对我们更加严格，虽然IE让我们很头疼，但是却对我们的代码提出了更高的要求！忽然觉得，有IE也蛮好的。。。

如果有一天，你发现IE下dom结构都无法渲染出来的时候，记得提醒自己，是否代码中有标签没有闭合。