一、问题背景
用户群里面有个别用户反馈系统卡主了，一直在刷新，但就是出不来，但是我们本地又是好好的。让用户清空一下缓存，再次刷新就又好了。这个问题乍一看是系统不行的样子，但是查看监控又发现指标一切正常，并没有异常的情况发生。
二、问题分析
因为是偶发性问题，用户的bug场景已经消失，没办法远程查看用户的电脑，所以只能根据现有问题，将bug复现出来。
1、排除法定位问题
首先我们可以确定，这个问题是个别用户 特殊场景下产生的，所以可以排除是系统架构问题。然后有一个很明显的点，用户清空缓存之后，就恢复正常，我们服务对外提供接口，是没有缓存之分的，所以问题大概率出现在客户浏览器上面。
还有一个很明显的问题是：前端页面一直在刷新出不来，跟前端沟通发现，如果getUser接口请求没有得到正确的响应，就会一直等待。所以问题再次缩小为：getUser接口没有返回200的正确请求。通过后端api调用日志，可以确定用户出问题的这段时间，没有错误请求进来。
getUser为用户基本信息接口，前端会根据用户信息来判断各种权限。
api的日志没进来，我们可以确定这个接口在nginx端就被拦截了，通过查看nginx端的日志，发现了很多getUser请求报Http 400 Bad Request问题。分析到这一步，我们基本可以把思路放在，什么错误场景下才会产生Http 400错误。
Http 400异常场景参考博客： https://blog.csdn.net/zhuyiquan/article/details/78707577
三、找到问题原因
通过对能够产生Http 400的场景进行分析，最终确定是：Http请求头的cookie超过最大限制导致nginx返回400的错误，跟我们的问题场景最符合。跟前端确认产生cookie的页面操作后，最终定位到是登录/退出的页面操作，然后本地不断进行登录然后退出，发现getUser的cookie会越来越大，数据量达到4KB的时候，就返回400错误，复现出用户的问题了。
cookie是什么，最大限制是多少，可以参考： https://juejin.cn/post/6844904100035821575
四、修复方案
找到问题后，问题的解决方案就简单很多了，既然是cookie太大从而导致的Http 400错误，那就在退出登陆的时候清空历史cookie即可，但是有一点需要注意的是，如果用户处于已登录状态下，访问系统的登录接口，要强制性重定向到登陆后的控制台页面，不能在已登录情况下，重复登录。
所以对应的处理方案为：
- 后端修改点：登出接口将历史废弃cookie删除。
- 前端修改点：登录页面下，进行用户登录状态判断，如果已登录就重定向到控制台页面上。
五、复盘总结
虽然找到问题并解决，但同时也暴露出更多的问题来，解决这一个问题并非我们的最终目的，最终目的应该是避免或者更快的找到问题，解决一类的问题。
1、过程存在的问题
- 前端对getUser判断太过暴力，非200就一直刷新，一方面影响用户体验，一方面没办法快速定位问题。
- 监控体系不够完善，发生多个Http 400错误，没有提前感知到并报警，因为用户主动反馈的都属于一定级别的故障。
- 登录/登出的核心功能，方案设计不够完善，cookie清空的基本点都没有考虑到。
2、长期的解决方案
1、完善监控
不仅仅是对系统各个环节进行监控，还要对用户的客户端进行监控，比如console控制台错误，兼容性问题等。设置各类异常点的报警，将报警推送到开发可以看得到的地方（邮件、短信、电话等）。
2、完善规范
前后端对接严格遵循规范，对请求参数、返回值、错误信息等的处理进行明确的要求。对于方案的设计要按照要求：先出设计文档，技术研讨确定，最后再实施测试，让每一次方案设计都能够尽可能的完善，减少出错的概率。
3、制定bug问题库
对每次发生的bug进行复盘总结，形成文档沉淀到公司的bug问题库中，后续不管是遇到问题还是方案设计，都可以借鉴参考，让已经发生的问题，不再重复发生。
