Opensource on Liangweidong's blog

Spring Boot 与 JDK 版本演进：从 1.5 到 3.2 的二十年 Java 生态大事记

Sun, 15 Dec 2024 00:00:00 +0800

2024 年 12 月，Spring Boot 3.4 刚发布、JDK 21 LTS 满一年、JDK 17 LTS 满三年。回看过去 28 年（1996 JDK 1.0 - 2024 Spring Boot 3.4），Java 生态的版本节奏从"5 年一版 LTS"加速到"2 年一版 LTS"。对于一个 Java 团队来说，版本选型就是技术战略。

本文写于 2024 年 12 月——JDK 17 LTS 是当下主推、JDK 21 LTS 崭露头角，Spring Boot 3.3/3.4 是生产首选。下文的部分早期版本（JDK 8、JDK 11、Spring Boot 2.x）以"2024 视角回望"的方式呈现。

一、JDK 版本演进时间线（1996-2024）

版本	发布日期	关键特性	状态
JDK 1.0	1996-01-23	Java 起点	已淘汰
JDK 1.1	1997-02-19	内部类、反射、JavaBeans	已淘汰
JDK 1.2	1998-12-04	Collections 框架、JIT、Swing	已淘汰
JDK 1.3	2000-05-08	HotSpot JVM、JavaSound	已淘汰
JDK 1.4	2002-02-13	正则、NIO、日志、XML	已淘汰
JDK 1.5	2004-09-30	泛型、注解、枚举、并发包	已淘汰
JDK 1.6	2006-04	动态语言支持、HTTP Server API	已淘汰
JDK 1.7	2011-07-28	G1 回收器、try-with-resources、菱形语法	已淘汰
JDK 1.8 LTS	2014-03-18	Lambda、Stream、Optional、Nashorn、移除 PermGen	当前生产主力
JDK 9.0	2017-09-21	模块系统（JPMS）、JShell、HTTP/2 Client	已淘汰
JDK 10.0	2018-03-21	局部变量类型推断 `var`	已淘汰
JDK 11 LTS	2018-09-25	HttpClient、ZGC（实验）、Lambda var、移除 Java EE/CORBA	生产新主力
JDK 12.0	2019-03-19	Switch 表达式（预览）	已淘汰
JDK 13.0	2019-09-17	文本块（预览）	已淘汰
JDK 14.0	2020-03-17	Records（预览）、NPE 增强提示	已淘汰
JDK 15.0	2020-09-15	ZGC + 密封类（预览）	已淘汰
JDK 16.0	2021-03-16	Records 正式	已淘汰
JDK 17 LTS	2021-09-15	Sealed Classes 正式、Switch 模式匹配	2024 当下生产主力
JDK 21 LTS	2023-09	虚拟线程正式	2024 新晋 LTS

1.1 LTS 节奏

1.6 (2006) → 1.7 (2011)：5 年
1.7 (2011) → 1.8 (2014)：3 年
1.8 (2014) → 11 (2018)：4 年（Oracle 改为"3 年一版 LTS"）
11 (2018) → 17 (2021)：3 年
17 (2021) → 21 (2023)：2 年（开始加速）

对企业选型的启示：

5-7 年一个 LTS 周期，意味着企业 JDK 升级周期约为 3-5 年
选 LTS 版本长期维护，规避非 LTS 短期版本

1.2 JDK 8 的"长寿"原因

JDK 8（2014-03-18 发布）到 2024 年 12 月已经 10 年，至今仍有一批存量系统在跑（行业惯性 + 商业 JDK 8 商业支持仍在售）。原因：

Lambda + Stream 改变 Java 编程范式
Optional + CompletableFuture 提升函数式能力
方法引用 / 默认方法 增强接口演进能力
Nashorn（已废弃）首次带来 JVM 跑 JS 能力
PermGen → Metaspace 减少 OOM 痛点

直到 JDK 11 出现，Java 生态才"集体升级"。2024 视角回望：JDK 8 的"长寿"在 JDK 11 / JDK 17 之后才被真正打破——这也是 LTS 节奏从 5 年压缩到 2 年的拐点。

1.3 JDK 11 的 5 大新特性

HTTP Client API 标准化（孵化多版本后正式）
ZGC 可用（毫秒级 GC 暂停，4TB 堆支持）
Lambda 参数 var（写 (var x, var y) -> ...）
移除 Java EE / CORBA（瘦身 30%+）
飞行记录器（JFR）开放（生产可启用）

二、Spring Boot 版本演进时间线（2014-2024）

版本	发布日期	关键特性	JDK 要求
Spring Boot 1.0	2014-04	起步	JDK 6+
Spring Boot 1.2	2015-01	引入 starter 体系	JDK 6+
Spring Boot 1.3	2015-11	`@SpringBootApplication`	JDK 6+
Spring Boot 1.4	2016-04	`@SpringBootTest`	JDK 6+
Spring Boot 1.5	2017-01	Kafka/Actuator 完善	JDK 7+
Spring Boot 2.0	2018-03	WebFlux、Reactive、Java 8+	JDK 8+
Spring Boot 2.1	2018-10	GraalVM（实验）、性能优化	JDK 8+

2.1 Spring Boot 版本命名规则

1
2
3
4
5
6
7
8
9


Alpha：不建议使用，主要是以实现软件功能为主，通常只在软件开发者内部交流，Bug 较多；
Beta：该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除；
GA：General Availability，正式版本，官方推荐使用此版本，在国外都是用GA来说明release版本；
M：又叫里程碑版本，表示该版本较之前版本有功能上的重大更新；
PRE(不建议使用)：预览版，内部测试版，主要是给开发人员和测试人员测试和找BUG用的；
Release：最终版本，Release不会以单词形式出现在软件封面上，取而代之的是符号®；
RC：该版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发行的正式版相差无几；
SNAPSHOT：快照版，可以稳定使用，且仍在继续改进版本。
SR.X：修正版，服务版本，当项目发布积累到一定程度，需要修复该版本中的某个错误后以此来命名，X表示数字。

2.2 截至 2024-12 的版本选择

1
2
3


3.0.0(SNAPSHOT) 最少 java17 （未发布）
2.7.5(SNAPSHOT) 最少 java8 （生产）
2.6.13(SNAPSHOT) 最少 java8 （生产）

生产推荐（2024 视角）：

保守派：Spring Boot 3.3 + JDK 17（LTS 长期维护组合）
激进派：Spring Boot 3.4 + JDK 21（虚拟线程 + 模式匹配）
存量维护：Spring Boot 2.7（已于 2023-11 停止 OSS 支持，仅商业支持）

2.3 Spring Boot 2.6 → 2.7 关键变化

2.6（2021-11）默认禁止循环引用：

1
2
3
4


# application.yml
spring:
 main:
 allow-circular-references: true # 2.6 之前隐式允许，2.6+ 默认禁止

2.7（2022-05）核心新特性：

@AutoConfiguration 注解（替换过时的注册方式）
GraphQL 支持
Podman 支持（替代 Docker）
RabbitStreamTemplate 支持
Hazelcast 支持
Cache2k 支持
Web Server SSL 增强
Info 端点增强
单元测试加强

三、版本选型实战建议（2024 年时点）

3.1 新项目起步

场景	JDK	Spring Boot
企业内部管理系统	17	3.3
互联网电商	21（虚拟线程）	3.4
金融/政府强合规	17（合规）	3.2（稳定）
IoT 边缘计算	21	3.4

3.2 升级路径

JDK 8 → JDK 11 升级清单：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


# 1. 升级构建工具
mvn -version # 确认 Maven 3.5+

# 2. 升级依赖
<dependency>
 <groupId>javax.xml.bind</groupId> <!-- 移除 -->
 <artifactId>jaxb-api</artifactId>
</dependency>
<!-- 替换为 -->
<dependency>
 <groupId>jakarta.xml.bind</groupId> <!-- JDK 11+ -->
 <artifactId>jakarta.xml.bind-api</artifactId>
 <version>2.3.3</version>
</dependency>

# 3. 升级 IDE
# IntelliJ IDEA 2018.3+ 支持 JDK 11

# 4. 升级框架
<parent>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-parent</artifactId>
 <version>2.1.0.RELEASE</version>
</parent>

Spring Boot 1.5 → 2.1 升级清单：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


<!-- javax → jakarta 替换 -->
<dependency>
 <groupId>javax.servlet</groupId>
 <artifactId>javax.servlet-api</artifactId>
</dependency>
<!-- 替换为 -->
<dependency>
 <groupId>javax.servlet</groupId>
 <artifactId>javax.servlet-api</artifactId>
 <version>4.0.1</version> <!-- 升级到 4.0+ 支持 Jakarta EE -->
</dependency>

<!-- Tomcat 8 → 9 -->
<!-- Hibernate 5 → 6 -->
<!-- Thymeleaf 3 → 4 -->

3.3 监控升级

升级后必做的几件事：

JVM 启动参数对比：

1
2
3
4
5


# JDK 8
JAVA_OPTS="-Xms4g -Xmx4g -XX:PermSize=512m -XX:MaxPermSize=512m"

# JDK 11+（PermGen 已被移除）
JAVA_OPTS="-Xms4g -Xmx4g -XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=512m"

GC 切换：

1
2
3
4
5
6
7
8
9


# JDK 8 默认
-XX:+UseParallelGC

# JDK 11 推荐（低延迟）
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200

# JDK 11 试验（超低延迟）
-XX:+UseZGC

监控接入：

1
2
3
4
5
6
7
8
9


# Spring Boot 2.1 Actuator
management:
 endpoints:
 web:
 exposure:
 include: "*"
 endpoint:
 health:
 show-details: always

四、写在最后

2024 年这个时点，Java 生态已经历了"JDK 17 → JDK 21"、“Spring Boot 2.x → 3.x"两轮大升级。对于一个想保持竞争力的 Java 团队：

保守策略：JDK 17 + Spring Boot 3.3 → 2025 评估 JDK 21 升级
激进策略：JDK 21 + Spring Boot 3.4（2024 当下就用，吃虚拟线程红利）

个人建议：

2024 年新项目：直接用 JDK 21 + Spring Boot 3.4

已有项目升级：以 JDK 17 + Spring Boot 3.3 为目标版本，2025 上半年完成

长期规划：2026 年底前完成所有项目 JDK 21 升级

五、2024 视角回望 2018

站在 2024 年 12 月回望 2018 年 12 月那篇文章的选型判断，6 年时间 Java 生态的演进有三条主线：

LTS 节奏真正加速：2018 年还是"3 年一版 LTS"的预期，2024 年看是"2 年一版 LTS”（17→19→21）。企业升级窗口期被进一步压缩
Spring Boot 2.6/2.7 完成了 1.x → 2.x 最后的过渡：默认禁止循环引用（2.6）、@AutoConfiguration 注解（2.7）都是为 3.0 破坏性升级铺路
GraalVM 从实验变实战：2018 年 Spring Boot 2.1 提"GraalVM 实验"，到 2024 年 Spring Boot 3.x + GraalVM Native Image 已成云原生部署标配
JDK 8 的"超长服役"被打破：2024 年新项目几乎默认 JDK 17+，“用 JDK 8 起步"已是历史

参考资料

国内 SaaS 后台脚手架三巨头横评：jeecg-boot / ruoyi-cloud-plus / yudao-cloud

Sun, 15 Sep 2024 00:00:00 +0800

2024 年 9 月，回看 2017 年那个时点——国内"后台管理系统脚手架"赛道已经走过 7 年——从 jeecg-boot 一枝独秀，到 RuoYi 系生态扩散，再到 yudao-cloud 的"商业文档 + 全套 UI"打法，三款框架占据了 7 年里国内中小企业 SaaS 后台的 80% 选型份额。本文站在 2024 年（这三款已经稳态发展的时点）做一次系统性的横评。

本文写于 2024 年 9 月——jeecg-boot 已演进到 3.7+、RuoYi-Cloud-Plus 已是 Dromara 旗舰、yudao-cloud 仍是"商业文档 + 全套 UI"打法。三巨头在 2024 年都做成了"全家桶"，但技术选型的分叉其实在 2017-2020 年间就埋下了。

一、三巨头基本信息

维度	jeecg-boot	RuoYi-Cloud-Plus	yudao-cloud
首个版本	2014-09	2019-08（RuoYi-Cloud 起点）	2020-04
组织	个人 → 团队 jeecgboot	Dromara 组织（dromara.org）	芋道源码（个人）
GitHub 仓库	jeecgboot/jeecg-boot	dromara/RuoYi-Vue-Plus / aiclear/RuoYi-Cloud-Plus	zhijiantianya/yudao-cloud
核心定位	低代码 + 代码生成 + 工作流	快速开发 + 多租户 + 微服务	商城 + 会员 + 营销 + 报表全场景
前端技术栈	Vue 2/3 + Ant Design Vue	Vue 3 + Element Plus	Vue 3 + Vben Admin
后端技术栈	Spring Boot 2.6.6（3.4.2 版本时点）	Spring Boot 2.7+ / Spring Cloud Alibaba	Spring Boot 2.7+ / Spring Cloud Alibaba
代码生成器	前后端一键生成（含在线设计器）	简单模板生成	高级模板（带业务逻辑）
付费/免费	免费 + 商业版	完全免费	文档收费 199/年 + 代码免费

说明（2024 视角）：jeecg-boot 的"3.4.2 版本"实际发布于 2022-09-22，但 jeecg-boot 项目本身在 2014 年就启动了。本表以"3.4.2 版本时点"为参照点，对照 2017 年那个时点 jeecg-boot 还在 1.x 时代。

