技术选型的"踩坑"经历
"XX开源框架更新了，我们用最新版吧？"
"这个技术很火，大厂都在用，肯定没问题！"
"自研最灵活，为什么要用别人的？"
半年后，团队成员在群里吐槽：
- "动态部署怎么又失败了？"
- "前端组件怎么不兼容？"
- "SQL生成有bug，又要改代码..."
技术选型，不是选最新，而是选最适合。
我们踩了不少坑，最终选定了3个核心技术栈。
问题1：如何实现动态部署？
核心需求：运行时安装/卸载应用，不需要重启平台。
对比的4个方案
方案 | 优点 | 缺点 | 结论 |
Spring Cloud | 生态完善 | 需要重启，部署重 | ❌ 不符合需求 |
OSGi | 成熟稳定 | 学习曲线陡峭 | ❌ 维护成本高 |
自研类加载器 | 完全可控 | 开发周期长 | ❌ 重复造轮 |
SOFA ARK ✅ | 阿里开源，专门为动态部署设计 | 需要学习 | ✅ 选择这个 |
为什么选择 SOFA ARK？
理由1：成熟稳定
- 阿里巴巴生产环境使用10年+
- 支撑双11大促
- 开源社区活跃（3k+ stars）
理由2：专门为动态部署设计
基座Biz（一直运行）├── 子应用A（30秒安装）├── 子应用B（热更新，不停止）└── 子应用C（独立卸载）理由3：Spring Boot原生支持
<dependency> <groupId>com.alipay.sofa</groupId> <artifactId>sofa-ark-springboot-starter</artifactId></dependency>一行依赖，开箱即用。
问题2：前端如何低代码？
核心需求：JSON配置生成页面，不需要写前端代码。
对比的4个方案
方案 | 优点 | 缺点 | 结论 |
Element Plus + 设计器 | 组件丰富 | 需要开发设计器 | ❌ 开发成本高 |
自研JSON引擎 | 完全可控 | 重复造轮 | ❌ 维护成本高 |
Ant Design Pro | 蚂蚁金服出品 | 需要写React代码 | ❌ 不是真正的低代码 |
AMIS ✅ | 配置即页面 | 需要学习JSON | ✅ 选择这个 |
为什么选择 AMIS？
理由1：真正的低代码
{ "type": "crud", "api": "/jd/get", "columns": [ {"name": "id", "label": "ID"}, {"name": "name", "label": "姓名"} ]}配置JSON，页面自动生成。
理由2：50+内置组件
- 表单类：input、select、date、upload...
- 展示类：table、cards、chart...
- 布局类：grid、tabs、carousel...
理由3：与后端解耦
前端：AMIS JSON配置 ↓后端：提供数据接口（APIJSON）前后端分离，各司其职。
问题3：数据库操作如何简化？
核心需求：少写SQL，统一数据访问。
对比的4个方案
方案 | 优点 | 缺点
| 结论 |
MyBatis-Plus | 流行 | 需要写Mapper | ❌ 代码重复多 |
JPA | Java标准 | 性能一般 | ❌ 复杂查询弱 |
自研SQL生成器 | 完全可控 | 开发周期长 | ❌ 容易有bug |
APIJSON ✅ | 自动化CRUD | 需要学习语法 | ✅ 选择这个 |
为什么选择 APIJSON？
理由1：自动化CRUD
POST /jd/get{"User": {"userId": 1}}→ 自动生成SQL→ 自动返回结果不需要写Mapper、Service、Controller。
理由2：关联查询强大
{ "User": {"userId": 1}, "Department": {"deptId@": "/User/deptId"}}一行配置，自动JOIN。
理由3：动态公式
{"userId": "@uid()"}{"createTime": "@now()"}内置函数，自动填充。
选型决策的3个原则
对比了8种方案，我们总结了3个选型原则：
原则1：解决核心问题
问自己：这个技术解决了什么核心问题？
- SOFA ARK → 解决动态部署问题
- AMIS → 解决前端配置问题
- APIJSON → 解决重复SQL问题
如果核心问题不匹配？不选。
原则2：成熟度优先
问自己：这个技术经受过生产考验吗？
- SOFA ARK → 阿里生产10年+
- AMIS -> 百度开源，5年+
- APIJSON -> 4年+，100+项目使用
如果没有生产案例？不选。
原则3：社区活跃度
问自己：这个技术有活跃的社区吗？
- SOFA ARK → GitHub 3k+ stars
- AMIS -> GitHub 11k+ stars
- APIJSON -> GitHub 4k+ stars
如果社区不活跃？不选。
技术栈总览
最终选定的核心技术栈：
低代码平台技术栈├── 动态部署：SOFA ARK 3.1.10│ ├── 基座Biz（Master Biz）│ └── 子应用Biz（Multiple Biz）│├── 前端框架：AMIS│ ├── 50+组件│ ├── JSON配置驱动│ └── 与后端解耦│└── 数据访问：APIJSON ├── 统一端点（/jd/*） ├── 自动化CRUD └── 关联查询支持选型结果：
- ✅ 满足所有核心需求
- ✅ 成熟稳定
- ✅ 社区活跃
- ✅ 学习成本可控
避坑指南
技术选型中，我们踩过的坑：
坑1：追新不追稳
❌ 错误：用最新版、Beta版 ✅ 正确：用稳定版、LTS版
教训：我们试过SOFA ARK的一个SNAPSHOT版本，结果动态部署失败，回退到稳定版才解决。
坑2：自研不借鉴
❌ 错误：自研类加载器 ✅ 正确：借鉴成熟方案
教训：花了2个月自研，最后发现SOFA ARK已经解决了所有问题。
坑3：忽视学习成本
❌ 错误：选择复杂的框架 ✅ 正确：选择易用的方案
教训：AMIS虽然需要学习JSON，但比React开发简单10倍。
总结
技术选型，不是选最新，而是选最适合。
对比了8种方案，我们选择了：
- SOFA ARK（动态部署）
- AMIS（前端低代码）
- APIJSON（数据库简化）
选型的3个原则：
- 解决核心问题
- 成熟度优先
- 社区活跃度
记住：
- 追新不如追稳
- 自研不如借鉴
- 复杂不如简单
与其追求"最新最酷"的技术栈， 不如选择"最稳定最合适"的方案。
技术选型有风险，决策需谨慎。
系列文章：
- 第1篇：为什么我们需要自己的低代码平台？
- 第2篇：18个月开发200+功能，结果用户只用到5个
- 第3篇：对比了8种方案，我们最终选择了这3个技术栈（本文）
- 第4篇：SOFA ARK 核心概念详解
