前言

在默默的算着，2023年300多天的日子已经悄然无息的从我手中流走，还没来得及细细的品味，2023年即将逝去。在最近工作中，遇到了两个线上比较棘手的bug，今天，就对自己2023年写过的bug来个复盘吧

2023年写过的bug

截至今日，以下数据是2023年每月我解决操作过的bug数据分布：

以上大多数是测试阶段的bug,个别是线上的。作为一个码农，自认为在提测前对自己写过的功能保持着一个比较负责任的心态，尽量保持高质量的提测。但，没有谁能保证不写 bug，不出错的。我们要做的，是在bug出现以后，找到问题的根源，解决问题，避免同类问题再次发生。

解决一线上纰漏bug流程复盘

1、bug现场

前几天公司为迎接双十一，搞满减满折活动促销，对全场商品(除个别商品)仅仅开启每满200-70的满减满折活动，收到反馈，个别商品列表活动的标签显示错误,列表有500个左右商品，大概5个左右商品标签差个每字

2、代码逻辑

后台创建满减满折活动时，会将哪些商品能参加这个活动具体的标签写入缓存中，C端查询商品列表时，会去商品查询缓存，查看这个商品正在参加的进行中的活动的标签返回给前端展示。由于后台满减活动的配置逻辑是我做的，标签也是我写入缓存的，看到这个反馈，我心中第一反应，满减活动创建添加商品标签的缓存逻辑代码有bug?

3、排查思路

• 
  
• 测试环境创建一个满减满折活动，看是否个别商品满减标签显示错误，发现没有问题，复现失败
  
• 让测试协助，是否测试环境能否复现此bug,测试也无法复现
  
• 由于这块我没有特意代码补充日志，公司框架也没有全局去拦截请求的入参，靠日志排查之路走不通
  
• 怀疑是否还开启了别的活动，商品是否还参与别的活动，冲突导致，查看数据库数据，发现目前仅仅就开启着这一个活动
  
• 怀疑是否曾经开启过满200-70的活动，发现也没有开启过
  
• 去看数据库500个左右的商品，5个标签错误的商品找出规律，没有发现
  
• 活动创建，后编辑该了类型？发现活动创建成功后，也没有编辑过
  
• 活动创建前端参数错误？回头着重去看我写的那块代码，再三斟酌，没有发现有问题，就算前端参数错误，为啥就那几个商品少了个每次，此路也不通
  
• 想过并发，没有道理，因为创建活动就当时一个人操作
  
• 想过很多人线上复现不了的bug最常见的解释，网络波动，我那也不应该，要么写入失败，不会写入成功，少一个字
  
• 想过redis的缓存数据被人工手动改过？毕竟是线上的，不会随便改，也不应该，概率可以忽略
  
• 既然C端的标签是从缓存拿去的，无奈我项目全局搜索所有用到设置商品缓存代码逻辑，一个个前后调用去看，最后给我看到了查询满减活动表，然后设置标签的代码，一步步定位最终最外层controller代码，才发现商品编辑那里有修改商品缓存的逻辑，只要涉及到商品编辑，那里会先删除这个商品的所有缓存，然后在添加缓存，由于那块组装商品标签逻辑和我创建活动添加标签逻辑不一致，少了一个类型判断导致
  

由于商品管理那块，我没有参与过需求的评审，开发、设计，所以从始至终排查问题都没有想到过那里会影响我做的满减满折活动的商品标签

4、问题解决

任何一个bug,能复现找到问题的根源就好解决，最棘手的时没有人能复现，又没有日志，完全去猜各种可能性

5、总结

• 
  
• 针对一些难以复现的bug或者遇到的技术问题 ，找到根本原因很重要
  
• 要多了解业务，把各种变更造成的影响，要能提前预知到
  
• 如果项目框架没有完善的全局日志记录，重要地方适当打印下日志