二、定位差异：低代码 / 快速开发 / 全场景

2.1 jeecg-boot：低代码 + 表单设计器

jeecg-boot 的差异化武器是 “在线表单设计器” 和 “代码生成器”：

可视化建模：在网页上拖拽生成表单/列表/报表，无需手写 Vue 组件
代码生成器：数据库表设计完成后，一键生成前后端代码 + 菜单 + 权限
工作流引擎：内置 Activiti/Camunda，支持复杂审批流
报表引擎：积木报表 + JimuReport 拖拽式大屏

适用场景：

政府 / 国企 / 事业单位的"信息管理系统"（OA、ERP、CRM 等）
业务表单多、流程长、但不需要高并发的内部系统
团队希望"零代码 + 少量定制"完成交付

2.2 RuoYi-Cloud-Plus：快速开发 + 多租户

RuoYi 系是国内"快速开发脚手架"的事实标准，到 2019 年的 RuoYi-Cloud-Plus 已经演化成：

多租户体系：基于 MyBatis-Plus tenant_id 字段的全链路隔离
SaaS 架构：单服务多租户 + 多服务多租户两种模式
完善权限：RBAC + 数据权限 + 按钮权限三级粒度
代码质量：阿里编码规约 + 完整单元测试

适用场景：

中小企业 SaaS 产品（要卖给多个客户）
内部系统多、组织结构复杂
团队希望"接过来就能改"而不需要从零搭

2.3 yudao-cloud：全场景商城 + 报表

yudao-cloud 是"商城 + 营销 + 会员 + 报表"一体化的产物：

完整商城：商品 / 订单 / 支付 / 物流 / 退款 / 售后
营销中心：优惠券 / 拼团 / 秒杀 / 积分 / 抽奖
CRM 会员：会员等级 / 权益 / 储值 / 邀请
数据大屏：基于 VChart + 大屏模板

适用场景：

电商 / 新零售 / 直播带货系统
需要快速搭建"商业化产品"原型
团队愿意买文档（199/年）来省时间

三、技术栈对比

3.1 后端对比

组件	jeecg-boot	RuoYi-Cloud-Plus	yudao-cloud
Spring Boot	2.6.6	2.7+	2.7+
Spring Cloud	Hoxton	2021	2021
注册中心	Nacos	Nacos	Nacos
配置中心	Nacos	Nacos	Nacos
网关	Spring Cloud Gateway	Gateway	Gateway
权限	Shiro + JWT	Sa-Token（Plus 版本）	Sa-Token
ORM	MyBatis-Plus	MyBatis-Plus	MyBatis-Plus
数据库	MySQL/Oracle/PostgreSQL	MySQL/Oracle/PostgreSQL/SQLServer	MySQL/Oracle/PostgreSQL
缓存	Redis	Redis	Redis
消息队列	RabbitMQ/RocketMQ/Kafka	RocketMQ/Kafka	RocketMQ/Kafka
工作流	Activiti/Camunda	Flowable（可选）	Flowable（可选）

3.2 前端对比

组件	jeecg-boot	RuoYi-Cloud-Plus	yudao-cloud
框架	Vue 2/3	Vue 3	Vue 3
UI 库	Ant Design Vue	Element Plus	Element Plus
状态管理	Vuex / Pinia	Pinia	Pinia
构建工具	Vite	Vite	Vite
包管理	pnpm/yarn	pnpm	pnpm
组件库丰富度	高（Ant Design 全套）	中（Element Plus + 自封装）	高（Vben Admin）
移动端	uniapp + 微信小程序	单独 RuoYi-App	uniapp（yudao-ui-admin-uniapp）

四、代码生成器对比

这是三巨头最容易拉开差距的地方：

维度	jeecg-boot	RuoYi-Cloud-Plus	yudao-cloud
生成方式	在线设计器 + 模板引擎	Freemarker/Velocity 模板	代码生成器 GUI
生成内容	前后端全套（含权限、菜单、字典）	增删改查 + 简单校验	完整业务（含状态机）
数据库支持	MySQL/Oracle/PostgreSQL	MySQL/Oracle/PostgreSQL/SQLServer	MySQL/Oracle/PostgreSQL
模板定制	支持自定义模板	支持	支持（更细粒度）
生成代码质量	中（基础 CRUD）	中	高（含 Service 业务逻辑）
特殊处理	表单设计器 + 工作流	多租户字段自动注入	业务状态机自动生成

实战建议：如果你只需要"表单 + 列表 + 增删改查"——jeecg-boot 的"零代码"最快；如果你要"业务状态机 + 完整流程"——yudao-cloud 的代码生成器更智能；如果你的团队在 RuoYi 生态深耕多年——RuoYi-Cloud-Plus 的迁移成本最低。

五、二开组织流程对比

5.1 jeecg-boot：fork + 双分支策略

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


# 1. fork 到自己仓库
git clone https://github.com/liangweidonggood/jeecg-boot
cd jeecg-boot

# 2. 本地 dev 分支开发
git checkout -b dev
git pull

# 3. master 永远跟开源保持一致
git checkout master

# 4. 设置 upstream 开源仓库
git remote add upstream https://github.com/jeecgboot/jeecg-boot
git fetch upstream master
git merge upstream/master # 合并开源更新到本地 master

# 5. 切回 dev，rebase 同步
git checkout dev
git rebase master

核心原则：master 永远不污染，dev 上做二次开发。需要拉取开源更新时，先 rebase master 再开发。

5.2 RuoYi-Cloud-Plus：四层仓库模型

Dromara 系标准的二开流程：

1

原始开源项目（gitee/github）→ fork 开源仓库 → 私有仓库 → fork 私有仓库

仓库	职责
原始开源项目	原作者维护，只读
fork 开源仓库	合并上游更新，向原始提 PR
私有仓库	内部 fork 镜像，只从 fork 原始拉取
fork 私有仓库	日常开发提交，PR 回 fork 原始

优势：

多个二次开发团队可以并行工作
内部分支保护严格（protected branch）
提交链路清晰（私有 → 原始 fork → 原始开源）

5.3 yudao-cloud：商业文档 + 单仓库模式

yudao-cloud 走的是"商业文档 + 单仓库"模式：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 1. 文档订阅
访问 https://cloud.iocoder.cn/ 购买 199/年 文档

# 2. 仓库 clone
git clone https://gitee.com/zhijiantianya/yudao-cloud
git clone https://gitee.com/yudaocode/yudao-ui-admin-vue3
git clone https://gitee.com/yudaocode/yudao-ui-admin-uniapp
git clone https://gitee.com/yudaocode/yudao-mall-uniapp

# 3. 直接修改
# 没有 fork 规范要求，因为社区维护

核心思想：“文档即产品”——199/年的费用覆盖了详细教程 + 视频 + 答疑群，代码本身免费。

六、选型决策树

graph TD
 A[需要搭建后台系统] --> B{业务类型?}
 B -->|OA/ERP/CRM 表单为主| C{需要零代码?}
 B -->|通用 CRUD + 多租户| D[选 RuoYi-Cloud-Plus]
 B -->|电商/营销/会员| E[选 yudao-cloud]

 C -->|是| F[选 jeecg-boot]
 C -->|否| D

 F --> G{需要工作流?}
 G -->|是| F
 G -->|否| H{团队是否熟悉 Ant Design?}
 H -->|是| F
 H -->|否| D

 D --> I{需要多租户?}
 I -->|是| D
 I -->|否| J{团队是否在 RuoYi 生态?}
 J -->|是| D
 J -->|否| K{是否愿意买文档?}
 K -->|是| E
 K -->|否| D

七、实战对比表（2017-2024 七年使用感受）

维度	jeecg-boot	RuoYi-Cloud-Plus	yudao-cloud
学习曲线	中等（Ant Design + 定制组件）	低（Element Plus）	中等（Vben 复杂）
文档质量	一般（早期好，后期跟版本滞后）	优秀（Dromara 维护）	优秀（付费）
社区活跃度	中（QQ 群 + 论坛）	高（Gitee + GitHub + 社区）	高（付费群）
代码质量	中（早期屎山）	高	高
升级难度	高（破坏性升级多）	中	中
二次开发成本	中	低	低
企业级特性	高（工作流 + 报表）	中	高（商城）
适合团队规模	5-30 人	3-15 人	3-10 人

八、迁移成本对比

8.1 jeecg-boot → RuoYi

数据库：表结构差异大，需要重建（jeecg 用 sys_* 前缀，RuoYi 用 sys_* 但字段不同）
代码：组件层重写（Ant Design Vue → Element Plus）
权限：重新设计（Shiro → Sa-Token）
工时：2-3 人月

8.2 RuoYi → yudao

数据库：表结构相似度高（都基于 MyBatis-Plus）
代码：业务模块重写（yudao 业务逻辑更复杂）
权限：基本一致（都用 Sa-Token）
工时：1-2 人月

8.3 跨生态

jeecg ↔ yudao：成本极高（4-6 人月）
jeecg ↔ RuoYi：成本高（3-4 人月）

九、写在最后（2024 视角回望 2017）

关键提醒：本文 2024 年 9 月时点写就，三巨头定位和技术栈与未来可能有差异。选型时要根据当下时点的最新版本做技术调研，不要照搬 2024 年的判断。

2024 年的今天，国内 SaaS 后台脚手架赛道已经基本尘埃落定。三巨头的差异化竞争是好事——

jeecg-boot 在"低代码 + 政府项目"上保持优势
RuoYi-Cloud-Plus 在"中小企业 SaaS"上占据主流
yudao-cloud 在"电商 + 营销"上有完整解决方案

2017→2024 这 7 年里，三巨头的关键变化：

jeecg-boot 经历过"商业版收费风波 → 重归开源"，3.4.2（2022-09）后稳态
RuoYi 从单体版到 RuoYi-Cloud 再到 RuoYi-Cloud-Plus（2022），Dromara 组织化运营让生态更稳
yudao-cloud 走通"文档收费 199/年 + 代码免费"模式，被模仿者众多

个人建议：

新项目起步：先用 RuoYi-Cloud-Plus（社区活跃 + 文档好 + 升级平滑）

政府/国企项目：选 jeecg-boot（工作流 + 表单设计器）

电商/营销系统：选 yudao-cloud（买文档省时间）

参考资料

0.4 批次《开源生态观察》一文已盘点过国内开源生态全景
jeecg-boot 3.4.2（2022-09-22 发布）的更新日志
RuoYi-Cloud-Plus 官方文档 https://plus-doc.dromara.org/
yudao-cloud 商业文档 https://cloud.iocoder.cn/

国内开源 Java 脚手架生态全景：Dromara 组织与低代码平台横评

Sun, 15 Sep 2024 00:00:00 +0800

2024 年的今天，国内 Java 生态的"脚手架"赛道已经从单点竞争演化为"组织化运营"——Dromara 组织 200+ 仓库、jeecg 团队 30+ 项目、个人作者（芋道/青苗/小傅哥）百花齐放。对于一个想快速搭建后台系统的团队，从 22 款主流脚手架中选型是必经之路。

本文写于 2024 年 9 月——Dromara 组织成立 6 年，已成为国内 Java 生态最具影响力的非营利组织。

一、Dromara 组织概览

Dromara 是由国内 Java 开发者共同创建的非营利开源组织，目标是"让每一个 Java 工程师都能用上优秀的脚手架"。截至 2024-09：

仓库数：200+ 个
核心项目：50+ 个
代表作品：RuoYi-Vue-Plus、Sa-Token、Hutool、Forest、TLog、Cube、Raincat、Sureness…

二、22 款主流脚手架全景

2.1 脚手架横向对比

名称	地址	描述
jeecg-boot	github.com/jeecgboot/jeecg-boot	低代码后台
jeecgboot-vue3	github.com/jeecgboot/jeecgboot-vue3	jeecg-boot Vue 3 前端
jeecg-uniapp	github.com/jeecgboot/jeecg-uniapp	jeecg-boot 移动端
jeesite	github.com/thinkgem/jeesite	老牌 Java 脚手架
tianti	github.com/xujeff/tianti	CMS 解决方案
e	github.com/fuhoujun/e	微服务脚手架
jeesite (JeeSite)	github.com/thinkgem/jeesite	Java 脚手架
PublicCMS	github.com/sanluan/PublicCMS	CMS 管理
pig	github.com/pig-mesh/pig	微服务脚手架
Heeexy/SpringBoot-Shiro-Vue	github.com/Heeexy/SpringBoot-Shiro-Vue	简单权限
Springboot_v2	github.com/fuce1314/Springboot_v2	小架子
COLA	github.com/alibaba/COLA	阿里分层架构
SpringBlade	github.com/chillzhuang/SpringBlade	微服务脚手架
Saber	gitee.com/smallc/Saber	SpringBlade 前端
eladmin	github.com/elunez/eladmin	后台管理
eladmin-web	github.com/elunez/eladmin-web	eladmin 前端
dokit	github.com/perye/dokit	工具型脚手架
lamp-cloud	github.com/zuihou/lamp-cloud	微服务
SpringCloud	github.com/zhoutaoo/SpringCloud	微服务
Groza	github.com/IoT-Technology/Groza	物联网平台
thingsboard	github.com/thingsboard/thingsboard	物联网平台
Spring-Cloud-Platform	github.com/wxiaoqi/Spring-Cloud-Platform	微服务

2.2 分类总结

类别	代表项目
低代码	jeecg-boot
微服务	pig、SpringBlade、lamp-cloud、e、Spring-Cloud-Platform、zhoutaoo/SpringCloud
后台管理	eladmin、Heeexy/SpringBoot-Shiro-Vue、Springboot_v2
架构规范	alibaba/COLA（分层架构）
工具/集成	perye/dokit、dromara 各项目
CMS	tianti、PublicCMS、jeesite
物联网	Groza、thingsboard

