若依帮了大忙，也限制了我。这篇文章讲清楚——哪些保留、哪些重写，以及最重要的：边界画在哪。

一、选若依，我不是冲动

2025 年初决定做 MES 系统时，摆在我面前的选择有三个：

方案 优势 劣势
从零手写 完全自由 一个人写死也写不完
直接用开源产品 拿来就用 印刷包装行业没有现成的
基于若依二次开发 基础功能开箱即用，Spring Boot 3 版本成熟 需要理解框架后再定制

我选若依，不是因为它最好，而是最适合一个人起步：

  • 用户管理、角色权限、菜单管理：这三个模块如果从零写，至少一个月。若依直接给，还能代码生成。
  • Spring Boot 3 + Vue3 技术栈：和我自己的技术栈完全一致，学习成本为零。
  • 代码生成器：一张表 10 分钟生成一套 CRUD，一个人顶三个人的开发速度。
  • 社区活跃：Gitee 8k+ Star，遇到问题搜得到答案。

独立开发者的第一原则：不要在基础设施上证明自己，把时间花在业务差异化上。

二、若依给了什么，我没动的部分

用了若依之后，下面这些模块我基本没改，直接复用：

2.1 权限体系（RBAC）

若依的五表权限模型（用户-角色-菜单-部门-岗位）对大多数企业级系统够用了。我只在菜单权限的基础上，加了按钮级权限指令：

1
2
// 若依自带的 v-hasPermi 指令
<el-button v-hasPermi="['system:user:add']">新增</el-button>

这个设计很精妙——权限字符串存储在数据库，前端通过指令控制显示，后端通过注解二次校验。一条没改，直接用到生产。

2.2 代码生成器

若依的代码生成器是我用得最多的功能。通过 Velocity 模板，输入表名 → 生成 Controller、Service、Mapper、Vue 页面。

我只做了两处调整：

  • 生成的 Vue 页面默认是若依风格，我改了一版模板，统一注入自己的公共组件
  • 生成的 SQL 映射默认只支持 MySQL 语法，多数据源场景下需要手动处理

没有代码生成器，我一个人不可能在 100 天内写完 40+ 张表的 CRUD。

2.3 系统管理模块

功能 是否保留 说明
用户管理 ✅ 原封不动 够用
角色管理 ✅ 原封不动 够用
菜单管理 ✅ 保留，扩展了图标选择器 若依的图标太少
部门管理 ✅ 保留，加了数据权限联动 部门和数据权限强绑定
岗位管理 ❌ 隐藏了 制造业不需要岗位概念
字典管理 ✅ 保留，扩展了字典标签动态渲染 系统配置全靠它
参数管理 ✅ 保留 全局参数配置
通知公告 ✅ 保留，改了推送逻辑 接入了生产异常通知
日志管理 ✅ 保留，加了数据同步日志 多数据源场景专属

三、哪些地方必须重写

若依是个好脚手架，但不同行业的业务逻辑差异巨大。下面是我重写的核心部分：

3.1 数据权限：从无到有

若依的权限是”菜单级”的——你能看到哪个页面。但制造业的需求是：

  • 质检员张三只能看自己负责的机台数据
  • 车间主任李四只能看本车间的生产任务
  • 老板能看到全厂汇总

这是行级数据权限，若依没有内置支持。我写了 @DataScope 注解：

1
2
@DataScope(deptAlias = "d", userAlias = "u")
public List<ProductionOrder> selectOrderList(ProductionOrder order);

通过 MyBatis 拦截器在 SQL 执行前动态拼接 WHERE 条件，按角色过滤数据范围。这个模块完全从零写的，但思路参考了若依的 AOP 设计模式。

3.2 多数据源：从玩具到生产

若依的 dynamic-datasource 能切换数据源，但在真实异构数据库场景下不够用：

  • 事务管理需要显式指定 TransactionManager，否则跨库不回滚
  • 异构数据库（MySQL + SQL Server + Firebird）的字段映射需要 DTO 层
  • Firebird 的编码问题、驱动版本兼容问题框架完全没覆盖

