RuoYi-Vue-Pro项目中菜单树过滤逻辑的优化实践

问题背景

在RuoYi-Vue-Pro 2.1.0版本中，存在一个关于菜单树展示的逻辑问题。当管理员将某个包含子菜单的根目录标记为不可用状态时，该根目录下的子菜单仍然会出现在生成代码时的父菜单选择列表中。这种情况会导致系统展示出不符合预期的菜单结构，可能给用户带来困惑。

问题分析

通过深入分析，我们发现问题的根源在于系统当前的菜单树过滤逻辑不够完善。具体表现为：

1. 系统在查询菜单列表时，仅简单过滤了直接标记为不可用的菜单项
2. 对于父菜单被禁用的子菜单项，没有进行递归过滤
3. 前端展示层没有对菜单树进行二次处理

这种实现方式虽然简单直接，但无法满足"当父菜单被禁用时，其所有子菜单也应被视为禁用"的业务逻辑需求。

解决方案比较

针对这个问题，开发团队提出了两种可能的解决方案：

方案一：级联更新状态

原理：在更新父菜单可用状态时，同步更新所有子菜单的可用状态。

优点：

• 实现简单直接
• 查询时无需额外处理

缺点：

• 可能引发不必要的授权异常
• 状态变更不够灵活，难以应对临时禁用菜单的场景
• 不符合"开闭原则"，修改状态会影响多个菜单项

方案二：服务端动态过滤

原理：在查询菜单列表时，服务端构建完整的菜单树结构，并过滤掉所有父ID非0且被禁用的根菜单及其子菜单。

优点：

• 灵活性高，可以临时禁用菜单而不影响实际数据
• 符合单一职责原则，过滤逻辑集中在服务端
• 不会产生级联的授权问题

缺点：

• 每次查询都需要进行额外的过滤计算
• 服务端处理压力略有增加

经过团队讨论，最终选择了方案二作为实现方案，主要基于以下考虑：

1. 更符合业务场景需求，特别是需要临时禁用菜单的情况
2. 避免级联更新可能带来的副作用
3. 虽然增加了服务端计算负担，但在现代服务器性能下影响可以忽略

技术实现细节

在具体实现上，我们采用了以下技术方案：

1. 服务端过滤逻辑：

   • 首先查询所有可用的菜单项
   • 构建完整的菜单树结构
   • 递归遍历菜单树，移除所有父节点被禁用的子树
   • 返回过滤后的菜单列表

2. 性能优化措施：

   • 使用内存缓存减少数据库查询
   • 采用高效的树遍历算法
   • 对常用菜单结构进行预计算

3. API设计：

   • 保持原有API接口不变
   • 在服务内部实现过滤逻辑
   • 确保向前兼容

实际效果验证

实施该解决方案后，系统行为符合预期：

1. 当管理员禁用某个根菜单时，其所有子菜单不再出现在任何选择列表中
2. 菜单状态变更可以即时生效，无需重启服务
3. 系统性能无明显下降
4. 用户体验得到提升，菜单选择更加直观准确

总结与建议

通过对RuoYi-Vue-Pro项目中菜单树过滤逻辑的优化，我们获得了以下经验：

1. 树形结构数据处理：在处理树形结构数据时，不能仅考虑节点本身的属性，还需要考虑其在整个树中的位置和上下文关系。

2. 状态管理策略：对于具有层级关系的数据，状态管理需要特别谨慎。级联更新虽然简单，但往往不是最佳选择。

3. 性能与灵活性权衡：在大多数现代应用中，适度的性能牺牲换取更好的灵活性和可维护性是值得的。

4. API设计原则：保持接口稳定，在服务内部实现业务逻辑变化，是良好的API设计实践。

对于类似系统的开发者，建议在处理层级数据时：

• 充分考虑业务场景需求
• 评估各种实现方案的长期维护成本
• 进行充分的性能测试和用户体验测试
• 保持实现的简洁性和可扩展性

这次优化不仅解决了具体的技术问题，也为项目中类似的数据处理场景提供了有价值的参考方案。