前言
“不积跬步，无以至千里；不积小流，无以成江海。”
想成为编程大佬也一样，不经过海量的bug、各种复杂的系统问题的处理经验，那么始终是纸上谈兵的小菜鸟。
那么如何做到遇到bug淡定自若，达到“他强任他强,清风拂山岗,他横由他横,明月照大江”的大佬境界呢？
本文结合自己多年的编程经验，给大家总结了这份bug定位套路大全，也许能对你有所帮助。
一、日志定位法
基本上大部分的bug异常问题，只要能找到相关的异常日志，那么就不用太慌了，根据提示的异常类型和出现位置，很容易就定位出异常原因。
可以说，日志是日常工作中定位bug，修复异常问题的首要依据。
有人可能说，那要是没有异常提示呢？
大部分情况下，可能和日志的输出级别有关。很多时候适当的降低日志级别，会输出更多程序运行的相关信息，给我们的bug修复提供更多的依据。
但要注意，生产环境上要控制好日志的输出级别，如果日志级别过低，可能会导致日志文件增长过快，对服务器的磁盘IO和存储空间造成较大的压力。
在spring boot中我们可以利用actuator组件实现日志级别的动态调整。
二、断点调试法
在开发过程中，遇到程序出现异常或执行效果不符的情况，有时可能只是代码逻辑的一些问题，并不会抛出异常，也就没有了相关的日志输出。这种情况下，最适合的就是在对应的方法打上断点，开启debug模式启动项目，逐步调试分析程序的执行步骤和数据变化的情况。
程序员老鸟都知道，能断点调试的bug，都不叫什么bug。
断点调试又分为2种情况：
1、本地断点调试
2、远程断点调试
很明显，本地断点调试是我们日常开发过程中用的最多的，在idea中给程序打上断点，然后通过debug模式启动项目，调用对应的方法，进入断点后通过F7和F8逐步调试。适用于本地开发环境。
而远程断点调试则是通过和远程运行的程序建立websocket连接来进行断点调试，本地的项目不用启动。适用于测试环境和生产环境。
三、google、百度大法
程序员圈子里有很多有趣的鄙视链，比如搞C的看不起搞java，搞java的看不起搞php的。
这里也说一条，用google的瞧不起用百度的。
但是我想说，年轻人才做选择，作为程序员老鸟，我都用。一般来说，百度更适合中国人的口味，搜索出的内容量也会比较多，但是过滤出高质量符合自己的场景的文章有时候比较费事。
google的话，感觉搜索结果中的文章质量会高很多，特别是针对国外的一些网站。
当遇到一个看不懂的异常时，将那一大串不明觉厉的异常日志直接扔到google，百度里，立刻搜出来各种大牛的处理问题的相关博文，这酸爽，大家都懂的。
当然，最关键的是搜索的关键字，这取决于你对bug现象的描述，越言简意赅搜索到的信息反而越多。
四、stackoverflow大法
如果你从事编程多年，还不知道stackoverflow这个牛逼的网站，我只能说你可能是个假程序员。
在这个网站里，你基本上可以找到你开发过程中遇到的所有bug。
如果找不到，你还可以在里面发起提问，会有很多大神给你提供思路和答疑，当然前提是你的英语还不错。
五、问题复现法
一般本地开发环境的异常问题都比较容易复现，比较困难的是测试环境，生产环境的异常问题。
比如网络问题导致的请求失败，服务器配置问题导致请求被拒绝，数据结构和数据记录不一致导致的异常，GC异常，偶然性或周期性出现的异常等等。
总的来说，就是开发环境和测试、生产环境的环境不一致导致问题很难复现。
1、尽可能减少程序运行环境之间的差异
2 、扩大日志记录的时间，记录多个异常周期内的日志
3、记录请求的入参出参
4、本地模拟环境重线异常问题
当你本地能复现问题后，就可以随便整了，可以采用各种手段尝试解决问题。成功后将解决方案照搬到生产环境就可以了。
六、排除法
很多异常很可能可以由多种原因引发，这时候你就需要采用排除法，针对每一个可能的原因去尝试。
还有的时候，针对一些中间件，组件参数的优化，也可以采用排除法。
在你对异常情况没有清晰定位的时候，可以采用排除法，尽可能的缩小异常查找的范围，进而定位问题。
七、同类比较法
这个也是我在开发过程中常用的一种异常定位办法。
典型的场景是，明明是相同或者类似的一个功能模块，A模块里面能正常运行，B模块里面缺一直出现问题。
这时候比较笨的办法就是仔细比较2个模块里面这个功能实现有哪些差异，做一些对应的调整。
程序员不能光会Ctrl+C 和 Ctrl+ V，你可能需要更多的思考。
八、官方文档法
一般来说，官方文档是一个技术或框架的最准确的说明文档，是我们程序开发过程中最直接、最正确的首要依据。
很多时候在网上找的博客文章，往往由于没有说明问题的上下文环境，中间件或组件的版本不一致，导致对自己的问题定位没有什么指导价值。
这时候，通过官方文档你可以获取最正确的第一手资料，是帮助我们定位异常的重要依据。
查看官方文档的时候，一定要选择和自己项目中一致的版本号。
九、源码分析法
真正的大神，定位问题的手段往往都朴实无华。
各种问题都能够直接怼源码，通过手撕源码，达到“他自狠来他自恶 我自一口真气足”的大神境界。
任你异常变化万千，通过跟踪源码，直指问题核心，定位异常原因。
阅读源码这招威力虽然强大，但是对使用者的“内功”会有较高的要求，非3，5年内功不可轻易修炼，使用者需要量力而行。
十、大神求教法
开发过程中，bug万千，作为一个新入职场的小菜鸟，阅历尚浅，内功不够，遇到bug后，首先还是要自己多思多想，尽力尝试分析原因，独自解决问题。
每解决一个bug就是自己程序人生的一次成长的机会，所以不要轻易放过。
当尝试无果后，需要梳理好问题的上下文以及前因后果，然后施展终极大招——大神求教法。这里的大神可以是团队里的老人，可以是技术社区的大佬，可以是技术群里的高人。
得到大佬指点后重新尝试，解决问题后，需要做好相关的异常解决笔记，日积月累之下，自然也成为了同事眼中的大神。
总结
本文主要给大家分享了自己工作多年的bug处理经验，希望大家所有收获，遇见bug再也不慌。
