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层用了