这些在上篇文章《若依框架多数据源实战》里有详细复盘。一句话总结：若依给了地基，但上面每一层都得自己加。

3.3 移动端：从若依 App 到自研 CRM

若依社区有 RuoYi-App（基于 uni-app），但它是管理后台的移动版，不适合我们的 CRM 场景。销售需要的是客户拜访、商机跟进、合同管理、售后工单——这些若依 App 完全没有。

我只保留了若依 App 的 Token 认证和请求封装，其余全部重写。所以上一篇文章才说「若依 App 框架深度定制」。

3.4 业务模块：从零构建

这部分和若依无关，纯粹是印刷包装行业的业务逻辑：

  • 生产工单与 BOM 管理
  • 工序流程设计
  • 质检体系（IPQC/IPFQC/FQC）
  • 设备管理与 OEE
  • MES-CRM 数据打通

若依在这些地方帮不上忙，也不需要帮忙——它本来就定位为通用后台框架。

四、重写的边界在哪里？

这个问题我想了很久。结论是两条边界线：

1
2
3
4
5
6
7
8
9
┌──────────────────────────────────────────┐
│  若依负责                          │
│  登录 → 权限 → 菜单 → 字典 → 日志    │
│  用户管理 / 角色管理 / 代码生成器      │
├──────────────────────────────────────────┤
│  我们负责                              │
│  数据权限 / 多数据源 / 业务模块          │
│  移动端 CRM / 质检体系 / 生产流程       │
└──────────────────────────────────────────┘

若依管”系统怎么跑”，我们管”业务怎么做”。

这条线划清楚之后，开发效率提升了很多。不会再纠结「这个功能若依有没有」，而是直接判断：若依管不管这事？不管就自己写。

五、若依框架的三个不足

用了大半年，若依有几个地方确实让人头疼：

5.1 前端耦合度高

若依的 Vue 页面大量依赖 this.$store、this.$router 的直接调用，组件之间的数据流不够清晰。虽然 Vue3 版本改进了不少（支持 <script setup>），但很多页面还是 Options API 的写法混在 Composition API 里。

5.2 少部分代码风格老旧

比如前端大量使用 this.$refs.xxx.validate() 而不是 ref 绑定。这不算 bug，但不够 Vue3。

5.3 升级路径不友好

若依从 Spring Boot 2 升到 3、从 Vue2 升到 Vue3，没有平滑升级方案，基本等于重搭。这对基于若依做了大量二次开发的项目来说，代价很高。

但这些不足不是若依的问题——它是一个通用框架，不可能照顾到每个人的升级需求和代码偏好。

六、从不做开源到做内容：我的路径选择

MqCode 目前没有开源——它是一个商业产品，承载着公司的核心业务逻辑。

但不开源不代表不输出。我选择了另一条路：写技术文章，公开思路和方案。

不公开 公开
核心业务代码 架构设计思路
客户数据 技术选型决策过程
商业逻辑细节 踩坑记录和解决方案

比如多数据源方案、数据权限设计、质检模板架构——这些不涉及核心商业代码，但能让同行看到技术深度。

已经有客户告诉我：「看了你的文章，觉得你懂这个行业，才联系你的。」

七、给同样站在路口的人

如果你也在纠结要不要基于若依做产品，我的建议是：

  1. 若依适合作为起点，不适合作为终点。 它帮你跳过从 0 到 0.5，但从 0.5 到 1 只能靠自己。
  2. 先跑通核心业务，再考虑替换框架组件。 不要一上来就改这改那，业务逻辑才是你的护城河。
  3. 保留若依的权限体系。 这是若依最成熟、最值得保留的部分。
  4. 自己写业务模块时，不用若依的代码风格。 保持自己的代码规范，减少升级负担。