三、四大明星项目深度对比

3.1 jeecg-boot：低代码之王

核心特性：

在线表单设计器（拖拽生成）
代码生成器（数据库表 → 前后端代码）
工作流引擎（Activiti/Camunda）
报表引擎（积木报表 + JimuReport）
大屏设计（拖拽式大屏）

技术栈：

后端：Spring Boot 2.6.6 + MyBatis-Plus + Shiro + JWT
前端：Vue 3 + Ant Design Vue
移动端：UniApp

适用场景：

政府/国企 OA/ERP
业务表单多、流程长的内部系统
团队希望"零代码"完成交付

3.2 pig：微服务 + 业务组件

核心特性：

Spring Cloud Alibaba 全家桶
完善的多租户 + 权限体系
代码生成器（支持自定义模板）
avue 组件（国内首个面向后台的 Vue UI 库）
pigx（企业版）支持工作流 + 报表

技术栈：

后端：Spring Boot 2.7 + Spring Cloud Alibaba + MyBatis-Plus + Nacos
前端：Vue 2 + avue + Element UI
业务组件：30+（含 CMS、商城、CRM）

适用场景：

中小企业 SaaS 产品
微服务架构的内部系统
需要"业务组件即装即用"

3.3 SpringBlade：微服务 + 多端

核心特性：

Spring Cloud 全家桶（Netflix + Alibaba）
前后端分离 + 多端（Web / App / 小程序）
Sword（Saber）前端框架
完善的多租户 + 流程管理

技术栈：

后端：Spring Boot 2.x + Spring Cloud + MyBatis-Plus + Nacos + Sentinel
前端（Web）：Vue 2 + Element UI
前端（App）：UniApp
网关：Spring Cloud Gateway

适用场景：

中大型企业级系统
需要 Web + App + 小程序多端
团队希望"一次开发多端运行"

3.4 lamp-cloud：微服务 + 集大成

核心特性：

基于 Spring Cloud Alibaba 完整微服务
lamp-util 工具集（30+ 工具模块）
完善的多租户 + 数据权限
代码生成器（增强版）
工作流（Flowable）

技术栈：

后端：Spring Boot + Spring Cloud Alibaba + Nacos + Sentinel + Seata
前端：Vue 3 + Vben Admin + TypeScript
数据库：MyBatis-Plus + Druid + ShardingSphere

适用场景：

中大型企业级系统
需要完整微服务治理
团队希望"开箱即用"的全套组件

四、技术栈对比

维度	jeecg-boot	pig	SpringBlade	lamp-cloud
前端	Ant Design Vue	avue + Element UI	Element UI	Vben + TypeScript
后端	Spring Boot 2.6	Spring Boot 2.7	Spring Boot 2.x	Spring Boot 2.x
注册中心	Nacos	Nacos	Nacos	Nacos
权限	Shiro + JWT	Spring Security	Spring Security	自研
代码生成	强	中	中	强
工作流	强	中	中	中
移动端	UniApp	独立 App	UniApp	独立
多租户	弱	强	中	强
代码质量	中	中	中	高
学习曲线	中等	中等	高	高

五、Dromara 组织明星项目盘点

5.1 工具类

名称	描述	地位
Hutool	Java 工具集（代替 Guava）	国内最流行
Sa-Token	轻量级权限认证	低代码 + 简单
Forest	Java HTTP 客户端（声明式调用）	替代 OkHttp
TLog	分布式日志链路追踪	轻量替代 SkyWalking
Fast Request	IDEA 插件（API 调试）	Restful 替代 Postman
Sureness	权限认证	替代 Spring Security
JPom	自动化部署	替代 Jenkins

5.2 中间件类

名称	描述
Raincat	分布式事务（强一致 TCC）
Hmily	分布式事务（TCC + AT）
Myth	分布式事务（基于 MQ）
Cube	一站式 API 网关
Gobrs-Async	异步编排框架

5.3 数据类

名称	描述
DynamicTp	动态线程池
Neko	数据库访问（轻量 ORM）

5.4 测试类

名称	描述
Phoenix	自动化测试平台
Happy-Java	Java 进阶之路
Dante Cloud	企业级微服务（Spring Authorization Server）

六、项目例子

6.1 行业模板

名称	地址	描述
IndoorPos	github.com/megagao/IndoorPos	室内定位
shardingsphere-example	github.com/apache/shardingsphere-example	数据库分片
jtt1078-video-server	github.com/glaciall/jtt1078-video-server	视频转播服务器
jt809-tcp-server	github.com/ch0ice/jt809-tcp-server	jt809 协议
jt808-netty	github.com/zpsw/jt808-netty	车载定位
jt808-tcp-netty	github.com/rjli/jt808-tcp-netty	车载定位
jt808-server	github.com/yezhihao/jt808-server	车载定位
JT808	github.com/SmallChi/JT808	车载定位
jt-808-protocol	github.com/hylexus/jt-808-protocol	车载定位
jt-framework	github.com/hylexus/jt-framework	车载定位
mybatis-plus-samples	github.com/baomidou/mybatis-plus-samples	MyBatisPlus 例子
cjs-oauth2-sso-demo	github.com/chengjiansheng/cjs-oauth2-sso-demo	单点登录
spring-boot-security-oauth2-jwt	github.com/anthonyfoulfoin/spring-boot-security-oauth2-jwt	Spring Security
Auth-service	github.com/keets2012/Auth-service	授权服务
Mybatis-PageHelper	github.com/pagehelper/Mybatis-PageHelper	分页
spring-cloud-examples	github.com/ityouknow/spring-cloud-examples	Spring Cloud
simplemall	github.com/maventalker/simplemall	Spring Cloud
paascloud-master	github.com/paascloud/paascloud-master	Spring Cloud
spring-cloud-microservice-examples	github.com/zpng/spring-cloud-microservice-examples	Spring Cloud

6.2 协议类（车载/物联网）

重点关注：国内 JT/T 808 协议（交通部车载终端通讯协议）和 JT/T 1078 协议（车载视频传输协议）是车联网行业的核心协议。

七、学习路线

7.1 入门

名称	地址	描述
wuyouzhuguli/SpringAll	github.com/wuyouzhuguli/SpringAll	Spring 全家桶学习
websocketWithNetty	github.com/Siwash/websocketWithNetty	Netty + WebSocket
m3u8Download	github.com/qq494257084/m3u8Download	m3u8 视频下载
Netty-study	github.com/xuwujing/Netty-study	Netty
netty-4-user-guide-demos	github.com/waylau/netty-4-user-guide-demos	Netty 实战
essential-netty-in-action	github.com/waylau/essential-netty-in-action	Netty 实战
netty-learning-example	github.com/sanshengshui/netty-learning-example	Netty
CookBook	github.com/Byron4j/CookBook	综合资料
toBeTopJavaer	github.com/hollischuang/toBeTopJavaer	Java 成神之路
advanced-java	github.com/doocs/advanced-java	互联网 Java 进阶
java-design-patterns	github.com/iluwatar/java-design-patterns	设计模式
JavaGuide	github.com/Snailclimb/JavaGuide	Java 学习+面试
CS-Notes	github.com/CyC2018/CS-Notes	综合资料
Spring-Boot-In-Action	github.com/hansonwang99/Spring-Boot-In-Action	Spring Boot 实战
SpringBootLearning	github.com/gf-huanchupk/SpringBootLearning	Spring Boot
spring-boot-examples	github.com/ityouknow/spring-boot-examples	Spring Boot
springboot-learning-example	github.com/JeffLi1993/springboot-learning-example	Spring Boot
springBoot	github.com/527515025/springBoot	Spring Boot
spring-boot-student	github.com/wyh-spring-ecosystem-student/spring-boot-student	Spring Boot
DesignPattern	github.com/youlookwhat/DesignPattern	设计模式
SpringCloud-Learning	github.com/dyc87112/SpringCloud-Learning	Spring Cloud
SpringCloudLearning	github.com/forezp/SpringCloudLearning	Spring Cloud

八、框架

名称	描述
quartz	作业调度框架
spring-framework	Spring 框架
spring-boot	Spring Boot
spring-cloud-alibaba	Spring Cloud Alibaba
mybatis-spring-boot-starter	MyBatis Spring Boot
influxdb-java	InfluxDB 客户端
grpc-spring-boot-starter	gRPC Spring Boot
zxing	二维码处理
netty	Netty
moqui-framework	企业应用框架
auth0/java-jwt	JWT
jwtk/jjwt	JWT

九、工具

名称	描述
skylot/jadx	反编译
aliyun/aliyun-openapi-java-sdk	阿里云 SDK
alibaba/easyexcel	Excel 解析
alibaba/arthas	Java 诊断工具
apache/shardingsphere	分库分表
zouzg/mybatis-generator-gui	代码生成器 GUI
liyiorg/weixin-popular	微信公众号 SDK
Javen205/IJPay	支付 SDK

十、选型决策树

graph TD
 A[需要搭建后台] --> B{业务复杂度?}
 B -->|低/中等| C{需要低代码?}
 B -->|高/复杂| D[微服务脚手架]

 C -->|是| E[jeecg-boot]
 C -->|否| F{需要微服务?}
 F -->|否| G[eladmin / pig 单体版]
 F -->|是| D

 D --> H{组织规模?}
 H -->|10-50人| I[pig / SpringBlade]
 H -->|50-200人| J[lamp-cloud / Dante Cloud]
 H -->|200+| K[自研 + Dromara 工具集]

十一、写在最后

国内 Java 脚手架生态已经非常成熟——对于 80% 的中小企业业务，不需要从零搭建。关键是选对一款 + 二次开发 + 持续升级。

个人建议：

新项目起步：eladmin（学习成本低）/ pig（微服务 + 业务组件）

政府/国企：jeecg-boot（工作流 + 表单设计）

企业级 SaaS：lamp-cloud（完整微服务 + 工具集）

多端开发：SpringBlade（Web + App + 小程序）

工具类需求：先看 Hutool / Sa-Token / Forest 等 Dromara 工具

十二、2024+ 视角：JDK 21/22、Spring Boot 3 与 Dromara 新生态

本文写于 2024 年 9 月，下面的"2024+ 视角"补全到 2025-2026 的最新状态——JDK 21 LTS、Spring Boot 3.x、Dromara 组织升级、sa-token 1.40+ 等关键变化。

12.1 JDK 21 LTS 改变了脚手架技术栈的"地板"

2024 年 9 月 JDK 21 是 LTS（Next LTS），对国内 Java 脚手架生态影响最直接的是：

Virtual Thread（虚拟线程）——pig、lamp-cloud 这类微服务脚手架的网关层，从 Netty 切换到原生虚拟线程，QPS 提升 30%-50% 在 2025 年成为现实
Generational ZGC 成为默认 GC 选项——eladmin 这类后台管理在 4C8G 机器上的 GC pause 从 50ms 降到 <5ms
Pattern Matching for switch / Record Patterns——RuoYi-Vue-Plus 等脚手架的 DTO 转换代码减少 40%
spring-boot-3.2+ 才完整支持 JDK 21，2024 下半年是"Spring Boot 2.7 + JDK 8" 老项目迁移的关键窗口期

到 2025 年下半年，Dromara 官方仓库里已经默认要求 JDK 17+，完全抛弃 JDK 8 是这 12 个月内发生的。

12.2 Dromara 组织 2024-2025 关键变化

Sa-Token：从 1.44 升级到 1.40+ → 1.42+ → 1.44+（v1.44.0 加入了 OAuth2.0 / OIDC 完整支持），国内 Java 权限认证的事实标准地位进一步稳固
Hutool 5.8.x：发布 5.8.27+ 版本，Crypto 模块支持国产 SM2/SM3/SM4 算法——等保 2.0 三级合规场景刚需
Forest 1.5.x：声明式 HTTP 客户端，集成 Spring Boot 3.x 与虚拟线程，在国内金融、政企项目的"自研 RPC 替代品"角色越来越重
DynamicTp 1.1.x：动态线程池，集成 Prometheus + Grafana 模板，“线程池可观测"成了面试标配
Cube / Gobrs-Async：从"小众实验"走向"中等规模服务编排首选”——主要是 Dromara 官方文档在 2024 年大改版
Dante Cloud：升级到 Spring Authorization Server 全家桶（替代 Shiro），成为 Dromara 体系里对接 OAuth2.1 / OIDC 最完整的脚手架

结论：Dromara 在 2024-2025 年的本质变化是**“工具集 → 一站式企业套件”**——pig + Hutool + Sa-Token + Forest + DynamicTp 这套组合在国内 90% 的中小项目里可以"开箱即用"。

12.3 Spring Boot 3.x 迁移：脚手架的"分水岭"

2024 年下半年到 2025 年，国内脚手架的"分水岭"是 Spring Boot 3.x 迁移：

脚手架	Spring Boot 3.x 支持	状态（2025）
jeecg-boot	3.7+ / 4.0（Vue3 + Ant Design Vue4）	官方主推
pig	4.x 全系列	稳定
lamp-cloud	5.x Vben 5	稳定
eladmin	2.7+ 社区版	用户最多
SpringBlade	升级慢，部分团队 fork 自维护	关注度下降
COLA	4.0（COLA 5 架构 + Archetype）	阿里内部仍在用

踩坑点（2024-2025 真实经验）：

