【Bug周刊】Vol.6

Bug周刊Bug周刊随手记

【Bug周刊】Vol.6

客怎眠qvq2024-08-152024-08-23

前言

最近开发中遇到很多相同的问题，下意识去翻自己的历史记录，但又没能快速定位。我的trilium一直用来记录自己的周报和相关教程，对于常见的bug和修复方案也找不到合适的地方，只能穿插在日报的历史中，随时间沉没。无意间翻到子舒的奇趣周刊，Bug周刊也由此而生。

天庭二周目，所有仙尊、魔尊的后手都刷新出来了……好好好，痛快！

菜单权限

对之前临时接手的项目进行菜单权限改造，编写用户/角色对应的菜单列表查询接口，配置用户/角色权限后的保存接口。

补充一些遗忘的知识点:

1️⃣ 在获取前端查询 query 参数时，可以直接用结构体接收，但获取 body 里的 json 时，就需要加上 @RequestBody 注解。

2️⃣ 在进行保存/更新操作时，JPA 根据某两个等效条件删除数据时，可以直接 deleteByIdAndName(id, name)，不用再写查询语句，别忘了加上 @Modifying 和 @Transactional 注解。

3️⃣ 在使用 ant design 表格组件时，一定要加上 rowKey 参数，不然会出现特殊情况：第一次查询的结果仍保留在第二次查询渲染的表格中未被销毁。

引用站外地址

自定义antd的table属性rowKey

博客园

日志中心

公司的综合管理系统有将登录、操作行为记录到 elastic 的操作，每次调用一个封装好的 api 服务，由该服务负责所有日志的读取和查询。但是这个服务半年来一直处于无人维护的状态，每次启动后撑不过几分钟就崩了，也没有人排查错误，最近临时接手这个项目的维护。

一开始以为，项目代码性能不足，想着直接重构，本地启动后 postman 调用相关接口直接寄，一通操作后发现一个诡异现象，服务刚启动时的第一次调用，接口一定是正常的，后续调用都会报 500，判断是某个接口在查询返回结果后，进行了其他异常操作。

分析了代码后，原项目封装了一个 EsConfig 作为 Bean，相当于在第一次正常启动后，持久化了es的配置信息，有三个接口在完成查询操作后，手动关闭了这个 Bean，导致之后该服务的任何接口都无法获取到es的配置信息 或者说 与 es 建立的连接没了。

@Autowired
EsConfig esConfig;  // @Bean 直接声明在controller层用了😭


public Result<Object> search2(EsLogEntity<Object> esLogEntity){
  // 原项目使用了 @Bean 注解，esclient 实际上使用后是不需要关闭的
  RestHighLevelClient client = esConfig.esClients();

  // 请求头构建

  // 相关查询条件绑定

  // 发起请求获取查询结果

  // 罪魁祸首 只声明了一次 EsConfig esConfig; 
  // client.close()后，其他接口调用的 esConfig.esClients() 是已经关闭后的
  client.close();
}

总结：半年前有开发将封装了一个 Bean 在 controller 层，他自己用时就直接调…… 属于编码规范问题，如果是在具体的 Implement 中，关闭也不会有任何影响