上一节我们彻底完成了录制生成相关的功能，但其实在越来越多的人知道pity以后，有不少人遇到了部署相关的问题。
大家好~我是
米洛！
我正在从0到1打造一个开源的接口测试平台, 也在编写一套与之对应的教程，希望大家多多支持。
欢迎关注我的公众号米洛的测开日记，获取最新文章教程!
# 回顾
上一节我们彻底完成了录制生成相关的功能，但其实在越来越多的人知道pity以后，有不少人遇到了部署相关的问题。
所以卫衣哥出面帮我编写了一个docker配置，里面不仅包含了MySQL，还包含了Redis，大大降低了部署中遇到的问题。
# 隐藏bug
不过就在他制作镜像的时候，遇到了一个奇葩问题：页面一直重复登录。
这可把我难倒了，我们总结一下现象: 页面好像判断用户已经登录了，又判断用户没登录，所以一下让用户到主页，一下又切到登录页，后端接口则一直在无限重复请求。
于是我开始梳理登录这块的逻辑，视图找到问题的关键所在:
- 当用户进入页面的时候，尝试获取用户的登录态，如果是未登录则弹到登录页面
- 如果是已登录，进入页面后我们会再度校验用户的token是否已经过期，如果过期则又把他弹回登录页，或者token不存在也是如此
# 反复检查
我一开始想到的是redis，因为我们的用户数据会缓存一层。如果redis开启，数据库没值，也会校验通过，但卫衣哥说redis早就清空缓存了。
不过他又给了我个提示: 他的数据库是没数据的。
我反复检查了前端代码，基本判断不存在死循环的问题。那也就是说，只有这一种可能了？
token校验通过了，但是没有给出具体的返回，或者说没有报错，导致前端认为token还是ok的，进入主页再次校验，发现没拿到数据库的用户信息，就导致2个步骤，1个对1个不对，无限循环了？
我们看看后端代码，就恍然大悟了:
之前没有这多余的2行，由于卫衣哥传入的token是确凿的，我们系统能解析的，解析完毕之后拿到了user_info，我们这边去db二次校验获取user，我们也没有检查user是否存在，也就是说接口并不报错。
最终就导致了悲剧的发生: 小区大门保安让进了，小区单元楼不让进，让你去保安那拿钥匙，无限循环了。
所以改善的地方就是: 加一个用户是否存在的判断即可:
if user is None:
return PityResponse.failed("用户不存在")
# 或者直接抛出异常
# raise Exception("用户不存在")
2
3
4
# 还有问题
还要记得，我们是有一个Depends的中间件的: Permission，这个里面同样需要改造一下:
这里我们也是只解析了用户token，没有校验数据库是否真有这个用户。
# 也就是我们把__call__改成async模式，接着对用户查询一次即可。
今天就是本节的bug案例了，最新的部署文档和代码都已经提交了，欢迎大家鞭打~其实这之后我又发现我们的response提取参数用不了了，我真的会谢。
不愧是bug王子
我只想说：回归测试真的很重要，有时候我改着改着老功能就不行了，尽管你对系统再熟悉，也有疏忽的时候呀！！！
希望大家引以为戒，认真对待测试~~