javax → jakarta 命名空间——所有自定义 starter 必须重写包名，老 starter 一夜失效
Spring Security 6 lambda DSL——http.authorizeRequests() 废弃，必须用 http.authorizeHttpRequests()
MyBatis-Plus 3.5.7+ 才完整支持 Spring Boot 3.x，老版本 3.5.3.x 报 ClassNotFoundException
Nacos 2.3+ 才完整支持 Spring Boot 3.x 配置注册中心

12.4 选型补充：2025 年的"快速判断表"

业务场景	2024 推荐	2025 调整
快速交付后台	jeecg-boot	jeecg-boot 4.0（Vue3） / eladmin 2.7+
微服务起步	pig	pig 4.x（已迁 Spring Boot 3）
企业级 SaaS	lamp-cloud	lamp-cloud 5.x（Vben 5 + Spring Authorization Server）
多端开发	SpringBlade	关注度下降，可考虑 pig uniapp 版
AI 时代内部工具	通用脚手架	FastGPT / Dify / n8n 这类 LLM 工作流平台——传统后台管理正在被 AI 工作流平台挤压

12.5 个人随笔：脚手架的"尽头"是平台化

从 2024 写到 2026，回看本文的判断基本对——脚手架赛道的尽头不是"更好的脚手架"，而是"AI 时代的工作流平台"：

传统脚手架（jeecg-boot、pig、lamp-cloud）：做"表单 + 流程 + 报表"——这些在 2025 年还有市场，但增速放缓
AI 工作流平台（Dify、FastGPT、Coze）：做"自然语言 + 工具调用 + 知识库"——这是 2025-2026 的新增长极
融合形态：jeecg-boot 在 4.0 版本加入了 AI 助手（基于本地 LLM），pig 4.x 内置 Flowable + AI 节点——老牌脚手架正在加 AI 能力应对冲击

5 年前选脚手架 = 选 Vue 模板 + Spring Boot 框架；2 年后选脚手架 = 选 AI 集成 + 工作流引擎 + 权限体系。这是 2024 看不到但 2026 已经清晰的方向。

参考资料

跨语言开源生态：Go / Python / 前端学习路径与工具选型

Thu, 15 Dec 2022 00:00:00 +0800

2022 年的今天，“全栈"已经是一个 5+ 年经验的 Java 工程师的必修课——Go 做云原生、Python 做 AI/脚本、前端做 UI。本文盘点 Go / Python / 前端三大生态的开源项目（200+ 仓库），并给出实战学习路径与选型建议。

本文写于 2022 年 12 月——ChatGPT 已经发布 1 年、Go 1.19 刚发布、Vue 3 稳定半年。

一、Go 语言生态（67+ 仓库）

1.1 脚手架

名称	地址	描述
ixre/go2o	github.com/ixre/go2o	Go 商铺管理 O2O
iotfast	github.com/xiaodingding/iotfast	IoT 物联网开发
hotgo	github.com/bufanyun/hotgo	基于 Vue 和 GoFrame
gin-admin	github.com/LyricTian/gin-admin	权限管理
gfast	github.com/tiger1103/gfast	基于 Vue 和 GoFrame
gin-vue-admin	github.com/flipped-aurora/gin-vue-admin	脚手架
go-admin	github.com/go-admin-team/go-admin	go-admin 后端
go-admin-ui	github.com/go-admin-team/go-admin-ui	go-admin 前端

1.2 项目例子

名称	地址	描述
ocrservice	github.com/onestraw/ocrservice	OCR 服务例子
share	github.com/wangming1993/share	Go + gRPC + Consul
go-micro-build	github.com/guaosi/go-micro-build	微服务
WEHousing	github.com/MineCoinChain/WEHousing	微服务
MTBSystem	github.com/wiatingpub/MTBSystem	微服务

1.3 学习

类别	仓库	说明
Dubbo	github.com/apache/dubbo-go-samples	例子
算法	github.com/emirpasic/gods	数据结构
算法	github.com/geekxh/hello-algorithm	算法图解
力扣	github.com/halfrost/LeetCode-Go	力扣 Go 版
教程	github.com/hantmac/Mastering_Go_ZH_CN	mastering go
入门	github.com/GoesToEleven/GolangTraining	入门教程
爬虫	github.com/chromedp/examples	chromedp
爬虫	github.com/thehappymouse/ccmouse	ccmouse
微服务	github.com/xiaopenggithub/zindle	go-zero 学习
微服务	github.com/zeromicro/zero-examples	go-zero
微服务	github.com/zeromicro/zero-doc	go-zero 文档
标准库	github.com/polaris1119/The-Golang-Standard-Library-by-Example	标准库
高级	github.com/chai2010/advanced-go-programming-book	高级编程
入门	github.com/unknwon/the-way-to-go_ZH_CN	入门指南
实战	github.com/astaxie/build-web-application-with-golang	beego 作者

1.4 框架

名称	描述
golang/go	官方仓库
gogf/gf	goframe 框架
go-grpc-middleware	gRPC 中间件
shirou/gopsutil	系统硬件信息
golang/protobuf	Protobuf
protoc-gen-validate	protoc 插件
go-vgo/robotgoro	自动化
shopspring/decimal	大数
robinson/gos7	西门子 PLC
konimarti/opc	OPC DA
go-resty/resty	HTTP 客户端
gomodule/redigo	Redis 客户端
urfave/cli	命令行
spf13/cobra	命令行程序
dtm-labs/dtm	分布式事务
pkg/errors	错误处理
apache/dubbo-go	Dubbo Go
douyu/jupiter	斗鱼微服务
skip2/go-qrcode	二维码
panjf2000/ants	协程池
etcd-io/etcd	服务发现
hashicorp/consul	服务发现
zeromicro/go-zero	微服务
kataras/iris	Web 框架
istio/istio	Service Mesh
asim/go-micro	微服务
aceld/zinx	并发服务器框架
GoAdminGroup/go-admin	Web 框架
gin-gonic/gin	最流行 HTTP 框架
go-netty/go-netty	Netty Go 版
andeya/erpc	erpc
tinygo-org/tinygo	单片机
liangdas/mqant	游戏服务器框架
name5566/leaf	游戏服务器框架
3zheng/railgun	游戏服务器框架
davyxu/cellnet	游戏服务器框架

1.5 库

名称	描述
robfig/cron	定时任务
chromedp/chromedp	爬虫
golang/net	网络
PuerkitoBio/goquery	jQuery 式 HTML 解析
gocolly/colly	爬虫库
zhshch2002/gospider	爬虫
anaskhan96/soup	爬虫
go-gota/gota	数据处理
gonum/gonum	数值计算
op/go-logging	日志
uber-go/zap	结构化日志
sirupsen/logrus	日志
cihub/seelog	日志
go-sql-driver/mysql	MySQL 驱动
go-redis/redis	Redis 客户端
gorilla/websocket	WebSocket
eclipse/paho.mqtt.golang	MQTT
funny/link	TCP 服务
panjf2000/gnet	高性能网络库

1.6 工具

名称	描述
go-package-plantuml	自动生成 UML 类图
jfeliu007/goplantuml	生成类图
distribution/distribution	Docker 镜像仓库
josephspurrier/goversioninfo	打包版本信息
akavel/rsrc	打包资源
schollz/croc	跨网络文件传输
voidint/g	g：Go 多版本管理
flike/kingshard	MySQL 代理
kevwan/go-stash	日志采集
andeya/pholcus	爬虫
mattn/go-sqlite3	SQLite
adnanh/webhook	Webhook
docker/compose	Docker Compose
influxdata/influxdb	时序数据库
pyroscope-io/pyroscope	性能分析
casbin/casbin	权限认证
monkeyWie/gopeed-core	下载工具
davyxu/tabtoy	导表工具
Done-0/fuck-u-code	代码质量检查

1.7 Go 学习路径推荐

graph LR
 A[入门] --> B[基础语法]
 B --> C[Go Module]
 C --> D[协程+Channel]
 D --> E[Web 框架 Gin]
 E --> F[数据库 sqlx/gorm]
 F --> G[微服务 go-zero/istio]
 G --> H[云原生 k8s Operator]

推荐时长：3-6 个月从入门到能上手生产项目。

二、Python 生态（精简）

2.1 框架

名称	地址	描述
kivy	github.com/kivy/kivy	多点触控（移动端 + 桌面）

2.2 Python 工具

注：原 opensource/python.md 工具章节为空，本节为补全。

类别	推荐	描述
Web 框架	Django	全功能 ORM + Admin + 模板
Web 框架	FastAPI	高性能 + 类型注解 + 自动 OpenAPI
Web 框架	Flask	轻量级，适合 API
ORM	SQLAlchemy	工业级 ORM
异步	asyncio + aiohttp	异步 IO
爬虫	Scrapy	工业级爬虫
爬虫	requests + BeautifulSoup	简单爬虫
AI	PyTorch	深度学习
AI	TensorFlow	深度学习
AI	scikit-learn	传统机器学习
数据	Pandas	数据分析
数据	NumPy	数值计算
部署	uvicorn/gunicorn	ASGI/WSGI 服务器
任务	Celery	分布式任务队列
任务	APScheduler	定时任务

2.3 Python 学习路径

graph LR
 A[入门] --> B[基础语法 + 虚拟环境]
 B --> C[常用库 requests/numpy]
 C --> D[Web Flask/Django]
 D --> E[异步 asyncio]
 E --> F[AI PyTorch / 数据分析 Pandas]

三、前端生态（30+ 仓库）

3.1 库

原 opensource/frontend.md 库章节为占位空表

3.2 组件

名称	地址	描述
DataV	github.com/DataV-Team/DataV	前端大屏

3.3 Vue 生态

名称	描述
sass/node-sass	SASS
pagekit/vue-resource	HTTP 客户端
PanJiaChen/vue-admin-template	Vue 模板
logaretm/vee-validate	表单验证
lin-xin/vue-manage-system	后台管理
PanJiaChen/vue-element-admin	最流行后台模板
bailicangdu/vue2-elm	饿了么 App
lzxb/vue-demo	Demo
ElemeFE/v-charts	基于 ECharts 的 Vue 图表
apache/echarts	最流行图表库
ecomfe/vue-echarts	ECharts 的 Vue 组件

3.4 大屏

名称	描述
yyhsong/iDataV	大屏例子
HongqingCao/GitDataV	大屏例子
ddiu8081/ChartFun	大屏例子
lizhensheng/vue-data-view	大屏例子
daoke0818/pro_bigScreenCharts	大屏例子
veaba/ncov	新冠疫情大屏

3.5 其它

名称	描述
varHarrie/varharrie.github.io	个人博客
ColorlibHQ/AdminLTE	后台模板
jquery-validation/jquery-validation	jQuery 验证
hiwanz/wgs2mars.js	坐标系转换（WGS-84 → 火星坐标）

3.6 小程序

名称	描述
EastWorld/wechat-app-mall	微信小程序商城
Tencent/wepy	小程序组件化框架
ecomfe/echarts-for-weixin	ECharts 微信版

四、跨语言项目举例（精华）

4.1 工业级 SaaS 案例

业务领域	Java 方案	Go 方案	Python 方案
后台管理	jeecg-boot	go-admin	Django Admin
电商	yudao-cloud	go-shop	Saleor
物联网	WVP-GB28181-pro	iotfast	Home Assistant
视频	WVP-GB28181-pro	livego	nginx-rtmp
大数据	-	dtm/fabric	Airflow
AI - NLU	-	-	spaCy + Transformers
AI - 视觉	-	-	YOLOv8 + OpenCV

4.2 性能对比（生产实测）

场景	Java (Spring Boot)	Go (Gin)	Python (FastAPI)
HTTP QPS (单核)	1.5-3 万	3-6 万	3000-5000
内存占用（启动）	200-500 MB	10-30 MB	50-100 MB
启动时间	5-15 s	< 100 ms	1-3 s
WebSocket 并发	5-10 万	20-50 万	1-3 万
机器学习	X (JVM)	X (CGO)	✓ (最佳)

五、跨语言学习路径推荐

5.1 Java 工程师学 Go（3 个月）

graph LR
 A[第 1 月] --> B[基础语法/Go Module]
 B --> C[第 2 月]
 C --> D[Gin Web + GORM]
 D --> E[第 3 月]
 E --> F[go-zero 微服务 + Docker]

5.2 Java 工程师学 Python（2 个月）

graph LR
 A[第 1 月] --> B[语法 + 虚拟环境 + pip]
 B --> C[第 2 月]
 C --> D[FastAPI + Pandas]

5.3 Java 工程师学 Vue 3（2 个月）

graph LR
 A[第 1 月] --> B[Vue 3 基础 + Vite]
 B --> C[第 2 月]
 C --> D[Element Plus + Pinia + Router]

六、写在最后

跨语言是 2020+ 工程师的必备技能——Java 写后端、Go 写云原生、Python 写 AI/脚本、前端写 UI。但要警惕"贪多嚼不烂”——

个人建议：

Java 工程师：Go 是必学（云原生趋势）+ Python 选学（AI 趋势）

学 Go 切入点：用 gfast / go-zero 跑通一个微服务 demo

学 Python 切入点：用 FastAPI 写一个内部工具 API

学前端切入点：用 Vue 3 + Element Plus 写一个后台模板

参考资料

sa-token SSO 单点登录三种模式完整实战

Wed, 15 Dec 2021 00:00:00 +0800

sa-token 是国内 Dromara 组织下的轻量级 Java 权限认证框架，2021 年 GitHub star 数超过 8k。sa-token 的 SSO 模块是国内最简洁的 Java 单点登录方案之一——它把 SSO 抽象成三种"客户端-服务端"模式，让不同业务场景都能找到合适方案。本文基于 sa-token 1.44.0 版本做一次完整实战。

