新项目全栈框架选 Ruoyi 还是 芋道/Jeecgboot

ruoyi 吧。。。这玩意用的人多，容易找到解决方案

芋道吧

同 ruoyi

没流程需求就 jeecg ，有流程就芋道
有预算也能买 jeecg 商用版带流程

毕业设计框架

ruoyi

直接用 springboot ，最符合“生态好, 可扩展性强, 稳定可靠少坑”

脚手架

这又是要走 N 年前的老路，前后端重新和并？

Rails

前段时间公司也有类似需求 我看了几个 https://github.com/feiyuchuixue/sz-boot-parent ，https://github.com/valarchie/AgileBoot-Back-End

芋道风评很差，v2 搜一下

ruoyi-vue-pro 和 ruoyi-vue-plus 二选一就行，两者各有长处。芋道风评差是因为他文档收费，不是东西差

Ruoyi ，衍生项目多

Ruoyi 芋道 Jeecgboot renren-fast 商业版都用过，首先排除 Jeecgboot ，代码老，包袱太重。

其他的，拉下来都大量魔改过，感觉没什么大区别

@duhb AI 加持，前后一起干，省一个人，工作时长不变，工资不多。

刚做过一个 Jeecgboot 的,方便是方便,但是确实包袱太重了

yudao 太大太重了

ruoyi-vue-plus 还行

我们这也不用前端人员了 别管干得好不好 反正先砍了再说 ai 可真的是 未来可期 - -！

反正国产框架一律作为备选中的备选. 能有国外平替绝不用国内版. 除非是类似 Doris 这种已经成为知名开源基金会项目的.

都用过

jeecg 太重，适合长期开发的大项目

芋道还行，风评不太好，如果芋道自带的一些功能和业务贴合那就合适

ruoyi 有很多轻量改版，开发快，生态内容多

推荐我开源的一个轻量框架，只包含系统管理和个人中心等基础功能，不带工作流，集成了 AI 。React 、Vite 和 Java21 + Spring Boot 。地址： https://xryder.cn

刚使用 ruoyi-vue-plus 开发了一个项目，感觉很顺手，之前买过 bladex 使用，问问题还得看技术心情

@ymz #16 AI 使用费还让那一个人承担

Jeecgboot ，至少有一个稳定的公司团队在迭代升级，实在不行你还能购买商业版来解决问题，适合长期项目用。
ruoyi 版本很多，总有一款能比较适合你手头项目，但是偏短期使用。长期哪个不是什么功能都得上？

推荐 ruoyi-vue-plus
芋道也读过源码，感觉他们维护没有 ruoyi-vue-plus 积极。

我现在用的是 continew-admin ，当然我不是推荐你用，因为这个项目还在不断优化，可能不能满足你需要工作流的需求

@aLazarus continew-admin 这个框架我看了下用的技术都是当前最主流的框架, ui 设计很现代化, 如果我不使用工作流或者后续整合 flowable, 你建议使用这个框架吗

@mark257 #30 我不好说，只能说对于代码洁癖的人来说是可以的尝试的，但是功能还不完善比如多租户还正在迭代。需要考虑作为脚手架来说，很大概率确定一个版本之后就不会再更新了，所以这种迭代中的脚手架并不一定适合所有项目

@flashBee233

我们之前公司也用的 pig4 ，个人接单开发得话 eladmin ，smartadmin 都有用过，smartadmin 代码生成功能挺不错的，页面也好看

首先，你要搞明白，ruoyi 和 jeecgboot 都不是框架，而是一套“后台管理系统模板”。基于此，建议：

1. 如果对可扩展性有要求，两个都别用，这两个模板提供的业务代码设计上都是垃圾，在垃圾上堆出来的，可扩展性极低，坑肯定很多。

2. 其次，要求生态好，那就要选 react ，不要 vue ，就算三方库的数量，react 至少是 vue 的五倍以上。

以上建议不适用于以下前提：

1. 贵司的人无法辨别 ruoyi 和 jeecgboot 那套业务模板是金子还是粪便，这样随便选一个都能能提高贵司上限。

2. 如果你们没有(不想招聘)前端程序员，只有(只想招聘)前端模板员，那别在乎什么生态好，就选 vue 吧。

-----

说完上述观点，我觉得选哪个对你都是一样，因为你给出选型的需求里面，都是务虚，对项目业务需求一个字都没提。所以选哪个看运气，跟你个人水平没关系(因为你处于一个选型的时候完全不看业务需求的水平层次)，运气好刷刷做完，运气不好项目尾款收不到你背锅被炒鱿鱼，不过最大的锅还是老板背，因为最终亏钱的是他/她。

@chinfeng 好个高高在上的语气，既然你建议 react ，能否在回复里给出几个脚手架建议？

@rechardwong0522

首先这两玩意都不是脚手架，你的理解有问题。其次 ruoyi 和之上的 jeecg 基本就在第一个层次，这套系统的整个底子，从架构层面看起来就是 60 后程序员的产物，充满了各种错误且过时的实践。我的建议是：

- 一次性做项目，需求明确，规模中小，能跑起来交付就行，那可以用
- 在此之上，如果你能接到后续的单子都是高度同质的(需求差异最好不超过 10%)，那可以用
- 你想形成自己的技术积累，别用
- 你想做一个适配多种业务的系统，别用
- 如果你想你的成品可扩展性强，别用
- 如果你想生态好，对一个 2025 年还停留在 spring-boot 2.x 和 vue 2.x 的模板，千万别用

@chinfeng 是脚手架还是模板，只是定义不同而已，都是为了快速开发，免得造轮子。另外，你倒是推荐一个认为优秀的“模板”啊？

@rechardwong0522 定义决定认知，如果 ruoyi yudao 是轮子，那是一个质量很差的轮子，承载不了太多东西，用这玩意做的东西天花板特别低，还想什么技术积累、扩展性的就是难为自己。但是今天在中国仍然充斥着大量只要很低交付水平的需求，因此这类 admin 模板就能在这些低质产出中找到自己的生态位。

如果你还在找这种优秀模板，那就是停留在业余水平的那种认知层次。就像是你刚把自己的自行车升级到了小轿车，然后坐上了驾驶位还在寻找比较舒服的脚蹬差不多感觉。

@chinfeng 干话一大堆，就是不回答我、不推荐一个你认为好的模板，拜拜了您

@rechardwong0522 建议用 ruoyi-vue-plus

@rechardwong0522 你说得对，我就是不告诉你。

@mark257 谢谢，调研了一圈，我也选了这个。

@rechardwong0522 你这调研也太水了，5202 年了都还要选 mybatis 作为技术栈……

以前的我对这种脚手架嗤之以鼻，用过一次芋道后发现至少还有代码的分层分包分模块设计，待过几家公司的代码都没这么优雅..

@zhiguang 是这样的，主要是由于中国软件产业还很落后，交付质量要求低的市场还是有的，所以 ruoyi 才有生存的空间。还有很多团队甚至清一色的都是培训班出身的二把刀，就是靠老板关系交付，只要美工设计漂亮就不需要靠技术交付，比 ruoyi 质量差也不奇怪了。