基于IE下ul li 互相嵌套時的bug,排查,解決過程以及心得介紹
檢查bug的步驟
1. bug定位
【基于IE下ul li 互相嵌套時的bug,排查,解決過程以及心得介紹】在js腳本中，按照腳本執行的順序，你可以用console或alert，來確定bug發生的代碼區間 ， 然后在區間內進一步來查找bug發生的具體代碼段 。
2. bug fix
通過排除，就是在插入節點內容的時候導致了bug，我用的是kissy的DOM.html()方法 ， 其功能類似于DOM元素節點innerHTML方法，我起初認為是這個方法導致的IE6渲染出錯，然后我換成了innerHTML方法，結果還是有誤 。
這時候我想到了內存泄露，看看是不是在循環拼接字符串的過程中，有循環引用或者其他原因造成內存泄露，然后在一些方法結束的時候，我把一些變量賦值null，來防止內存泄露（雖然不知道是否有效 ， 但是至少我這么嘗試過了），結果還是不行 。
是不是數據過多，導致一下子渲染的時候崩潰呢？于是我減少了拼接的數據長度，這個起效了 。1~3條數據的時候，可以渲染上，那就說明方法是沒有錯的；但是3條以上的數據 ， IE6還是無法響應 。于是我又試著一條一條數據取持續插入，因為一次插入1條數據沒有問題的話，我大不了多插入幾次吧 ， 但是IE還是有問題 。其實，這時候我的思路已經偏離了 。
后來找同事來看看，說之前也碰到過這個問題，是IE6下，標簽沒有正確閉合的原因導致的 。沒錯 ， 這就是這個bug的真正原因啦 。后來，我把拼接的字符串打印出來 ， 然后再使用格式化工具進行格式化，變很快發現了我拼接字符串的時候出現的這個問題，于是很快fix掉這個bug 。我用的在線格式化工具：http://tool.chinaz.com/Tools/JsFormat.aspx
3. 測試
測試時候，我們寫上一串html代碼，并對一些標簽不閉合，看看IE和chrome對比情況 。
代碼如下，在第二個li標簽里 ， 我們對ul標簽中的其中一個span標簽，做不閉合處理
復制代碼 代碼如下:
ul
li
ul
liinner li/li
liinner li/li
liinner li/li
/ul
/li
li
ul
liinner li/li
liinner li/li
liinner li
spannot closedspanerror happend/span/li
/ul
/li
li
ul
liinner li/li
liinner li/li
liinner li/li
/ul
/li
/ul
IE 和chrome下都正常顯示 ， 如上圖 。
接下來通過開發工具調試看看 。
在IE7~9下面，dom結構錯亂，發送錯誤的地方就在那個沒有閉合的span標簽那里，原來的第三個li節點的內容直接插到了span節點下面 。
我們再來看看chrome下面的情況吧：第三個li正常的渲染到dom樹里面，在發生錯誤的span標簽那里，自動補上了一個span的閉合標簽
4. 總結
各個瀏覽器在渲染html的時候表現不一樣，尤其是IE瀏覽器同其他的瀏覽器 。chrome和FF的容錯性能很好，即使頁面中存在html標簽沒有正常閉合，它也會智能的進行識別，并使其在瀏覽器中看上去無恙，且最終的DOM結構也沒有問題，然而不好的一面就是你不知道你的代碼有錯，還以為一切正常 。而IE89現在也可以這樣處理，看上去頁面內容沒有問題，但是呢，通過開發工具，你可以看到錯誤的html代碼沒有正常的DOM結構 。但是IE6就不會給你這樣的機會，要么就直接崩潰了 。
chrome可以容許我們犯錯，而IE卻對我們更加嚴格，雖然IE讓我們很頭疼，但是卻對我們的代碼提出了更高的要求！忽然覺得，有IE也蠻好的 。。。
如果有一天，你發現IE下dom結構都無法渲染出來的時候，記得提醒自己，是否代碼中有標簽沒有閉合 。