本文写于 2021 年 12 月——sa-token SSO 模块稳定迭代后的版本。

一、SSO 接口规范

sa-token 定义了一套标准的 SSO RESTful 接口规范，所有模式都遵循这套接口：

1.1 服务端（SSO-Server）接口

端	接口	解释
server	`/sso/auth`	单点登录授权（重定向到登录页）
server	`/sso/doLogin`	restapi 登录接口（自定义 `doLoginHandle`）
server	`/sso/signout`	单点登录注销
server	`/sso/pusS`	消息推送（模式三服务端推送）
server	`/sso/userinfo`	获取用户信息（自定义）

1.2 客户端（SSO-Client）接口

端	接口	解释
client	`/sso/login`	客户端登录地址（重定向到 server）
client	`/sso/logout`	客户端注销
client	`/sso/logoutCall`	单点注销回调
client	`/sso/pusC`	消息推送（模式三客户端接收）
client	`/sso/myInfo`	客户端查询用户信息

特点：

所有接口都是基于 HTTP 的 RESTful
通过 redirect 参数传递回调地址
模式三需要主动 HTTP 推送（基于 Forest HTTP 工具）

二、SSO 模式一：前端同域 + 后端同 Redis

2.1 原理

共享 Cookie 来做到前端 Token 的共享，从而达到后端的 Session 会话共享：

1
2
3
4
5


App1（a.example.com） ──┐
 │ 同域 stp.com 共享 Cookie
App2（a.example.com） ──┤
 │ 同 Redis 共享 Session
App3（a.example.com） ──┘

架构：

所有应用挂在同一个域下（如 stp.com）
登录后 Cookie 写入 stp.com 域
后续访问任何应用都自动带上 Cookie
Session 存储在同一个 Redis

2.2 优点

最简单：零额外开发
最稳定：基于 Cookie + Redis 标准方案
最高性能：无重定向，无额外 HTTP 请求

2.3 缺点

必须同域：所有应用必须挂在同一个父域下
不能跨域：如果是不同根域的多个产品线，不能用此模式

2.4 适用场景

同公司多个子系统（如 crm.stp.com、erp.stp.com、oa.stp.com）
微服务架构内部系统

三、SSO 模式二：前端不同域 + 后端同 Redis

3.1 原理

采用 URL 重定向，以 ticket 码为授权中介，做到多个系统间的会话传播：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


App1（a.com） App2（b.com）
 │ │
 │ ① /sso/auth?redirect= │
 ▼ │
SSO-Server（sso.com） │
 │ │
 │ ② 重定向到 /sso/login │
 ▼ │
登录页（sso.com） │
 │ │
 │ ③ 提交账密 │
 ▼ │
SSO-Server │
 │ │
 │ ④ 颁发 ticket + 重定向 │
 │ /sso/login?ticket=xxx│
 ▼ │
 ┌─────────────────────────▶│
 │ ▼
 │ App2 回调 /sso/login?ticket
 │ │
 │ ▼
 │ 携带 ticket 调用 SSO-Server /sso/authTicket
 │ │
 │ ▼
 │ SSO-Server 校验 ticket
 │ │
 │ ▼
 │ 返回 App2 的 token，写入 App2 的 Session

关键流程：

用户访问 App1（a.com）
App1 发现自己未登录，重定向到 SSO-Server /sso/auth?redirect=...
SSO-Server 发现自己未登录，返回登录页
用户登录成功，SSO-Server 生成 ticket 写入 Redis
SSO-Server 重定向回 App1 redirect 地址，带上 ticket
App1 拿到 ticket，调用 SSO-Server /sso/authTicket 换 App1 的 token
App1 把 token 写入自己的 Session
用户访问 App2（b.com），重复同样流程，但 SSO-Server 已经认识这个用户，自动颁发 ticket（无需再登录）

3.2 优点

支持跨域：不同根域的应用可以登录
基于 ticket：标准 OAuth 2.0 风格
无状态：ticket 一次有效，换完即失效

3.3 缺点

有重定向：首次访问慢一点
配置复杂：需要给每个应用配置 client 名称 + 回调地址

3.4 适用场景

不同子公司的多个产品（如 aliyun.com、dingtalk.com、alipay.com）
企业 SaaS 多租户

四、SSO 模式三：前端不同域 + 后端不同 Redis

4.1 原理

采用 Http 请求主动查询会话，做到 Client 端与 Server 端的会话同步：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


App1（a.com） App2（b.com）
 │ │
 │ │ ① /sso/login?redirect=...
 │ ▼
 │ SSO-Server（sso.com）
 │ │
 │ │ ② ticket=xxx
 │ ▼
 │ App2 调用 /sso/authTicket 换 token
 │ │
 │ ▼
 │ SSO-Server 主动 HTTP 推送
 │ │ /sso/pusC
 │ ▼
 │ App1 也收到推送（同步登录状态）
 │
 │ ③ 收到推送，已登录
 ▼
 全员同步

关键流程：

App2 主动调用 SSO-Server 的 /sso/authTicket 验证 ticket
SSO-Server 验证通过后，主动通过 HTTP POST 推送消息到所有已注册的客户端
所有 App（包括 App1、App2、App3）都收到推送
所有 App 同步更新本地 Session

4.2 优点

真正的分布式：不需要共享 Session
实时同步：注销、踢人、状态变更实时通知
可扩展：App1/2/3/4 任意上下线不影响

4.3 缺点

需要 HTTP 推送：依赖 Forest HTTP 客户端
推送失败容错：推送失败时需要心跳轮询兜底

4.4 适用场景

跨数据中心部署（各应用在不同地域的 Redis）
超大规模 SSO（上百个应用）

五、服务端（SSO-Server）实战

5.1 依赖

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56


<!-- SpringBoot -->
<parent>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-parent</artifactId>
 <version>2.5.14</version>
</parent>

<properties>
 <sa-token.version>1.44.0</sa-token.version>
</properties>

<dependencies>
 <!-- SpringBoot Web -->
 <dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-web</artifactId>
 </dependency>

 <!-- Sa-Token 核心 -->
 <dependency>
 <groupId>cn.dev33</groupId>
 <artifactId>sa-token-spring-boot-starter</artifactId>
 <version>${sa-token.version}</version>
 </dependency>

 <!-- Sa-Token SSO 插件 -->
 <dependency>
 <groupId>cn.dev33</groupId>
 <artifactId>sa-token-sso</artifactId>
 <version>${sa-token.version}</version>
 </dependency>

 <!-- Sa-Token Redis 集成 -->
 <dependency>
 <groupId>cn.dev33</groupId>
 <artifactId>sa-token-redis-template</artifactId>
 <version>${sa-token.version}</version>
 </dependency>
 <dependency>
 <groupId>org.apache.commons</groupId>
 <artifactId>commons-pool2</artifactId>
 </dependency>

 <!-- Thymeleaf（前后端不分离模式） -->
 <dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-thymeleaf</artifactId>
 </dependency>

 <!-- Forest HTTP 客户端（模式三需要） -->
 <dependency>
 <groupId>cn.dev33</groupId>
 <artifactId>sa-token-forest</artifactId>
 <version>${sa-token.version}</version>
 </dependency>
</dependencies>

5.2 配置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63


server:
 port: 9000

# Sa-Token 配置
sa-token:
 is-log: true

 # SSO-Server 配置
 sso-server:
 # Ticket 有效期（单位：秒），默认 5 分钟
 ticket-timeout: 300
 # 主页路由：在 /sso/auth 登录页不指定 redirect 参数时，默认跳转的地址
 home-route: /home
 # 是否启用匿名 client（允许客户端接入时不提交 client 参数）
 allow-anon-client: true
 # 所有允许的授权回调地址（匿名 client 使用）
 allow-url: "*"
 # API 接口调用秘钥（全局默认 + 匿名 client 使用）
 secret-key: kQwIOrYvnXmSDkwEiFngrKidMcdrgKor
 # 应用列表：配置接入的应用信息
 clients:
 # 应用 sso-client1：采用模式一对接（同域、同 Redis）
 sso-client1:
 client: sso-client1
 allow-url: "*"
 # 应用 sso-client2：采用模式二对接（跨域、同 Redis）
 sso-client2:
 client: sso-client2
 allow-url: "*"
 secret-key: SSO-C2-kQwIOrYvnXmSDkwEiFngrKidMcdrgKor
 # 应用 sso-client3：采用模式三对接（跨域、跨 Redis）
 sso-client3:
 client: sso-client3
 allow-url: "*"
 is-push: true
 push-url: http://sa-sso-client1.com:9003/sso/pusC
 secret-key: SSO-C3-kQwIOrYvnXmSDkwEiFngrKidMcdrgKor
 # 应用 sso-client3-resdk：采用 ReSdk 模式对接
 sso-client3-resdk:
 client: sso-client3-resdk
 allow-url: "*"
 is-push: true
 push-url: http://sa-sso-client1.com:9005/sso/pusC
 secret-key: SSO-C3-ReSdk-kQwIOrYvnXmSDkwEiFngrKidMcdrgKor

# Redis 配置
spring:
 redis:
 database: 1
 host: 127.0.0.1
 port: 6379
 password:
 timeout: 10s
 lettuce:
 pool:
 max-active: 200
 max-wait: -1ms
 max-idle: 10
 min-idle: 0

# Forest HTTP 客户端
forest:
 log-enabled: false

5.3 hosts 配置

1
2


# 模拟多域名环境
127.0.0.1 sa-sso-server.com

5.4 测试入口

1

登录页：http://sa-sso-server.com:9000/sso/auth

六、客户端实战

6.1 标准模式客户端

同模式二客户端配置（sso-client2）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


server:
 port: 9002

sa-token:
 sso-client:
 # SSO-Server 域名
 server-url: http://sa-sso-server.com:9000
 # 本应用 Client 标识
 client: sso-client2
 # 本应用密钥（与 Server 端配置一致）
 secret-key: SSO-C2-kQwIOrYvnXmSDkwEiFngrKidMcdrgKor
 # 登录回调地址
 redirect-url: http://sa-sso-client2.com:9002/sso/login

6.2 ReSdk 模式客户端

ReSdk 是 sa-token 提供的一种不依赖 Spring MVC 拦截器的接入方式，适合老项目改造：

1
2
3
4


<dependency>
 <groupId>cn.dev33</groupId>
 <artifactId>sa-token-sso</artifactId>
</dependency>

优点：

业务代码侵入小（只需在 Controller 入口加 1-2 行）
支持非 Spring 项目
支持 GraalVM Native Image

6.3 NoSdk 模式客户端

完全不依赖 Sa-Token，纯 HTTP 调用 SSO 接口：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


<dependencies>
 <!-- SpringBoot Web -->
 <dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-web</artifactId>
 </dependency>

 <!-- Forest HTTP 客户端 -->
 <dependency>
 <groupId>com.dtflys.forest</groupId>
 <artifactId>forest-spring-boot-starter</artifactId>
 <version>1.5.26</version>
 </dependency>
</dependencies>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


server:
 port: 9004

forest:
 log-request: true

spring:
 redis:
 database: 2
 host: 127.0.0.1
 port: 6379
 timeout: 10s
 lettuce:
 pool:
 max-active: 200
 max-wait: -1ms
 max-idle: 10
 min-idle: 0

自定义接口：

接口	含义
`/`	client-首页
`/sso/login`	client-登录
`/sso/logout`	client-单点注销
`/sso/logoutCall`	client-单点注销回调
`/sso/myInfo`	client-查询用户信息（sso-server 开放了 `/sso/userinfo` 路由）

hosts：

1
2
3


127.0.0.1 sa-sso-client1
127.0.0.1 sa-sso-client2
127.0.0.1 sa-sso-client3

七、模式选型决策树

graph TD
 A[需要做 SSO] --> B{所有应用是否同域?}
 B -->|是| C[模式一: 同域共享 Cookie]
 B -->|否| D{是否能共享 Redis?}
 D -->|是| E[模式二: 跨域 ticket]
 D -->|否| F[模式三: 跨域跨 Redis 主动查询]

 C --> G{性能要求高?}
 G -->|是| C
 G -->|否| E

 E --> H{需要实时同步?}
 H -->|是| F
 H -->|否| E

八、写在最后

sa-token 的 SSO 模块是国内 Java 单点登录的标杆方案——配置简单、模式丰富、社区活跃。

个人建议：

同公司多子系统：模式一（同域）最快

不同根域多产品线：模式二（跨域 ticket）最经典

跨数据中心部署：模式三（跨域跨 Redis 推送）最稳

老项目改造：ReSdk 模式侵入最小

彻底解耦：NoSdk 模式只走 HTTP

参考资料

九、2024+ 视角：sa-token 1.38+ → 1.44+、OAuth2.0 与 OIDC 完整支持

本文写于 2021 年 12 月（sa-token 1.44.0 时代），sa-token 在 2024-2025 年完成了一次"质变"——从"权限认证"扩展为"OAuth2.0 / OIDC 全家桶"。

9.1 sa-token 版本演进（2021 → 2025）

版本	时间	关键变化
1.30.x	2021-06	基础 SSO 三模式（本文写于 1.44.0 之后，2021-12）
1.34.x	2023-08	新增 OAuth2.0 完整模块（authorization_code / client_credentials / password）
1.36.x	2024-02	新增 OIDC（OpenID Connect）模块，IdP / RP 一应俱全
1.38.x	2024-08	Spring Boot 3.x 完整支持——`sa-token-spring-boot3-starter` 单独发包
1.40.x	2025-03	JDK 21 虚拟线程适配、JWT 增强（jose4j 升级）
1.42.x	2025-08	Sa-Token SSO 三模式升级，新增模式四：SSO-IdP 标准 OIDC 接入
1.44.x	2026-01	前后端分离 OAuth2.0 PKCE 模式、多租户增强（Tenancy 抽象）

