是的，这不是美版也不是欧版，这是中国特色的 eSIM 卡，中国特供版 eSIM 卡，当然没实体卡方便啊！

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

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

大佬这意思很明确：我们不是针对你们这些老实人，而是针对那些冚家都是老实人的！

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

5202 的今天，已经不需要这样的库了。

现在的前端流程是：shadcn 先梭个基础组件下来，然后上 ai 去微调这些组件的功能即可。

以前我觉得这是好东西，现在看生态位太尴尬了。

如果让一个 java 团队都达到能掌握这套框架的程度，付出的成本还真不如让他们直接学 go 。

而且微服务部分跟 spring-cloud 一样尴尬，里面绝大部分的东西，5202 的今天大部分已经不需要在应用开发框架上解决，基础设施已经覆盖掉大部分功能。

目前 AI 做 fragment 是没问题的，你必须把问题切得足够小，然后让 AI 解决很小的问题。

然后你自己在解决工程集成的问题。

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

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

@rechardwong0522

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

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

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

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

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

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

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

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

-----

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

这个做不到！

作为一个勤恳的程序员，我们能做到的是让别人堆屎山，然后把我自己写的屎山隐藏在别人的海量屎山之中，这样我就不会被人看扁了。

如果你觉得py3 比py2 省不少事，那你是没用过 py2。就是因为两者在编码效率上没有明显差距，但py3 却要花额外的成本处理兼容性问题，所以才没人愿意去升级。