最近在忙一个 project ，因为时间比较紧张，所以自己就比较着急反而花了更多时间。今天这个项目大概已经可以收尾了，自己也知道为什么当时 bug 没解决。这里总结下。

Bug 总结

这个 bug 其实是由两个错误设置导致的。我在本地有两个代码分支，每个分支都需要运行四到五个子程序。每个分支还需要两个配套文件，但这两个文件会因为一个数据源的更改而有所不同。结果是，每个分支各自出现了一些错误，导致一个分支成功，而另一个分支失败。

我最初看到的是一个分支成功了，所以误以为数据源没有问题并且已经更新成功了。其实，那个分支之所以成功，是因为它还在使用旧的数据源，而我没有更新它。另一个失败的分支是因为我更改了数据源，而新的数据源没有更新，所以失败了。但是在调试过程中，我一直认为我的数据源已经更新了，因为我不理解为什么另一个分支成功了。

最后，我将数据直接推送到 beta 环境。这时，我确认数据源没有问题，并发现本地失败的分支反而成功了，因为它需要的新数据源已经存在。而本地成功的分支却出现了问题，因为它还在使用旧的数据源。我在检查配置时才发现这个问题。

经验总结

1. 第一性原理

在解决问题时，特别是在调试过程中，不要只头疼医头，脚疼医脚。尤其是当你发现这是一个复杂的调试问题时，更应如此。有时候，简单的 bug 可以通过直接查看错误迅速定位，但对于复杂的调试，一定要保持清醒，假设每一个步骤都有可能出错。即使是成功的部分，也要考虑是否是由于某种巧合而成功，是否存在误打误撞的情况。

2. Local 环境第一问题是数据

通常，local 环境的数据是从 prod 环境复制过来的。然而，S3 Sync 的特性是不会删除已存在的文件，因此，如果多次复制数据，可能会出现同一文件的多份副本。所以，在调试之前，先确认数据的正确性。

3. 如果可以，进行 Shadow Run 还是直接推送到正式环境。有时 local 环境会出现问题，主要是因为配置和数据不同。prod 环境的 shadow run 不会产生 sev-2 的问题。

4. 即使时间紧张，Debug 也不能跳过步骤。按照步骤一步一步来，才是最稳妥的解决方案。这是 debug 是出现了问题，这个时候追求效率反而不是最有效率的。