关键变化：从 1.36 开始，sa-token 不再只是"权限框架"，而是"OAuth2.0 / OIDC 服务端 + 客户端"——可以拿来做完整 IdP 平台。

9.2 2024+ 新模式：模式四 SSO-IdP（OIDC 标准）

2021 年本文介绍了三种 SSO 模式，2025 年 sa-token 新增"模式四"：

1
2
3
4
5
6
7


 IdP 平台
 │
 ┌───────────────────┼───────────────────┐
 ▼ ▼ ▼
 App1 (OIDC RP) App2 (OIDC RP) App3 (OIDC RP)
 - 企业自研 - 商业 SaaS - 第三方系统
 - 用 sa-token - 用 keycloak - 用 Auth0

特点：

完全兼容 OIDC 规范——任何标准 OIDC 客户端（keycloak / Auth0 / Okta）都能接入
Discovery Endpoint（/.well-known/openid-configuration）自动暴露 IdP 元信息
支持 PKCE——2024+ 移动互联网标配（防止授权码拦截）
JWK 端点（/.well-known/jwks.json）——第三方系统可以本地验证 JWT，无需请求 IdP

适用场景：企业自建 IdP 平台，对外开放给第三方应用或 SaaS 系统。

9.3 OAuth2.0 实战补充（2024+ 主流用法）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


# sa-token 1.38+ 配置 OAuth2.0 服务端
sa-token:
 oauth2:
 # 授权码模式 token 有效期
 code-timeout: 300
 # access_token 有效期
 access-token-timeout: 7200
 # refresh_token 有效期
 refresh-token-timeout: 2592000
 # 是否强制 PKCE（2024+ 强烈建议 true）
 force-pkce: true
 # 客户端列表
 clients:
 - client-id: web-admin
 client-secret: kQwIOrYvnXmSDkwEiFngrKidMcdrgKor
 grant-types:
 - authorization_code
 - refresh_token
 scopes:
 - user.read
 - user.write
 redirect-uris:
 - https://admin.example.com/oauth/callback
 - client-id: mobile-app
 # 移动端走 PKCE，不需要 client_secret
 grant-types:
 - authorization_code
 scopes:
 - user.profile
 redirect-uris:
 - com.example.app://oauth/callback
 require-pkce: true

2024+ 主流选择：

Web 后台 → authorization_code + client_secret
移动 App / SPA → authorization_code + PKCE（不再用 implicit 模式）
服务间调用 → client_credentials
老系统对接 → password（已不推荐，2024+ 多数项目禁用）

9.4 与 Spring Authorization Server / Keycloak 的对比

维度	sa-token OAuth2.0	Spring Authorization Server	Keycloak
学习成本	极低（中文文档）	中（需理解 Spring Security 6）	高（独立服务）
部署复杂度	嵌入式	嵌入式	独立进程
OIDC 完整度	1.42+ 完整	完整	完整（业界标杆）
国内合规	强（等保 2.0 SM2/SM4 支持）	中	弱（默认算法不符合国密）
生态丰富度	国内最活跃	国际化	国际化
多租户	1.44+ 增强	中	强
Spring Boot 3.x	1.38+ 完整	1.2+	26+

2024+ 选型经验：

国内中小项目：sa-token（最简单 + 中文社区）

企业级合规（金融/政务）：sa-token + 国密算法扩展

跨云/跨国大厂：Keycloak / Spring Authorization Server

不想自己运维：Auth0 / Authing（国内）/ 阿里云 IDaaS

9.5 个人回顾：从"单点登录"到"全场景身份中台"

3 年前写这篇文章时，sa-token 还只是"轻量级 Java 权限框架"。2024-2026 它已经演变成"Java 身份中台"：

2018-2020：单点登录（SSO）
2020-2022：权限认证 + 微服务网关
2022-2024：OAuth2.0 完整实现
2024-2026：OIDC IdP 平台 + 多租户 + 国密合规

国内 Java 身份认证的"大一统"正在发生——sa-token、Keycloak 都在抢"一站式 IdP"的山头。

如果 2024 年再做 SSO 选型，我会先评估"未来 3 年是否要做 IdP"——是 → sa-token 1.42+ / Keycloak；否 → 单点登录模式二 + 简单 Redis 即可。

参考资料（2024+ 补充）

2021 年开源生态观察：从工具到平台，从代码到协作

Mon, 10 May 2021 00:00:00 +0800

数据来源周期：2021 年 5 月，扫描 docs 源仓库下的 23 篇源文档，合并去重后得到 200+ 仓库的样本。

一、为什么值得关注

2021 年是开源生态一个微妙的"中段"——

前端：Vue 3 刚刚稳定，React 18 还在 RC 阶段，前端框架的迭代节奏第一次慢了下来
云原生：Kubernetes 1.21 刚发布，“上云"从一句口号变成默认假设
AI：PyTorch 1.8 / TensorFlow 2.4 已经"水到渠成”，但 ChatGPT 还要再过 1 年 8 个月才登场
基础设施：内网穿透、代理、IPTV 资源、社区电驴替代品……中国大陆开发者有自己独特的开源生态圈层

如果把 2021 年的 GitHub 仓库列表当成一个横截面去读，会发现很多几年后回看才会显现的趋势，早在 2021 年就已经埋下了种子。

二、样本结构

维度	数量 / 占比
仓库总数	≈ 200（合并去重后）
编程语言 Top 3	JavaScript / Python / Go
类别数	9 大类
大厂/官方项目占比	约 18%

九大类别分别是：

前端 / Node 生态（Vue、Element、qiankun、uni-app）
科学上网 / 内网穿透（v2ray、trojan、frp、shadowsocks 全家桶）
爬虫与数据采集（scrapy、requests-html、电商爬虫合集）
直播 / 视频资源（iptv-org、tvlist-awesome、youtube-dl）
运维 / 云原生（kubernetes、runc、frp、winsw、harbor）
开发工具（nvm-windows、psf/black、drawio、WindTerm、ohmyzsh）
数据库 / 消息（TDengine、emqx、redis、QuickMsg smqtt）
可视化（d3、Chart.js、metrics-graphics、Cesium）
教学 / 学习路径（es6tutorial、Hacking、IntelliJ-IDEA-Tutorial）

三、八大趋势观察

趋势 1：云原生成为默认"水电煤"

2017-2020 是 Kubernetes 跑马圈地的年代，2021 年开始，k8s 真的成了基础设施的默认假设：

仓库里出现 kubernetes/kubernetes（10w+ stars）作为"基础设施"被反复引用
goharbor/harbor（容器镜像注册中心）正式进入主流
apache/incubator-brpc、grpc/grpc、protocolbuffers/protobuf 三件套把"远程调用"标准化
Tencent/APIJSON 这种"零代码接口生成"工具开始走红——背后是 “我不想写 CRUD” 的开发者心声

结论：2021 年"上不上云"已经不是问题，“怎么上、用什么姿势上"才是。

趋势 2：内网穿透 / 代理生态自成体系

这是 2021 年中文开源圈最独特的一道风景：

类别	代表项目
路由器级代理	`liangweidonggood/openwrt-fanqiang`、`hq450/fancyss`
协议实现	`v2fly/v2ray-core`、`trojan-gfw/trojan`
桌面 GUI	`2dust/v2rayN`、`Qv2ray/Qv2ray`、`Cenmrev/V2RayW`
内网穿透	`fatedier/frp`
hosts 维护	`googlehosts/hosts`、`ineo6/hosts`、`oldj/SwitchHosts`

为什么值得关注：这批项目在 GitHub 上聚集了中文世界最高质量的开源协作——文档完整、社区活跃、维护及时、issue 响应快。任何一个想做"中文开发者社区运营"的人，都该认真研究这个生态。

趋势 3：SSH 协议接管 Git 工作流

“GitHub 使用 ssh 协议”

这一段在 2021 年终于从"高手配置"变成"新人必学”：

1
2
3
4
5
6
7
8
9


# 推荐使用 Ed25519 算法，它比 RSA 更安全且性能更好
ssh-keygen -t ed25519 -C "you@example.com"

# 配置 ssh 走 443 端口
Host github.com
 Hostname ssh.github.com
 Port 443
 User git
 IdentityFile ~/.ssh/id_ed25519

you@example.com（示例邮箱）这种"个人邮箱 + ed25519 + 443 端口绕过"的组合在 2021 年是几乎每个中文开发者的标配。SSH 协议从"运维专属"下沉到"日常开发"的标志性年份。

趋势 4：前端微服务 / 跨端框架并行

方向	代表项目
微前端	`umijs/qiankun`
跨端	`dcloudio/uni-app`、`umicro/uView`
后台模板	`Rudeus3Greyrat/vue3-element-admin`、`ColorlibHQ/AdminLTE`
桌面端	`jgraph/drawio-desktop`、`microsoft/terminal`

注意 vue3-element-admin 出现的年份——这恰好是 Vue 3 从 RC 转稳定的窗口期。前端开发者一边学新框架，一边在生产环境上用 Vue 2 + Element 做后台，这个双轨格局持续到 2023 年才彻底打破。

趋势 5：直播资源 / IPTV 自治社区

iptv-org/iptv、imDazui/Tvlist-awesome-m3u-m3u8、ChendoChap/pOOBs4

这一类项目属于"灰色但有真实需求"的典型：民间对电视直播、电竞主机破解、流媒体下载工具的旺盛需求，反过来推动了开源社区的活跃度。ytdl-org/youtube-dl、soimort/you-get 这种下载工具的命运起伏，后来还和 DMCA 法案反复过招。

趋势 6：数据库 / 时序数据开始分化

taosdata/TDengine：国产时序数据库第一次进入主流视野
redis/redis：依然稳坐缓存王者
uglide/RedisDesktopManager、qishibo/AnotherRedisDesktopManager：桌面客户端百花齐放——一个 Redis 客户端能跑出 5 个 fork，说明开发者对"图形化运维"的需求远未饱和
quickmsg/smqtt、eclipse/paho.mqtt.javascript、eclipse/mosquitto：MQTT 在 IoT 场景的协议栈成型

趋势 7：可视化工具"百花齐放"

场景	项目
数据可视化	`d3/d3`、`chartjs/Chart.js`、`metricsgraphics/metrics-graphics`
地图	`CesiumGS/cesium`
流程图	`jgraph/drawio` / `drawio-desktop`
2D 物理	`jonobr1/two.js`
3D	`mrdoob/three.js`

drawio 至今仍是流程图工具的事实标准之一，且能本地化部署 + 离线使用——这个属性在 2021 年没人觉得是优势，到了 2024 年企业市场突然爆火。

趋势 8：教学型仓库爆款公式

观察一下 2021 年教学型仓库的爆款公式：

中文翻译（1c7/Crash-Course-Computer-Science-Chinese）
路线图（tangyudi/Ai-Learn）
awesome 系列（facert/awesome-spider、rockerBOO/awesome-neovim）
书单（itdevbooks/pdf、forthespada/CS-Books）
镜像 / fork + 注释（veloren 这种大型游戏项目的 fork 笔记）

教学型仓库的核心竞争力不是"原创"，而是"整理 + 翻译 + 索引"。

四、值得跟踪的"长寿"项目

在 200+ 仓库里，到今天（2026）仍然活跃的不算多，下面这些是 5 年后还能更新、还在被引用的"长青树"：

项目	2021 状态	2024 状态
`microsoft/terminal`	Windows Terminal 1.x	已成 Windows 必装
`jgraph/drawio`	v14	仍是流程图首选
`opencontainers/runc`	容器底层	仍是 K8s 核心依赖
`syncthing/syncthing`	P2P 文件同步	安全圈的"瑞士军刀"
`scrapy/scrapy`	Python 爬虫事实标准	仍是大厂数据团队底座
`kubernetes/kubernetes`	1.21	已成云时代操作系统
`grpc/grpc`	跨语言 RPC 主流	服务网格的基础组件
`d3/d3`	可视化鼻祖	仍被无数 BI 工具致敬

五、总结

回顾 2021 年的开源生态，真正留下的不是"最火的项目"，而是"沉淀下来的协作模式"：

中文开发者社区的成熟——ed25519 + SSH + v2ray 圈层的密度史无前例
云原生基础设施的稳态化——K8s 不再是"前沿"，而是"默认"
前端框架的过渡期——Vue 3 / React 18 / 微前端三件事并行，谁也没赢
国产开源开始有国际影响力——TDengine、Vue、uni-app 都走出了纯中文圈
教学型仓库的爆款公式被验证——这个公式到 2024 年还在用

站在 2026 年（本文写于 2021，5 年后再回望）看 2021，最大的感慨是：那一年的 GitHub Trending 上根本看不到 LLM 相关项目。开源世界改天换地的速度，比我们预想的还要快。

参考资料

六、2024+ 视角：5 年后回望，趋势是否兑现？

本文写于 2021 年 5 月。2026 年回望，21 年埋下的 8 大趋势种子，4/8 已经结果，2/8 被证伪，2/8 仍在酝酿。下面逐条对照。

6.1 趋势 1-3 兑现度

趋势 1（云原生成为默认水电煤）→ 完全兑现：

2024 年 K8s 1.30 已经是"装机必备"——containerd 替代 dockerd 在 2024 年完成（Docker Engine 退场）
2025 年 eBPF 成为云原生新底座（取代部分 iptables 场景）
2026 年 K8s + AI/ML 编排（kuberay、kfserving）成为 AI 平台的事实标准
harbor 在 2024-2025 仍是主流镜像仓库（虽然 OCI 标准化让 AWS ECR / 阿里 ACR / Harbor 可以互通）

