bug 查找 (二) 从前端找到后端

几天来，组长说我们系统的 apm 数据不正确，最体表现就是前端项目这几天错误统计为 0。

这不正常(没有办法，我们代码写的很烂)，因为前端环境很复杂，网络，浏览器都有可能出现错误，一天 100 多错误也是正常。

而 WebAPM 也是由我来写的，于是开始找 bug 之旅。

过程

1. 因为代码是我写的，我在了解到问题的情况下，问了下线上环境是否有变化，回答是否定的，没有改；上线新功能没，回答也是没有上线新功能，只能定位到是自己写代码的问题。

2. 找到与问题相关的代码了一下，(这个是谁写的代码)，完全没有看懂，花去一些时间去熟悉代码，一上午就过去了

3. 光看代码没有找到问题，下午要起动程序进行调试，分别是 nginx , 前端项目，后端项目，webapm 项目启来，发现 onerror 没有加载错误

4. 然后找到代码查看，发现开发模式下，window.onerror 需要对脚本进设置成 crossorigin 才能抓到 url。以为找到了问题，这个问题自己也找了一段时间。这个不是 bug 在生产环境下已经打开。

5. 然后找到 cookie 发现是通过 cookie 进行数据的保存的。发现 cookie 没有设置成主域名而是在 www 下，以为因为读不到，所以没有发，结果代码测式，可以发。

6. 然后再到控制台进行模拟出错，然后提交，发现是可以的。

7. 多次尝试发现数据库报错，某个字段报错。

8. 组长才想起来运维组把数据库升级了，数据库升级了，数据库升级了。

9. 然后解决问题，mysql 在旧版本时，字段类型是数字，你写入数据时可以写入空。但是新版不可以了。所以我们写入写入一个默认值 0.

解决问题总结

一天就解决这一个 bug，现在晚上进行一个总结和反思：

1. 出现了问题，光凭看代码，没有想第一时间复现问题。这是自己的问题，虽然环境挺复杂，但也不是不能配。

2. 基础知识不扎实，对 onerror 的作用范围不明确，对 cookie 的读写也不明确，导致错误查找很慢。

3. 动手能力弱，碰到问题，总是希望不启动环境去解决问题。以后如果环境复杂就要想到如何去简化环境，然后复现问题。

4. 问题还是在与组长的配合中解决的，组长的动手能力让我佩服。

5. 现在想想，这个问题在本地架起了环境也解决不了问题，因为本地数据库与以前是一致的，跟线上是不一致的。

6. 其实有很多机会去解决这个bug的，都没有抓住，在线上写数据时，日志太多没有抓到这条错误，而我们最后构造请求然后马上去看就发现了这个错误。

7. 还是有很多的知识盲点没有学到，这要加油去学。