从2019年7月17日下午4点到晚上11点的痛苦追踪，再从2019年7月18日上午10点到下午4点的柳暗花明，终于解决了一个大坑一个神坑。感觉一定要记录下来解决历程和最终形成的思考，要不然白瞎这么痛苦的追踪了。
如何入坑
测试小姐姐在检查一个bug的时候一顿意外操作发现一个隐藏bug，生活总是充满了意外，华丽丽的指派给了我。简单说就是有个表单在保存的布局结构和再次编辑时的布局结构不同，而且复现起来很难。首先拿到这个bug我就头大，一顿操作要拖动40多个字段到布局里来，复现一次花费贼多时间。然后很慌，不管三七二十一，先抓请求，然后在请求的接口上打断点，一顿调试，追踪，结果一无所获。具体的业务内容还是得保密，只能大致说说自己先入为主的错误想法：由于数据访问频次较大，所以使用Redis来缓存数据，所以保存布局报错第一时间怀疑的就是缓存没有清空，一直在缓存这里兜圈子。本次的解决方式是：
保存的时候就有问题，每次保存的时候虽然全部拖动到左边，应该传入146个字段，但是每次保存的时候入库的有时候101，有时候95，调试编辑布局的时候获取字段数量与数据库内该次扩展一致，确认问题出在保存的时候，然后调试POST接口，发现前端在每次传入partsXml参数的时候都不一样，后端逻辑遵循前端的xml参数，所以问题出在前端给的partXml上，给的参数不对
这里说说自己犯的错误：
- 先入为主错误思想：主观臆断，以为就是架构缓存的问题，没有考虑其他可能性，主要还是逃避排查问题的心理作祟。
- 没有获取稳定复现：没有获取比较稳定的复现，就是看到的bug复现可能只是原因的其中一个表象，而非全部。
- 没有反映真实情况：找大佬帮忙查问题的时候，说了太多自己主观看法，例如缓存清理问题，导致大佬思路被带到缓存检测这里，所以第一步反映的应该是客观的问题，然后再谈自己不确定的看法，并且明确自己的看法有几分把握。
- 没有理解整个流程：再没有理解整个流程的情况下，直接切到断点处排查问题，很容易跑偏。
以上体现的这几个错误点，都体现在阅读历史代码解决问题的过程不够规范,并且有一定的逃避和不愿意看的心理这其实是更深层次原因，有逃避问题的倾向，老觉的不是自己的问题，其实解决bug的过程不光是单纯解决问题，还对自己熟悉整个执行流程有很大的帮助，没有逃避的必要，再说这个问题总该归你解决。
思考总结
再次遇到类似问题的时候该怎么处理呢？我觉的正确的流程应该是这样的，就以这次的这个bug为例：应该遵循这样的流程：
观察问题，获取稳定复现：第一步就是要获取稳定复现，其实头一天晚上在复现的过程中没有彻底搞清楚状况，没有获取终极复现，稳定复现应该是这样：
- 1 点击恢复的时候再次保存才会复现
- 2 已经产生的租户级布局过的编辑布局不会再次复现
而最开始只是认为保存后没有保存布局这样一个简单看法，没有找到精准的复现场景。
理解流程：理解完整实现逻辑：第二步其实应该做的是对整个流程进行梳理，来判断哪一步有问题，而不是先入为主的盲目定位到缓存位置。
进入逻辑：断点调试逻辑：确认好流程后，最好跑一遍流程，熟悉一下实现过程，并理解代码实现过程。
推断和验证：推断验证所有可能性：这一步应该能推断出这样的可能性
- 前端传入的参数验证，是否正确传参
- 后端Controller层需要进行断点调试，逻辑是否有误
- 缓存清理逻辑，服务器端和本地缓存是否清理成功
找到三种可能出错的地方并进行一一验证，才能分析出整个环节问题可能出现在哪儿。不应该直接就定位到缓存。事实证明，最后的问题就是因为历史数据缺乏校验导致的xss攻击，所以一开始前端参数就有问题。后边怎么查都没用。
找大佬协助：陈述客观事实并提出自己看法：这里要承认一波，根本没详细的分析问题就言之凿凿的自己主观看法给亮哥，导致一开始分析就朝着缓存走。问题大大的。正确做法应该是合理提出事实和自己的推断。
复盘和提炼：复盘就是俺这篇博客文章了，提炼就是：目前的站点存在前后端不分离造成的xss攻击现象，只能通过输入限制来进行避免，后期是否能改造下呢？历史未经校验的数据再进行的xss攻击该怎么解决呢？
当然核心就是不逃避问题按照流程去处理问题，你会发现，经过艰苦奋斗的debug比解决普通问题成就感大多了，至少我可以总结下实施站点的实现逻辑了！by the way ,找合适的人处理合适的事情，脸皮要厚！