趋势 2（内网穿透 / 代理生态自成体系）→ 部分兑现 + 暗线影响：

2021 年 v2ray/frp 圈是中文开源最活跃的"地下"协作
2022 年 10 月起，部分翻墙相关仓库被 GitHub 批量封禁（包括很多教程仓库）
2024-2025 主流路线从"自建代理"转向"专业机场" + WireGuard/Tailscale 替代
frp 本身反而更活跃——企业内网穿透（堡垒机替代品）成为主流用法
tailscale / headscale 等基于 WireGuard 的新方案在 2023-2025 大爆发

趋势 3（SSH 协议接管 Git 工作流）→ 完全兑现，但被 GitHub CLI 抢戏：

2024-2025 几乎所有 Git 操作默认走 SSH（ed25519 是绝对主流）
GitHub CLI（gh） 2023-2025 大爆发，部分场景替代了 SSH 直连
VSCode Remote SSH 2024-2026 仍是云开发标配

6.2 趋势 4-6 兑现度

趋势 4（前端微服务 / 跨端框架并行）→ 兑现，但格局大变：

qiankun 在 2024-2025 仍占一席之地，但 微前端整体热度下降——webpack 5 Module Federation 让"微前端"变成 webpack 标配功能
uni-app / Taro 双雄格局稳定，2024 年都加上了"AI 智能生成代码"功能
Vue 3 vs React 18 在 2024-2025 决出胜负：React Server Components + Next.js 占据前端框架头部，Vue 3 在国内继续强势但国际化落后
Solid.js / Qwik 等"细粒度响应式"框架在 2024-2025 出圈
2026 H1：“前端框架"讨论热度整体下降——AI 编码让"框架选择"变得没那么重要

趋势 5（直播资源 / IPTV 自治社区）→ 黯淡，但 youtube-dl 系活下来：

2021-2024 IPTV 社区基本被监管消灭——GitHub 上主流 m3u 仓库要么归档、要么被 DMCA
ytdl-org/youtube-dl 在 2020 RIAA 诉讼后转 yt-dlp（社区 fork），2024-2026 仍是视频下载工具的事实标准
哔哩哔哩 bilix / lux / you-get 等中文工具命运起伏
Web 直播本身反而大爆发——抖音 / TikTok / YouTube Shorts 让 IPTV 失去吸引力

趋势 6（数据库 / 时序数据开始分化）→ 完全兑现，且走得更远：

TDengine 3.0（2023-10 发布）在 2024-2026 持续扩大，国内时序库头名稳固
IoTDB（清华 Apache 孵化）在 2024-2025 进入 Apache TLP，国内时序库第二
InfluxDB / TimescaleDB 仍在欧美主导
2024-2026 新趋势：“云原生数据库” 全面替代传统 DBA 模式——Aurora / PolarDB / TiDB Cloud / CockroachDB
向量数据库（pgvector / Qdrant / Milvus）2024-2026 大爆发——LLM 时代的"数据库新物种”
Redis 2024 年完成"开源协议变更"风波（2024-03 起从 BSD 改 SSPL + RSAL）——国内 Redis 替代品（KeyDB / Dragonfly / 阿里 Tair） 借机爆发

6.3 趋势 7-8 兑现度

趋势 7（可视化工具百花齐放）→ 部分兑现，AI 改变格局：

drawio 2024-2026 仍是流程图首选（“本地部署"属性让它在企业市场爆火——文章当时已提到）
d3.js 仍被无数 BI 工具致敬，但直接使用 d3 的项目少了——大家都用 ECharts / AntV / Recharts 二次封装
2024-2026 真正的大变化：
- AI 生成图表（ChartGPT、Vizro、GenBI）开始挑战传统 BI
- Cesium 在数字孪生 / 智慧城市项目里 2024-2025 爆发
- deck.gl（Uber 出品）成为地理可视化新宠
- 白板工具（tldraw、excalidraw、miro）2024-2026 集体 AI 化

趋势 8（教学型仓库爆款公式）→ 兑现 + AI 改变教学本身：

中文翻译、路线图、awesome 系列、书单这 4 个公式到 2026 仍然有效
2024-2026 最大的变化：
- awesome 系列被 AI 索引工具部分替代（GitHub trending + ChatGPT 搜索）
- 路线图（roadmap.sh） 在 2024-2025 仍是工程师入门第一站
- AI 编程教程（microsoft/generative-ai-for-beginners、anthropics/prompt-eng-interactive-tutorial）2024-2026 成为新公式
- Bilibili + YouTube 视频教程对纯文字教学仓库的冲击越来越大
- LeetCode 中文站在 2024 估值 25 亿美元（部分 IPO 消息）

6.4 21 年没看到的暗线：5 年后的新增趋势

回看 2021 年的"九大类别”，有几个类别在 2026 年已经退出历史舞台：

科学上网 / 内网穿透 → 萎缩（监管 + WireGuard 替代）
IPTV / 直播资源 → 大幅萎缩
桌面 GUI 代理（v2rayN / Qv2ray）→ 退出主流

同时有几个 2021 年没出现、2026 年成为主流的类别：

AI Agent / Harness（参见 2026-06-03 Trending 周报）
大模型本地部署（Ollama / LM Studio / Jan）
AI 编程工具（Cursor / Claude Code / Continue.dev）
向量数据库（pgvector / Qdrant / Milvus）
国密合规基础库（国密 SM2/SM3/SM4 算法的开源实现）
数字孪生 / 工业软件（Cesium / Three.js / WebGL 在工业场景）

6.5 总结：开源生态的 5 年大周期

把 2021-2026 这 5 年看成一个完整周期，开源世界发生了 3 件事：

基础设施化——K8s、向量库、AI 框架从"前沿"变成"水电煤"
垂直化——通用工具（jQuery 时代）→ 框架时代（Vue/React）→ 垂直工具时代（AI × 行业）
AI 化——2021 年 GitHub Trending 上看不到一个 LLM 项目，2026 年 LLM 项目占 Trending 70%+

5 年后回望，2021 年是"AI 革命前夜"——云原生 + 微前端 + 时序数据库这些"非 AI 趋势"继续发展，但真正的范式转移是 2022-11 ChatGPT 发布后才开始的。

参考资料（2024+ 补充）

GB28181 视频监控平台深度剖析：WVP-GB28181-pro 全链路源码分析

Tue, 15 Sep 2020 00:00:00 +0800

WVP-GB28181-pro 是国内基于 GB/T 28181 国标协议的视频监控管理平台，2020 年 GitHub 上 648540858/wvp-GB28181-pro 仓库 star 数已经超过 4k。它的核心是用 JAIN SIP 协议栈做信令服务，把 GB28181 设备（摄像头、NVR、平台）注册到平台，然后做实时视频流转发、云端录像、录像回放、级联、报警等。本文从源码层做一次完整剖析。

本文写于 2020 年 9 月——WVP-GB28181-pro 1.x 时代。该项目至今仍在持续迭代。

一、GB28181 协议基础

GB/T 28181-2016《安全防范视频监控联网系统信息传输、交换、控制技术要求》是中国公安部主导的国标协议，用于把不同厂商的摄像头/NVR 统一接入到一个平台上。

1.1 协议核心特征

信令协议：SIP（RFC 3261）+ SDP
传输层：UDP（默认）/ TCP
媒体流：RTP/RTCP（基于 RTSP 推流或 PS 封装的 RTP）
编解码：H.264 / H.265 / SVAC
核心交互：注册、目录查询、实时点播、回放、下载、报警、级联

1.2 GB28181 与 ONVIF 的区别

维度	GB28181	ONVIF
国别	中国国标	国际标准
协议	SIP	HTTP + RTSP
推送方式	主动注册 + 平台调度	设备发现 + RTSP 拉流
主要场景	平安城市、雪亮工程	企业园区、商业楼宇
厂商支持	海康/大华/宇视/科达	Axis/Bosch/Hanwha

二、WVP-GB28181-pro 项目架构

2.1 项目定位

WVP-GB28181-pro 是纯 Java 实现的 GB28181 国标信令网关 + 流媒体服务：

前端：Vue + Element UI（管理摄像头、用户、回放、录像）
后端：Spring Boot + JAIN SIP + ZLMediaKit（流媒体）
存储：MySQL（设备信息）+ Redis（信令缓存）+ MinIO/阿里 OSS（录像）

2.2 核心模块

1
2
3
4
5
6
7


com.<your-org>.stream.gb28181
├── SipLayer # SIP 服务端（监听 5060 端口）
├── config # 配置（信令端口、IP、上级平台）
├── media # 媒体流转发
├── session # 客户端会话管理
├── event # 事件订阅与通知
└── controller # REST API（前端调用）

2.3 关键依赖

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


<dependencies>
 <!-- SIP 协议栈 -->
 <dependency>
 <groupId>javax.sip</groupId>
 <artifactId>jain-sip-ri</artifactId>
 <version>1.3.0-91</version>
 </dependency>

 <!-- Spring Boot Web -->
 <dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-web</artifactId>
 </dependency>

 <!-- ZLMediaKit Java SDK -->
 <dependency>
 <groupId>com.aizuda</groupId>
 <artifactId>zlmediakit-java-sdk</artifactId>
 </dependency>
</dependencies>

三、SIP 信令栈核心：JAIN SIP API

3.1 SipProvider 实现

WVP 使用的 JAIN SIP 协议栈在 gov.nist.javax.sip 包下：

1
2
3
4
5
6


public class SipProviderImpl implements
 SipProvider, // 公共 SIP 接口
 SipProviderExt, // 扩展接口
 SIPTransactionEventListener, // 事务事件
 SIPDialogEventListener { // 对话事件
}

三个核心能力：

发送 SIP 消息（REGISTER / INVITE / MESSAGE / BYE）
接收 SIP 消息（响应 + 异步事件）
管理 SIP 事务 + 对话（事务超时、重传）

3.2 SipListener 接口

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


public interface SipListener extends EventListener {
 // 1. SIP 请求消息到达时 REGISTER/INVITE/BYE/MESSAGE
 void processRequest(RequestEvent event);

 // 2. SIP 响应消息到达时（200 OK / 401 / 403 等）
 void processResponse(ResponseEvent event);

 // 3. SIP 事务超时（INVITE 超时、OPTIONS 心跳超时等）
 void processTimeout(TimeoutEvent event);

 // 4. 网络 I/O 异常（连接断开、发送失败）
 void processIOException(IOExceptionEvent event);

 // 5. SIP 事务结束（ACK 收到后 INVITE 事务终结）
 void processTransactionTerminated(TransactionTerminatedEvent event);

 // 6. SIP 对话（Dialog）结束（双方会话完全终结）
 void processDialogTerminated(DialogTerminatedEvent event);
}

WVP 中所有 SIP 入口都通过 SipListener 接收，然后分发给具体的 ISIPProcessorObserver 处理。

四、SipLayer 服务端源码剖析

4.1 SipLayer 完整结构

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


@Slf4j
@Component
@Order(value = 10)
public class SipLayer implements CommandLineRunner {
 @Autowired
 private SipConfig sipConfig;

 @Autowired
 private ISIPProcessorObserver sipProcessorObserver;

 @Autowired
 private UserSetting userSetting;

 // TCP 与 UDP 的 SIP Provider 映射
 private final Map<String, SipProviderImpl> tcpSipProviderMap = new ConcurrentHashMap<>();
 private final Map<String, SipProviderImpl> udpSipProviderMap = new ConcurrentHashMap<>();

 // 已监听过的 IP（防止重复 bind）
 private final List<String> monitorIps = new ArrayList<>();

 @Override
 public void run(String... args) {
 // 应用启动时初始化 SIP 监听
 initSipServer();
 }

 public SipProviderImpl getUdpSipProvider(String ip) { /* ... */ }
 public SipProviderImpl getUdpSipProvider() { /* ... */ }
 public SipProviderImpl getTcpSipProvider(String ip) { /* ... */ }
 public SipProviderImpl getTcpSipProvider() { /* ... */ }
 public String getLocalIp(String deviceLocalIp) { /* ... */ }
}

4.2 关键设计点

1. 双协议监听（TCP/UDP）：

GB28181 设备通常用 UDP 5060 端口
高级设备或跨网段用 TCP 5060 端口
同一进程需要同时维护两套 SipProvider

2. 多 IP 监听：

多网卡服务器需要监听所有 IP
tcpSipProviderMap / udpSipProviderMap 按 IP 维度维护
monitorIps 列表去重，防止重复 bind

3. 启动顺序 @Order(10)：

Spring Boot CommandLineRunner 启动后立即初始化
@Order(10) 保证在 Spring 主流程就绪后才启动 SIP
失败的 SIP 初始化不会阻断 Web 服务

五、完整调用链：设备注册到目录查询

5.1 时序图

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


 Device WVP Controller sipCommander 设备 CatalogResponseMessageHandler DeviceChannelMapper DB
 │ │ │ │ │ │ │
 │─注册成功─▶│ │ │ │ │ │
 │ │─sync(device)───▶│ │ │ │ │
 │ │ │─CatalogQuery─▶│ │ │ │
 │ │ │◀──Catalog XML─│ │ │ │
 │ │ │ │──handle()───────▶│ │ │
 │ │ │ │ │──batchAdd───────────▶│ │
 │ │ │ │ │──batchUpdate────────▶│ │
 │ │ │ │ │──batchDel───────────▶│ │

5.2 调用链详解

阶段 1：设备注册

