如何让错误现出原形？
前面主要是为了让我们能有一个良好的心态来处理问题，情绪保持冷静可以让我们的思维更加敏捷，抓住特征可以让我们更快的找到线索，怀疑一切可以让我们有更多的思路去发现错误。（“不把妖孽打得显出原形，就别想翻过这座山！”――猴哥）
1、 化繁为简
临床表现：莫名其妙的报错，不方便调试，单纯看代码无法解释出错原因。
主要病因：js脚本冲突、Css冲突、DOM的ID冲突、DOM标签缺失等多种由于冲突产生的bug根源
排查方法：熟练使用 Delete / Backspace 键，对代码不断进行区域删除，直到症状消失，最后一次删除的区域很可能就是导致错误的根源。进一步查找根源可以在目标区域使用更小单位的区域定义反复使用此方法。
注意：
?对于 js 代码建议分别以类库 ? 功能 ? 行 为单位进行删除测试
?对于 HTML 代码建议按照页面结构先删除最内部的 tag，由内及外，这样可以迅速发现由于 tag 缺失造成的错误，同时也能保证每次删除的都是整段的代码，避免由于删除产生新的错误。
?对于 css 代码建议按照css文件 ? 定义的class系列 ? 行 为单位批量进行删除测试
忌：对于确认与相关功能有关的部分不要随便删除。
副作用：使用此方法也可以很好的确认错误原因是js造成的还是css造成的。
2、 顺藤摸瓜
临床表现：错误信息较准确，能够按照提示的错误逐层跟踪，使用“化繁为简”能够基本定位的错误类型
主要病因：基本语法错误、逻辑错误、不严谨（最常见的有：数组下标越界，null空指针导致的对象找不到，undefined未初始化，NaN数字计算错误等）
排查方法：利用浏览器的调试工具（F12是个很好的功能键）：跟踪代码；利用console.log 输出监控对象（IE无效）；利用 alert监控（最无奈的方法，用于极端情况）；把调试代码加载报错命令行的前面，一般都会有奇效！
注意：
?对于无js 报错的情况，直接调试无效功能的代码即可。有时候会发现之所以功能无效的原因居然是没有调用该代码！（是不是很可笑？我承认我犯过这种错误。）
?逻辑错误往往不太容易想清楚，这时候可以适当结合“化繁为简”的思路进行调试。
?当你使用的是类似于 jQuery 这种js库时，如果报错信息处于js库内，首先要更换为未压缩的js代码进行调试，然后分析是自己的哪段代码会调用相关功能。
忌：钻牛角尖！当按照此方法仍无法找到错误根源时，说明这并不是一个准确的错误信息，肯定有其他潜在的因素在产生错误。立刻更改切入点，不要在一个地方长时间浪费时间。（这种时候，可以参考下一个方法：“反复对照”）
3、 反复对照
临床表现： 应用普通方法很难定位错误，前两种方法怎么用都还是找不到头绪。
主要病因： 逻辑复杂、功能互相绑定难以剥离、页面对象内容复杂、有的页面正常有的页面不正常、兼容问题等
排查方法： 对付这种复杂的麻烦，排查方法也会很繁琐，但并不是什么特别高深的技术，只是需要多做一些体力活儿而已。
?方法一：检查可疑的代码，细化功能点，每次只修改一个地方，修改一次就测试一次，直到发现导致错误的关键代码。
?方法二：制作最简单的Demo 只实现需要的功能，当功能正常后，与出错的正式代码进行比较（比较中可以适当使用方法一）
?方法三：以正常功能（或出错）的代码为原型，修改一个地方就生成一个测试的备份，每个测试的案例都只有一处与原始代码不同，编上号码，在特殊环境下逐一测试，检查导致错误的根源（我曾经用这个方法解决了韩文系统下IE8加载公司内部flash 不能正常发声的bug）
注意：
?使用此法一定要有耐心
?此方法技术含量低，任何人都可以快速掌握，解决某些疑难杂症基本上可以说是药到病除！
忌： 急躁、马虎
4、 积累经验
临床表现：部分浏览器报错、事件响应异常、js操作DOM无效、PC 和 触屏系统功能不一致等
主要病因：各种兼容问题
排查方法：对于某些有明显特征的报错要熟记于胸，看到这些情况能立刻想到应该是哪些原因导致的。（最明显的例子：Json对象多了一个逗号的情况，只有ie报错）
注意：
?有个很基础的问题，但有很多初学者出错――没有搞清楚页面 html、css、js 的加载顺序，导致js 操作失败。（去Google 或 Baidu 搜索：“html css js 加载顺序”）
?日常工作要细心，勤观察。认真对待每一次查找错误的工作，对于部分非常特殊的情况可以记下来。
?熟练利用 Google、Baidu 等搜索引擎，有时候自己第一次遇到的情况，别人早都知道如何解决了。
忌：粗心大意、不求甚解
5、 细节决定成败
以上四种查找错误的方法全部都依赖于一个核心――细节！细节往往比你的技术水平更重要。说一句夸张点儿的话，能有多少那么高深的技术等着你去做？好好把自己手上的工作认真完成吧！但请记住了，当你重视细节以后，你距离去做高深技术的机会应该也就不远了。
三、 如何修正错误？
老程序员们应该已经深有体会，改Bug 最头疼的还是找错，一旦找到错误后，真正解决问题可能真的是只有几分钟。下面针对一些常见的错误原因与修改思路总结一下：
1、 基本语法、语言基础
逗号、分号、双引号、单引号 以及 各种括号 估计都曾导致过你的代码错误吧？这些东西记牢，必须知道什么时候应该使用什么，不要为了简化代码而精简这些符号。
例如：if / for 等语句后面的 { } 最好还是带上吧。
补充，对于js中的Number 数字的范围希望大家有一定的了解，因为这个范围肯定和后台语言中的Long不一样的。（已经有不止一个朋友跟我说 zTree 会自动修改节点的id，当我看到案例后，原来是数字溢出了！）
2、 条件严谨
对 Array 或者操作对象属性时，尽可能让条件判断语句写的完整、全面一些。
例如：判断 a.abc 的时候，最好别忘了判断 a 是否存在；或者操作Array时先判断一下Array 是否存在，要操作的下标是否越界等。
3、 注意兼容（css & js）
警惕部分浏览器不一致或者出错的情况，很多情况都是兼容造成的。如果自己经验不够，直接去Google 或者 Baidu。慢慢的自己经常接触到的一些兼容问题就会牢记下来了。
补充，有时候要注意页头 W3C的定义，曾经有朋友问我 zTree 异常的问题，最终发现是 W3C只写了一半。
4、 逻辑陷阱
条件过于复杂；循环、判断反复嵌套都是容易导致逻辑陷阱的因素。遇到这种情况，如果自己实在无法解决那么请个身边的高手来吧，让他帮你讲解一下。我相信，除了那些有点儿自闭的人来说，别人都会愿意帮助你解决问题的（前提是你自己别太遭人恨了，呵呵）
补充：多去看看有关 重构 的技术书籍！会让你提高很多的。
5、 异步加载
其实异步加载出现的问题往往属于逻辑陷阱，但我必须要提出来专门讲述，因为在这上面犯错的人太多了！！！！这里专门详细讲述一遍处理方法：
?对于异步加载出现了异常，请按照以下流程进行逐一排查：
1）页面是否有报错，是否执行到 ajax 部分的代码？（如果正常请看下一条）
2）用浏览器的调试工具监控网络，ajax 加载的url 地址是否正确？（如果正常请看下一条）
3）用浏览器的调试工具监控网络，传递给url 的参数是否正确？（如果正常请看下一条）
4）用浏览器的调试工具监控网络，从url 返回的数据是否正确？（如果正常请看下一条）
5）在 ajax 的success中编写调试代码，调试异步加载后的处理方法是否正确
如果以上几步都正常，那么我可以告诉你异步加载本身是一切正常的，还有错怎么办？继续往下看
?当异步加载确定正常后，就需要考虑另一个重要问题，也就是我在上一篇文章《这些年我们爱犯的弱智错误（菜鸟必看）》中专门讲述的易犯的错误――异步加载的疏忽
1）千万不要在执行了 ajax 之后立刻去执行应该在异步加载完成之后再运行的代码。因为你执行这段代码的时候，ajax根本没有完成呢。（最明显的现象：运行时时好时坏，但如果我加入了alert 会发现每次都正常了）
这种情况，请将你的代码转移到 ajax的 success 或 error 里面去执行
2）当你设置了某些特殊开关时，一定不要忘了在 ajax 的error 里面进行重置，否则很可能因为一次网络异常，就会造成你的页面js 功能失效。这种错误常常是地雷级别的，很难被发现。
6、 神奇的setTimeout
对于移动设备 或者 某些特殊情况，可以适当考虑使用 setTimeout 来解决问题。
我遇到比较特例的情况：有两个js的事件因为不同的功能在同时对同一个DOM操作时会导致IE8崩溃，显然这是IE的bug，但我无法去要求微软做什么…最终使用 setTimeout 让其中一个功能延迟100-200毫秒再执行，轻松搞定！
7、 别在一棵树上吊死
做前端的人都很郁闷要适配n多的浏览器，往往会遇到一些自己无法解决的问题（因为是浏览器bug 造成的），遇到这种情况怎么办？一般来说寻找一下有没有 hacker的方法，如果没有，那么就换一种思路，看看是否可以有其他方案来实现类似的功能。如果各种努力都做了…还有人不满意的话，那么告诉他浏览器的bug，让项目管理者来决定到底如何处理吧――这种情况死而无憾了！
写到这里，基本上可以说是倾囊而出了，希望能有一点点引起你的注意，希望能够让你感到一丝的触动，感到一些似曾相识。最主要的我还是希望你能够快速提高自己的技能，拿到多多的工资，让自己成为技术牛人！