解决 Bug 的流程套路总结

本文来自程序员鱼皮的 编程导航

学编程的过程中，我们会遇到各式各样的 Bug，也常常因为它们而感到头秃。

但随着你不断解决 Bug、积累经验，就会发现其实解决 Bug 也是有套路的。

解决 Bug 的能力也是衡量一个程序员水平的重要因素，大佬可能看到一个报错信息立刻就知道怎么解决，而新手可能连百度去搜一下报错都不知道。

下面分享鱼皮自己总结的解决 Bug 的流程和套路，帮助大家提高编程学习效率，保护头发。

解决 Bug 的流程套路总结

本文大纲：

一、准备工作

其实改 Bug 的过程就跟破案是一样的。

首先，在急着去搜索问题、上手写代码改 Bug 之前，先做这么几件事。

1、获得更多信息

就像案发现场找目击者、搜集证据一样。

我们要搞清楚 Bug 何时发生？为什么会发生？在什么情况下发生？

用户到底做了什么操作，才导致了 Bug ？

是每次都会出现 Bug，还是说点儿背触发了呢，如果是偶然触发，是否可复现呢？

不能复现的 Bug，还叫 Bug 么？（狗头）

这些信息，都很重要。如果可以的话，最好还能拿到用户详细的报错原因、请求和响应，信息多了，才能帮助我们更精准地定位和分析问题。

2、明确边界

说白了，就是通过手上已有的信息，搞清楚要把这个 Bug 算在谁的头上？

举个例子，假如说用户突然访问不了你的网站了。这时千万别自己先搁那傻傻分析和排查一通，而是可以先访问下网站试试。要是你能访问的话，说不定根本就不是 Bug，而是用户自家的网线断了！

企业开发中往往是多人协作，比如前端和后端、服务提供者和服务调用者，如何判断是谁写的 Bug 呢？

一般我们可以通过 接口 的请求参数和响应参数来划分职责。

比如我是前端，请求你后端的接口，向你发送 "鱼皮"，你必须要返回我 "狗头"。结果最后出现 Bug 时，我一看，我给你发送的是 "鱼皮"，你却给我 "鱼头" 了对吧，那显然是你那边的 Bug，雨我无瓜。

3、保护现场

确定是自己的 Bug 后，如果是线上程序出了 Bug，记得先把当时的程序状态保留下来，比如 dump 内存、下载日志，便于后面排查。

就和破案一样，案发现场的东西千万不能随便乱碰，要不然可能就缺失了关键信息。

接下来看看如何解决 Bug。

二、自行解决

每个人的时间都很宝贵，出了问题时，先不要盲目地去问别人，而是自主思考、自力更生。

可以通过以下方式自己解决：

1、自查

程序出了问题时，最直接的排查方式就是：对程序的报错、已记录的错误日志进行分析。

比如看到程序报错 "db connection timeout"，显然就是数据库连接超时了，这个时候可以先去确认下是不是网络和数据库自身的问题，说不定就已经能解决 Bug 了。

如果不理解英文，是不是可以借助一些翻译工具呢？

2、搜索引擎

俗话说得好，遇事不决问某度，这可能是大家最常用的解决 Bug 手段了。

但如今的某度搜索引擎对程序员不太友好，广告多、内容过时、点进去后文不对题，这些都会成为你搜索的障碍。

那大家不妨试试这些技巧：

1）屏蔽广告

在搜索词后加上 "-advertisement" 可以快速屏蔽搜索的广告信息：

2）站内搜索

使用 site:域名 + 搜索词，可以在特定的网站内快速搜索，像现在大部分 Bug 的解决方案其实都在 CSDN：

3）关键词搜索

使用某度搜索长句的时候，可以将错误信息中的关键词拆解出来，比如版本号、数据库类型等，使用空格进行连接叠加关键词，可以更加精准搜索想要的结果，避免连接词的干扰。

4）限定范围

打开搜索工具，可以给搜索增加限定，比如时间、文件类型等。技术更新迭代太快，建议搜索时间范围 一年内 的文章，时效性更高一些。

当然，其他的搜索引擎也都有自己的搜索技巧，大同小异。

比如大家可以试试 开发者搜索 ，专门面向程序员的搜索引擎，纯净很多。而且看起来它的实现方式也很简单，就只从开发者相关网站中搜索内容就行了。

3、询问 AI

AI 技术的发展异常迅猛，我们完全可以将 AI 当做自己的 Bug 排查助手。

可以把自己的问题描述清楚、或者直接将报错信息甩给 AI，就能快速得到参考答案和解决思路。搭配搜索引擎一起使用，相信能解决 90% 以上的 Bug。

比如使用鱼皮团队开发的鱼聪明 AI（ https://yucongming.com/ ），或者其他的 AI 工具都是可以的。

4、官方文档

当我们使用一些冷门技术或者较新的技术时，国内的搜索引擎可能很难找到解决方案。

这时不妨打开官方文档，直接搜索到和自己问题相关的部分，仔细阅读一遍，说不定就发现其实是自己语法或参数写错了呢？

在官方文档搜索内容：

其实，很多 Bug 就是因为阅读文档不仔细而产生的！

对于组件库、SDK、类库、插件、API 的使用，我其实更倾向于去阅读官方文档，比较直接，一针见血。

5、Github Issues

如果你使用的是开源的项目，那么可以试着在项目仓库的 issues 中搜索答案，尤其是知名项目，用的人很多，你遇到的 Bug 有可能别人也遇到过。

如果有解决方案，可以直接照搬；哪怕没有解决方案，你也可以试着发起一个 issue 提问，或者联系遇到类似 Bug 的同学，共同探索。

这也是一种直接和 GitHub 开源大佬交流的方式哦~

6、追溯源码

除了依赖冲突、内存溢出之类的技术上的 Bug，其实我们工作中更多地是修复业务逻辑上的 Bug。比如做一个支付功能，用户 A 扣了钱，但是没有任何反应。

这种情况也别费功夫在网上搜了，因为每个人写的业务代码都不一样，五花八门。不如自己从程序的入口开始，用 Debug 打些断点、打印一些变量信息，一行一行慢慢调试就好了。

打断点调试：

如果你怀疑是某个依赖的类或方法出了问题，也可以直接点进去查看它的源码和注释。

三、寻求帮助

如果自己无法解决问题，我们就只能向他人求助了。但是，先明白一点，别人没有义务帮你解决问题，怎么才能让自己的问题更容易被别人帮忙解决呢？

1、提问技巧

提问也是有技巧的，想要更快、更准确地获得答案，就要把你的问题、场景、前因后果、关键信息都提供清楚。

像鱼皮之前每天都会收到上百条私信提问，其中很多同学连自己要问什么都描述不清楚，比如：我网站为啥无法访问了？

这种问题别人怎么帮你解决呢？这不是耽误彼此的时间么？

建议在找别人提问前，请一定要把以下几点列举清楚，并且发送给你要提问的人：

1. 我遇到了什么问题