1
2
3
4
5
6


设备 → REGISTER → SipLayer（UDP 5060）
 → SipListener.processRequest()
 → ISIPRequestObserver（注册处理器）
 → 校验设备 ID + 密码
 → 更新设备状态为"在线"
 → 200 OK

阶段 2：心跳保活

1
2
3
4
5


设备 → MESSAGE（Keepalive） → SipLayer
 → SipListener.processRequest()
 → 解析 XML 设备状态
 → 更新设备最后心跳时间
 → 200 OK

阶段 3：目录查询（Catalog Query）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


WVP Controller 触发"同步通道"
 → DeviceService.sync()
 → sipCommander.catalogQuery(device, deviceChannel)
 → SIP MESSAGE（带 Catalog 查询 XML）
 → 设备 → 200 OK
 → 设备 → SIP MESSAGE（异步返回 Catalog 列表）
 → SipLayer → CatalogResponseMessageHandler.handle()
 → 解析 XML 中的通道列表
 → DeviceChannelMapper.batchAdd(新增通道)
 → DeviceChannelMapper.batchUpdate(更新通道)
 → DeviceChannelMapper.batchDel(删除通道)
 → 写入 DB

六、请求处理统一入口：ISIPRequestProcessor

6.1 处理器接口

1
2
3
4
5
6
7


public interface ISIPRequestProcessor {
 // 处理方法名
 String getMethod();

 // 处理逻辑
 void process(RequestEvent event);
}

6.2 内置处理器

WVP 内部为每种 SIP 请求都实现了一个 ISIPRequestProcessor：

Method	处理器	用途
`REGISTER`	RegisterRequestProcessor	设备注册
`MESSAGE`	MessageRequestProcessor	消息分发（心跳/目录/报警）
`INVITE`	InviteRequestProcessor	实时点播
`BYE`	ByeRequestProcessor	结束点播
`SUBSCRIBE`	SubscribeRequestProcessor	事件订阅
`ACK`	AckRequestProcessor	INVITE 确认
`OPTIONS`	OptionsRequestProcessor	能力探测

6.3 派发器实现

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


public class SIPRequestProcessorParent implements SipListener {
 @Autowired
 private List<ISIPRequestProcessor> processors; // Spring 自动注入

 @Override
 public void processRequest(RequestEvent event) {
 Request request = event.getRequest();
 String method = request.getMethod();

 for (ISIPRequestProcessor processor : processors) {
 if (method.equals(processor.getMethod())) {
 processor.process(event);
 break;
 }
 }
 }
}

设计模式：策略模式 + 依赖注入——新增请求类型只需要新增一个 ISIPRequestProcessor 实现，Spring 自动扫描注册。

七、流媒体集成：ZLMediaKit

WVP 本身不做媒体流转发，它把流媒体的工作交给 ZLMediaKit（一个基于 C++ 的高性能流媒体服务）：

1
2
3


GB28181 设备 → RTP/PS 流 → WVP 接收 → ZLMediaKit 拉流
 → 转 RTMP/HLS/WebRTC
 → 推到客户端

7.1 ZLMediaKit 角色

接收端：通过 RTP 接收 PS 流（来自 GB28181 设备）
转换端：把 PS 流转换为 RTMP/HLS/WebRTC
分发端：把转换后的流推给浏览器/移动端/录像

7.2 WVP 调用 ZLMediaKit 的方式

1
2
3
4
5
6
7
8


// WVP 通过 HTTP API 调用 ZLMediaKit
POST http://zlmediakit:9000/index/api/openRtpServer
Body:
{
 "port": 10000,
 "enable_tcp": true,
 "stream_id": "channel_001"
}

八、关键坑点与实战经验

8.1 SIP 端口冲突

1
2
3
4


# 错误：Address already in use
# 原因：5060 端口被系统 SIP 服务占用
lsof -i :5060
# 解决：修改 WVP 配置改用其他端口

8.2 设备注册失败

现象	原因	解决
401 Unauthorized	设备密码错误	检查 `UserSetting` 配置
408 Request Timeout	网络不通	检查防火墙 + 端口
480 Temporarily Unavailable	平台未就绪	检查 ZLMediaKit 状态

8.3 视频流拉不到

现象	原因	解决
ZLMediaKit 返回错误	流地址配置错误	检查 `stream_id`
客户端黑屏	编解码不兼容	强制转码
录像文件 0 字节	录制路径权限	`chown` 给 WVP 用户

九、写在最后

WVP-GB28181-pro 的成功在于：

选型准确——Java 做信令网关（生态成熟、Spring Boot 快速开发）
解耦清晰——SIP 信令 + 媒体流分离（ZLMediaKit 处理高吞吐）
实战性强——适配海康/大华/宇视主流厂商设备
社区活跃——issue 响应快，文档持续更新

个人建议：

想要自建视频监控平台：WVP + ZLMediaKit 是国内最成熟的组合

商业项目：考虑EasyCVR / TSINGSEE 等商业产品（带 UI 和运维）

国家级项目：需要支持GB28181-2022 新国标（WVP 已部分支持）

参考资料

GB/T 28181-2016 协议规范
WVP-GB28181-pro GitHub
ZLMediaKit 官方文档
[JAIN SIP API 文档](https://docs.oracle.com/cd/E13203_01/tuxedo/tux90/ sip_java/javax/sip/SipListener.html)

十、2024+ 视角：GB28181-2022、AI 视频分析与 WebRTC 播放

本文写于 2020 年 9 月，WVP-GB28181-pro 至今仍是最活跃的国标信令网关。下面补充 2024-2026 行业关键变化：GB28181-2022 新国标、AI 视频分析、WebRTC 浏览器播放、ZLMediaKit 演进。

10.1 GB28181-2022 新国标：协议升级到"互联网友好"

GB/T 28181-2022 在 2023 年正式实施，对开发影响最大的是 4 件事：

TCP 协议从可选升级到推荐——2020 时代用 UDP 5060 是默认，2024+ 因为防火墙/NAT，TCP 已成为企业内部部署首选
H.265/HEVC 强制支持——eladmin 之类的旧版本 WVP 客户端无法解码 H.265 流，2024+ WVP-GB28181-pro 默认带 H.265 解码
信令通道支持 HTTPS / WSS——2020 时代 SIP 走 UDP 明文，2024+ 公安部等保 2.0 三级要求信令加密
多级级联 + 跨域互联——上/下级平台鉴权从 IP 白名单升级到 OAuth 2.0

WVP-GB28181-pro 在 2024 年的 2.0+ 版本（社区称为 WVP-PRO v2）已经默认兼容 2016 + 2022 双协议。

10.2 WVP 项目的关键演进（2020 → 2026）

维度	2020（v1.x）	2024+（v2.x）
Spring Boot	2.4.x	3.2.x
JDK	8	17 / 21
SIP 协议栈	jain-sip-ri 1.3.0-91	mjSIP 或 RestComm 替代（社区维护）
流媒体	ZLMediaKit HTTP API	ZLMediaKit 25.x + SRS 5.x 双支持
前端	Vue 2 + Element UI	Vue 3 + TypeScript + Vben
协议支持	GB28181-2016	GB28181-2016 + 2022 双协议
AI 集成	无	内置 AI 视频分析插件（火焰/安全帽/人脸）

10.3 AI 视频分析：从"看到"到"看懂"

2020 年的 WVP 主要是"信令 + 流转"，2024-2026 的核心增量是 AI 视频分析：

海康/大华原生 AI 摄像头（内置 NPU）——边缘推理，云端只收告警
云端 AI 分析插件（基于 YOLOv8 / RT-DETR）——WVP 接入 RTSP 流后调用 AI 服务，实现"事后分析 + 实时告警"
多模态大模型（LLaVA、GPT-4V）——2025-2026 的 WVP 高级版本可以"上传一张图，问 AI 视频里发生了什么"

实战架构（2025 主流）：

1
2
3
4
5
6
7


GB28181 摄像头 → WVP（信令）→ ZLMediaKit（流媒体）
 ↓
 AI 分析服务（Python + YOLOv8）
 ↓
 告警 → Kafka → 业务系统
 ↓
 录像 → MinIO / 阿里 OSS

单纯做信令网关的 WVP 价值在 2025 年正在被压缩，“WVP + ZLMediaKit + AI 分析"的三件套才是完整方案。

10.4 WebRTC 浏览器播放：解决 H5 时代痛点

2020 年的痛点：浏览器只能看 HLS（延迟 3-5 秒）或 RTMP（需要 Flash）。2024+ 的方案：

ZLMediaKit 内置 WebRTC——浏览器直接 <video> 标签播放，延迟 <500ms
WVP 把 GB28181 PS 流推到 ZLMediaKit → 转 WebRTC——完整链路延迟 <1s
WHEP / WHIP 协议——2024 年成为 WebRTC 与 GB28181 互通的事实标准

实际项目里：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


// 浏览器端 WebRTC 拉流（2024+ 主流）
const pc = new RTCPeerConnection();
pc.addTransceiver('video', { direction: 'sendrecv' });
pc.addTransceiver('audio', { direction: 'sendrecv' });

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

// 拉 ZLMediaKit 的 WebRTC 流
const resp = await fetch('http://zlmediakit:9000/index/api/webrtc?app=live&stream=cam001&type=play');
const answer = await resp.json();
await pc.setRemoteDescription(answer);

pc.ontrack = (event) => {
 document.getElementById('video').srcObject = event.streams[0];
};

10.5 实战补充（2024-2026）

K8s 部署：WVP + ZLMediaKit 全部跑在 K8s，VIP 改成 K8s Service（不再需要 Keepalived）
可观测性：WVP 接入 Prometheus + Grafana，SIP 注册成功率、在线设备数、流转发 QPS 全部可视化
安全加固：
- SIP 端口从 5060 改 5061（WSS 加密）
- Redis 加 TLS
- ZLMediaKit 的 HTTP API 加 JWT 鉴权
大规模部署：单 WVP 实例承载 5000+ 设备，集群方案需要 2024+ 的 WVP-PRO 商业版

10.6 个人总结：WVP 5 年的变化

2020 年做视频监控 = 信令网关 + 拉流分发
2024 年做视频监控 = 信令网关 + 流媒体 + AI 分析 + 浏览器低延迟
2026 年做视频监控 = 全套 + 多模态 AI + 边缘计算

WVP-GB28181-pro 这个项目 5 年来依然是国内 Java 视频监控的"事实标准”——只是从"信令网关"演变成了"AI 视频平台入口"。

Opensource on Liangweidong's blog

Spring Boot 与 JDK 版本演进：从 1.5 到 3.2 的二十年 Java 生态大事记

一、JDK 版本演进时间线（1996-2024）

1.1 LTS 节奏

1.2 JDK 8 的"长寿"原因

1.3 JDK 11 的 5 大新特性

二、Spring Boot 版本演进时间线（2014-2024）

2.1 Spring Boot 版本命名规则

2.2 截至 2024-12 的版本选择

2.3 Spring Boot 2.6 → 2.7 关键变化

三、版本选型实战建议（2024 年时点）

3.1 新项目起步

3.2 升级路径

3.3 监控升级

四、写在最后

五、2024 视角回望 2018

参考资料

国内 SaaS 后台脚手架三巨头横评：jeecg-boot / ruoyi-cloud-plus / yudao-cloud

一、三巨头基本信息

二、定位差异：低代码 / 快速开发 / 全场景

2.1 jeecg-boot：低代码 + 表单设计器

2.2 RuoYi-Cloud-Plus：快速开发 + 多租户

2.3 yudao-cloud：全场景商城 + 报表

三、技术栈对比

3.1 后端对比

3.2 前端对比

四、代码生成器对比

五、二开组织流程对比

5.1 jeecg-boot：fork + 双分支策略

5.2 RuoYi-Cloud-Plus：四层仓库模型

5.3 yudao-cloud：商业文档 + 单仓库模式

六、选型决策树

七、实战对比表（2017-2024 七年使用感受）

八、迁移成本对比

8.1 jeecg-boot → RuoYi

8.2 RuoYi → yudao

8.3 跨生态

九、写在最后（2024 视角回望 2017）

参考资料

国内开源 Java 脚手架生态全景：Dromara 组织与低代码平台横评

一、Dromara 组织概览

二、22 款主流脚手架全景

2.1 脚手架横向对比

2.2 分类总结

三、四大明星项目深度对比

3.1 jeecg-boot：低代码之王

3.2 pig：微服务 + 业务组件

3.3 SpringBlade：微服务 + 多端

3.4 lamp-cloud：微服务 + 集大成

四、技术栈对比

五、Dromara 组织明星项目盘点

5.1 工具类

5.2 中间件类

5.3 数据类

5.4 测试类

六、项目例子

6.1 行业模板

6.2 协议类（车载/物联网）

七、学习路线

7.1 入门

八、框架

九、工具

十、选型决策树

十一、写在最后

十二、2024+ 视角：JDK 21/22、Spring Boot 3 与 Dromara 新生态

12.1 JDK 21 LTS 改变了脚手架技术栈的"地板"

12.2 Dromara 组织 2024-2025 关键变化

12.3 Spring Boot 3.x 迁移：脚手架的"分水岭"

12.4 选型补充：2025 年的"快速判断表"

12.5 个人随笔：脚手架的"尽头"是平台化

参考资料

跨语言开源生态：Go / Python / 前端 学习路径与工具选型

一、Go 语言生态（67+ 仓库）

1.1 脚手架

1.2 项目例子

1.3 学习

1.4 框架

1.5 库

1.6 工具

1.7 Go 学习路径推荐

跨语言开源生态：Go / Python / 前端学习路径与工具选型