【脚手架bug调试】直接修改数据库数据以后，将会发生什么？

cho.1出现bug的背景

昨晚，大秋（也就是鄙人）约小秋、xl来实验室调bug。由于菜单接口出现了“为空”的情况，大秋看了看数据库，猜测大概是后端数据之间逻辑出了问题，二话不说，修改了数据库的值。然后像个二哈一样，在一边看着两个前端调试，以为没自己啥事。
结果调来调去，这个接口又出现“为空”的情况。作为后端，二哈不得不开始思考到底咋回事。于是用狗爪子画了一张图梳理逻辑，并且debug了一会儿。终于发现问题，由于菜单需要最后递归形成树状结构，但是之前改数据库的时候没有考虑到逻辑的严密性、一致性，所以最后的数据没有父级，也就导致了最后接口返回结果“为空”。

cho.2bug调试过程（后端）

IDEA的debug方法省略，在之前是先看了数据库数据，然后看了服务器上的日志，才开始本地调试。
逻辑梳理图（保密信息已打码）：

使用debug，按照前端传参-后端处理-数据库数据的顺序，把每一步的数据记录下来，然后思考所得到的数据是不是预期的，如果是则继续获得下一步数据，如果不是，则思考为什么没有达到预期（这里一般就是bug的问题所在了）。
说一下思路：
前面数据一路正常，直到最后，都没有问题，但返回后为空，代码如下：

//authTree是一个工具类，用于生成权限树
//token=加密后的用户名
return Msg.success().add("msg",authTree.menuList(modules));

那么这里只有可能是menuList方法出了问题，于是继续看menuList的逻辑，传入的参数如上图所示，是模块管理、用户管理、角色管理，而这三个的父级是系统管理，但大秋并没有给这个用户系统管理的权限，因此，导致menu接口变成这样：

修改就很简单了，直接改数据库，把父级的权限给这个角色就ojbk

cho.3多谢后世人，戒之慎勿忘！

1. 数据库备份
2. 源码备份
3. 设计时最好有文档
4. 日志备份
5. 调试日志记录（可以定期整理成博客）
6. 调bug时最好不要直接修改数据库，否则容易破坏逻辑，最好是由前端（或者使用postman等）来修改数据。如果实在需要修改数据库，可以先理清楚逻辑。

#以上备份可以上传至gitee（or github but it’s not recommended）