前两天遇见一个bug，在已买到的宝贝列表页面，如下图：
bug snagshoot

直觉反应是表头的CSS有问题，仔细检查后，却没发现问题。难道是JS引起的？禁用JS后，问题依旧。

开始怀疑是页面中某段HTML代码导致了这个bug. 前几天刚用熟了Fiddler，于是毫不犹豫地立马派上战场：
fiddler autoresponder
其中E:IdeaProjectsTaobaoTest.html是保存的页面源码，也可以用bpu或Unlock for Editing等方式直接在Fiddler的SyntaxView中修改。但对于频繁修改来说，用AutoResponder映射到本地，再用自己喜欢的编辑器修改会更方便。

凭着经验，逐步移除Test.html中的代码块，直到只剩下表格本身，结果发现问题依旧。此时已经耗费了10多分钟，看着ie7下狰狞的空白，着实有点沮丧。

于是习惯性地打开google，琢磨了几个关键词，结果却没有搜到任何相关话题。

仔细回想这个页面的开发过程，demo在ie下是没问题的。后台套vm模板时，我也曾仔细检查过。难道最近又有啥修改让HTML代码出问题了？立刻打开Firefox的HTML Validator插件：
bug snagshoot

一堆警告触目惊心，开发居然在两个tr之间放了两个input元素。立刻将input移动到td里面，刷新页面，bug消失了！

马上通知开发修改vm模板，至此已经耗费了近一个小时，庆幸的是一切搞定！

总的来说，这次bug排查效率还比较高。但现在回过头来想想，发现自己还是犯了不少“错误”：

  1. 当直觉解决不了问题，对bug毫无头绪时，应该首先用HTML Validator检查，不少诡异bug都源自代码的不规范。比如上面的bug，如果排查时遵守这一条，应该10分钟内就能搞定。
  2. 对于这个bug，其实根本用不着Fiddler. 完全可以保存页面到本地，直接调试本地文件即可，Fiddler仅满足了技术欲望。对于复杂环境下的JS bug，才是Fiddler的真正用武之地。目前我自己以及不少同事都有点滥用Fiddler（感觉上很酷），以后还是要选择性使用，Fiddler未必是最高效的。

对于bug排查，小马曾有过一个很好的总结：1. 善用工具，2. 善用搜索。无他，唯手熟尔！

我补充一点：3. 勤于总结。让知识和经验分享沉淀下来，为了自己的成长，也是为了前端整个行业的成熟。