一些解决 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 手段了。

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

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

屏蔽广告

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

站内搜索

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

关键词搜索

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

限定范围

打开搜索工具，可以给搜索增加限定，比如时间、文件类型等：

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

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

3. 官方文档

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

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

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

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

4. Github

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

如果有解决方案呢可以直接照搬，哪怕没有解决方案，你也可以试着联系遇到类似 Bug 的同学，共同探索。

5. 追溯源码

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

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

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

寻求帮助

如果自己无法解决问题，我们就只能向他人求助了。

提问技巧

提问也是有技巧的，想要更快、更准确地获得答案，就要把你的问题、场景、前因后果、关键信息都提供清楚，还可以利用 PasteBin  之类的工具分享代码，让别人更好读懂。

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

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

所以我建议大家去阅读《提问的智慧》这本免费小书，教你成为一个有智慧的提问者。

地址：https://github.com/tvvocold/How-To-Ask-Questions-The-Smart-Way

途径

想好问什么之后，找谁问呢？

首先是两大平台：国内的 CSDN 相对适合初学者；国外的 Stack Overflow ，更活跃、解答人数会更多。

如果是开源项目，可以考虑在 GitHub 项目仓库下自己提一个新的 Issues ，艾特团队官方人员去解决。

如果你用了别人提供的类库和服务，可以在官方文档中找到项目的维护者，联系他们并反馈。

此外，你也可以加一些专业人员的好友、加些编程交流小队之类的抱团取暖，都是不错的。

---

最后，如果以上方法都解决不了 Bug，那不妨试一试：重启 ！

重启大法好，Bug 逃不了。重启还不行，那就卸载重装~

以上就是本期分享，我是鱼皮，求个 点赞 + 在看 ，这将是我持续创作的最大动力，谢谢 ????

往期推荐

这行代码，很温暖！

为什么我总写 Bug ？

今年最值得看的一篇文章！

多环境

大厂的 SDK 写法，偷学到了！