bug复盘 写这篇文章的本意，是统计自己一共遇上了几个bug，以及那些印象深刻的bug所耗费的时间。可惜现在我的记忆已经有些模糊了，所以如果要统计的话一定要边做边统计，不能拖到做完了再统计。（或许这意味着我应该养成记日记的习惯，每天抽出固定的一段时间来复盘总结） 在这里，只记录哪些耗费了我一天或超过一天时间，或者让我印象特别深刻的bug 1.ant design pro安装界面和教程里的不符，下载后得到的代码也和视频中的不一样 原因：ant design pro的版本更新了，按照视频里的步骤下载的是4版本。而视频里用到的是3版本。同理umi.js也遇到了类似的问题 2.安装springboot项目，maven栏右侧无依赖 原因：同样是视频落伍了，现在需要先创建一个maven项目，然后把生成好的springboot包拖进来。而视频里的方法是通过SpringInit创建 3.springboot的spring-boot-maven-plugin插件一直报红 原因：最匪夷所思的一个bug，我尝试了各种方法，切换仓库位置，删除版本号，配置版本号为XXX，配置下载地址，乃至删除重下……网上找到的各种方法试了个遍，全都没有用，搞得我差点心态崩溃。最后我在版本号位置输入了一个“2“，然后IDEA直接给我显示了”2.6.4“，我选择了2.6.4，然后就运行了。就，很离谱，似乎这个springboot版本只能支持2.6.4这么一个版本，其他任何1版本3版本哪怕是2.6.X版本它都不支持，就支持2.6.4，哪怕我仓库里下了一堆各种版本的spring-boot-maven-plugin插件，它就显示这一个版本。 4.userMapper.selectOne(queryWrapper);语句未执行 原因：印象最深刻的一个bug，卡的时间也最长，甚至逼的我发星球求助。最后的解决也颇具戏剧性，总之这个bug是由两个bug复合形成的，一是我的数据库表没设置主键和自动增长，二是我做测试时是在UserServiceTest类里做的测试，没有用HTTP Cilent做测试，传入的request参数是自己手动创建的request对象，导致代码155行的request.getSession().setAttribute(USER_LOGIN_STATE,safetyUser);报了个空指针异常 5.部署上线环节，前端登录页面可以正常访问到，但是进行登录或注册时，后端总是返回404 原因：后端转发配置文件里，本该是proxy_pass http://127.0.0.1:8080 的地方我写成了proxy_pass http://127.0.0.1:8080/ ，没错，只是多写了一个/，但前者会代理到http://127.0.0.1:8080/api/test.html，而后者只能代理到http://127.0.0.1:8080/test.html，少了一个/api却是致命的差距，因为我所有的后端端口都有/api，因此所有端口都没法访问到。 改进 跟着教程做项目，软件的版本一定要选择完全一致的 在星球做项目时，可以提前看一下星球里学员的笔记和踩坑记录，这能帮自己节省很多时间（但也不太利于培养自己的问题解决能力） 单元测试很重要！每完成一个功能，都要记得及时测试，验证是否能成功运行。一旦拖到后期，再出现问题排查起来会非常困难。 稳住心态，稳住心态，稳住心态，重要的事情说三遍，写程序的过程中永远会遇到各种超乎想象的问题。一个你以为很简单的功能，实现起来可能会耗费远超你想象的时间。一个堪称愚蠢的错误，却能卡住你数天的进度。编码前认真确认需求，每编写一个代码块都及时测试，遇到bug一步步去排查问题并及时记录错误原因。如果实在是被bug折磨到心态崩溃，那就不要继续工作，去洗个澡，睡一觉，出门散散步，放空一下心情，第二天换个思路去查bug，或者组织好语言去问一下大佬让他帮忙看一下程序。要记住大部分事情其实并没有你想象的那么严重，解决它也不会那么复杂。 ”如果你能正确的描述你遇到的问题，那实际上你就已经把这个问题解决了一半“，这句话实际上非常有道理，初学者在涉及一个自己不熟悉的领域时，最大的困扰在于无法用专业的术语问出自己的面临的问题。没有正确的问题，自然就很难得到有用的回答。现在我们有互联网，有chatgpt，只要你正确的提出了问题，99%的问题都能被解答。那么怎么才能正确的提出问题呢？靠”追问“和”迭代“，输入问题，得到的回答看不懂，就把看不懂的地方当成问题继续搜索，直到和自己的固有知识相重合为止。而”迭代“指的是发现自己对问题的描述不准确，得到的回答不是自己想要的后，就尝试用查到的专业术语替换问题中不专业的术语，或者通过排除错误的可能性来逐步缩小问题的范围，或者干脆换个思路重新提问。毕竟互联网上内容虽多，但一个关键词下的内容却有大量都是重复的，一般只会有3到4种不同的解决方案，如果把这3到4种方法都试过了却仍然没解决问题，那这恐怕是个棘手的问题，需要修改措辞重新进行搜索。 在这里可以举个真实例子，我在做用户中心项目时出了一个bug，部署上线环节，前端登录页面可以正常访问到，但是进行登录或注册时，总是返回404。碰上这种情况，我第一时间想到的是后端出了问题，毕竟前端页面能拿到而后端请求却没有响应。因此我搜索时输入的关键词是”后端404“或”nginx后端请求404“，但是事实真的是这样吗？我在搜索无果后，决定做个实验来确认是不是后端的问题，于是我在本地打包启动了后端，然后再启动前端，发现仍然有问题，排查后发现是数据库配置文件出了问题，我没把application-prod文件里的数据库配置成线上数据库。于是我修改了配置，重新打包上传，然而这次还是出错！又经过了一番排查后，我确定这是nginx服务器的问题，准确的说，是nginx服务器没正确转发我的请求，于是我将问题锁定在”nginx后端配置“上并进行搜索，结果找到的第一篇文章就解答了我的问题——原来是请求路径上多了一个斜杠…… 所以要知道，那些困扰你许久的问题往往都很”简单“，甚至简单到了愚蠢的地步，而你之所以找不到答案，是因为答案藏在你视野的盲区，藏在”黑箱“里。那些你只知道怎么做，却不知道为什么能这么做的地方。遇到问题试了各种方法都不管用，可能只是因为你只是在自己”知道“的范围内找答案，就如同我对后端有一定了解，却对nginx服务器完全一无所知，因此本能的在自己觉得安全的后端范围内找答案，不敢把问题归于自己不了解的服务器，因为那意味着自己要去学新的知识，进入未知的领域。然而当山穷水尽时，就是需要你跳出固有思维，逼自己去了解和学习一些新东西。跨出第一步后，你会发现其实没有你想象的那么难。 收获 在解决bug这方面，除了熟悉了一些网站和debug工具外，最大的收获是积累了一套用记笔记的方式记录，总结，复盘bug的工作流。我将其称作WDR模型，它主要包含三个部分—— W：what，这个问题是什么？或者说，发生了什么让你感觉遇到了问题？在W下只尽可能详细的记录自己遇到的异常现象，不要加入自己的主观判断。 D：do，你都做了什么？为解决问题你都采取了哪些行动，每次行动后问题是被解决了，没解决还是更糟糕了？ R：result，结果是什么？bug是被修复了，还是暂时搁置，或是因无法解决而阉割了一部分功能？你是如何解决这个问题的？如何避免类似问题再次发生？ 如果心有余力的话，可以把WDR模型升级成WDRT模型，T就是time，记录自己在每个问题上耗费的时间，结合四象限做事法进一步解决关键问题，提高工作效率。