夜雨聆风技术选型与依赖清单：为什么是 pig + UniApp + Element Plus
写在前面
写完前四篇，需求理清了、IDE 选好了，到了真正写代码的关口。但还有一件事卡着我——技术栈到底用什么版本。
这听起来又是一个很无聊的问题：「最新版不就完了？」但实际做选择的时候，几个矛盾同时摆在我面前：
后端想用 Spring Boot 4.0 的新特性（虚拟线程、GraalVM），但生态成熟度够不够？
AI 接入想用 Spring AI 2.0，但它强制要求 Spring Boot 3.4+，会不会把我整个依赖链带飞？
不想裸写 Spring Boot，需要一个脚手架（OAuth2 / RBAC / 字典 / 代码生成器），但又不能太重
选了脚手架就被它的版本节奏绑死，它没升 Spring Boot 4，你就上不去
我大概花了一周时间做调研，最后定的方案是：pig 框架 + Spring Boot 4.0 + Spring AI 2.0 + UniApp + Element Plus。这一篇就把选型过程、版本对比、踩坑记录都写下来。
为什么这篇这么长？因为选型是「一天决定、半年还债」的事情。我宁愿把每一个版本号的对齐关系都写清楚，也不想半年后某个夜里被一个 ClassNotFoundException 干醒。
一、后端选型：为什么不用裸 Spring Boot
先说后端脚手架。
很多教程都会告诉你「裸写 Spring Boot 最纯粹、最干净」。这话没错，但只适合 demo。真实的项目里，你只要开始写，立刻就会遇到这些东西：
登录认证：JWT 还是 OAuth2？密码加密用什么？token 续签怎么做？
权限管理：RBAC 角色权限模型、菜单权限、按钮权限、数据权限
字典管理：男 / 女、启用 / 禁用、订单状态……这些枚举值总不能写死在代码里
菜单管理：动态菜单、菜单缓存、菜单按钮权限
代码生成器：一张表生成 Entity / Mapper / Service / Controller / Vue 列表页 / 表单页
任务调度：定时任务、分布式锁
日志审计：操作日志、登录日志
这些东西自己写，每一项都是一周起步。你不写，等项目上线就会被各种「为什么没有这个功能」的灵魂拷问淹没。
我是个独立开发者，没那个时间。所以我决定上脚手架。主流的 Java 脚手架我对比过几个：
选了 pig，原因后面专门讲。
二、Spring Boot 4.0 vs 3.x：到底差在哪
这是这一篇的重头戏之一。很多人觉得「大版本升级就是改个版本号」，但 Spring Boot 4 不是这样——这是一次代际跃迁。
我先说结论：Spring Boot 4.0 基于 Spring Framework 7.0 构建，从语言基线、规范基线、性能模型到可观测性体系，全面刷新。
2.1 JDK 基线：17 是底线，21 是甜点
Spring Boot 3.x 的 JDK 最低要求是 17，4.0 依然是 17，但含义完全不同：
在 3.x 时代，虚拟线程是「能用但用得别扭」——调度器有 pinning 问题、synchronized 会把虚拟线程钉在载体线程上、StructuredTaskScope 还是预览 API。
到 4.0 + JDK 21：synchronized 的 pinning 问题被 JVM 层修复、结构化并发 GA、Sequenced Collections 等语言特性都能用。
我的选择：JDK 21 LTS。17 只是「能跑」，21 才是「跑得爽」。
2.2 Jakarta EE 9 → 11：又一次包名地震？
很多人对 Spring Boot 2 → 3 那波 javax.* → jakarta.* 的迁移心有余悸。好消息是 4.0 不再搞包名级别的全量地震，但规范版本往前走了一步：
包名没变，但规范版本升了——Servlet 6.1、JPA 3.2、Validation 3.1。这意味着：老的 javax.* 第三方库彻底不能用了；部分依赖的 Jakarta 规范实现要升到对应版本（Hibernate、Tomcat、Jetty）。
2.3 GraalVM AOT：从实验特性到生产级
这是 4.0 最让人兴奋的变化之一。
对一个要做 AI 接入的应用来说，这个收益非常大——Spring AI 调用大模型时要做大量的反射、Bean 注册，AOT 能把这些在编译期固化掉，启动时不用再花十几秒等 Bean 解析。
代价：原生镜像不支持运行时动态加载类、不支持反射的一部分用法（要写 reflect-config.json），调试体验差。我的策略是开发期用 JVM，部署时再开 native。
2.4 Virtual Threads：从可用到好用
虚拟线程在 Spring Boot 3.2 就已经能用了，但 4.0 才把它做透了。
# Spring Boot 4.0 开启虚拟线程，一行配置
spring:
threads:
virtual:
enabled: true
这一行配置之后，Tomcat 的请求处理线程、@Async 异步任务、RestClient 调用，统统自动切到虚拟线程。
对比 3.x 的差异：
3.x 需要手动
Executors.newVirtualThreadPerTaskExecutor()3.x 的
synchronized块会让虚拟线程 pin 在载体线程上4.0 + JDK 21 把
synchronized的 pinning 问题在 JVM 层修复了4.0 的
StructuredTaskScope让结构化并发能用
对一个 AI 应用的意义：一次 AI 调用动辄几秒，传统线程池扛几十个并发就吃力；虚拟线程轻松扛上千并发，每次大模型调用都开一个虚拟线程，根本不慌。
2.5 Micrometer 2.0 + OpenTelemetry：可观测性革命
这是 Spring Boot 4 最被低估的升级。
<!-- Spring Boot 4.0 一行依赖全搞定 -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-opentelemetry</artifactId>
</dependency>
对 AI 应用尤其重要：链路追踪能看到一次 AI 调用从「Controller 收到请求 → 检索 → 拼 Prompt → 调模型 → 解析返回」的完整链路，对调优是降维打击。
2.6 声明式 HTTP 客户端：告别 RestTemplate 和 Feign
Spring Boot 4.0 把声明式 HTTP 客户端正式内置了。
// 只定义接口，Spring 自动生成实现类
@HttpExchange(url = "https://api.deepseek.com")
public interface DeepSeekClient {
@PostExchange("/v1/chat/completions")
ChatResponse chat(@RequestBody ChatRequest request);
}
然后直接 @Autowired 注入就能用。再也不用写 RestTemplate、WebClient 的各种封装了。在 AI 开发里这个特别有用——每个模型厂商都有自己的 API 风格，用声明式客户端能快速接一堆模型。
2.7 BeanRegistrar：动态 Bean 注册的终极解法
Spring Boot 4.0 推出了 BeanRegistrar，专门用来解决 3.x 时代 @Bean + @Conditional 套娃的问题。
Spring AI 2.0 的多模型自动配置就是基于这个机制实现的——这也是为什么 Spring AI 2.0 必须要求 Spring Boot 4.0。
2.8 其他破坏性变更
除了上面的亮点，4.0 还有一批必须改的破坏性变更：
jakarta.* | ||
AutoConfiguration.imports |
好消息：3.x → 4.x 的迁移比 2.x → 3.x 平滑得多，没有再来一次全量包名地震。
2.9 Spring Boot 4.0 vs 3.x 差异对比表
汇总成一张表：
一句话总结：Spring Boot 4.0 不再是一个 Web 框架，而是云原生 Java 应用的完整基础设施。
三、Spring AI 2.0 vs 1.0：从能用到好用
这是第二个重头戏。
先说时间线：
2025 年：Spring AI 1.0 GA 发布
2026 年 6 月 12 日：Spring AI 2.0.0 GA 正式发布
很多人一听到「2.0」就以为是 1.x 是过渡版本、2.0 才是真正能用的。这对 Spring AI 不太公平。Spring AI 1.0 已经把 Java AI 应用的基础骨架搭出来了——能接 Chat Model、做 Embedding、连 Vector Store、写 RAG、用 ChatClient、挂 Advisors、做 Tool Calling、拿 Structured Outputs、接 Observability、写 ETL Pipeline。但 1.x 真正的问题是：很多能力有了，但还在快速演进期，工程化不够。
3.1 1.x 时代：单体核心之痛
Spring AI 1.x 的核心包是 spring-ai-core，它包含了所有核心接口和通用实现。这种「大而全」的设计在项目早期是合理的，但 AI 模型生态爆发后，问题暴露了：
依赖膨胀：你只用 OpenAI 的 Chat 能力，但
spring-ai-core会把所有模型相关的依赖都拉进来工具循环埋在私有实现里：想自定义工具调用的中间过程，发现工具循环被「埋」在
ChatModel的私有实现里，根本插不上手多模型路由差：想做多模型路由，发现自动配置只创建了一个
ChatModelBean@AiFunction限制多：不支持 POJO 参数、不支持可空值、不支持嵌套对象
3.2 2.0 模块化重构
Spring AI 2.0 做了一次彻底的架构重构。核心变化是把 spring-ai-core 拆了：
收益：现在你只用 OpenAI 的 Chat 能力，就只引 spring-ai-model-openai，不会再被一堆无关依赖污染。
3.3 ChatClient 统一抽象
1.x 时代，调用大模型是这样写的：
2.0 时代：
对比：1.x 用 ChatModel.call()，是底层 API；2.0 用 ChatClient，Fluent 风格链式调用，配置 system / user / tool / advisor 都在一条链上。ChatModel 在 2.0 里退到二线，作为底层构建块存在。
3.4 @Tool 注解：Function Calling 革命
1.x 的工具调用：
问题：不支持 POJO 参数、不支持可空值、不支持嵌套对象。
2.0 的工具调用：
革命性变化：可以直接把一个 Java 业务方法注册为 AI 可调用工具。AI 调用这个工具时，Spring AI 自动处理参数序列化、Schema 生成、JSON 解析。AI 指令和业务逻辑之间的「胶水代码」基本消失了。
3.5 Advisors 机制：横切关注点的统一管理
1.x 时代 Advisors 概念存在但生态薄弱，没有官方开箱即用的组件。2.0 提供了完整的 Advisor 体系：
这些 Advisor 可以像 Servlet Filter 一样灵活组合：
ChatClient client = chatClient.builder()
.defaultAdvisors(
new MessageChatMemoryAdvisor(chatMemory),
new QuestionAnswerAdvisor(vectorStore),
new SafeGuardAdvisor(sensitiveWords)
).build();
3.6 MCP 协议原生支持
MCP（Model Context Protocol）是 Anthropic 提出的 AI 客户端-服务端通信标准协议。Spring AI 2.0 内建了原生支持：
<dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-starter-mcp-client</artifactId> </dependency>
这一步的意义在于——你的 AI 应用不再是一个孤立的聊天窗口，而是 MCP 生态的一部分，可以和其他 MCP server 互通。
3.7 全链路可观测
1.x 时代的可观测性是「半成品」，要自己写一堆埋点。2.0 集成了 Micrometer Metrics + OpenTelemetry：
Token 消耗统计（按模型 / 按用户 / 按业务）
调用延迟监控
链路追踪（一次 AI 调用的完整链路）
Prompt 命中率
接上 Prometheus + Grafana 就能可视化监控。
3.8 OpenAI 兼容协议：零代码切换国产模型
这是 Spring AI 最香的设计之一。
业务代码完全不用改。DeepSeek、通义千问、智谱 GLM、Kimi、月之暗面都提供了 OpenAI 兼容接口，Spring AI 直接通过 spring-ai-openai 模块接入。
3.9 Structured Output：让 AI 返回直接映射到实体
1.x 时代，让 AI 返回结构化数据要自己解析 JSON，容易出错。2.0 的 Structured Output：
// 让 AI 直接返回映射到实体的对象 NoteAiOrganized result = chatClient.prompt() .user("把这段笔记整理成结构化数据：" + noteContent) .call() .entity(NoteAiOrganized.class);
Spring AI 自动处理 JSON 解析、字段映射、类型转换。在「笔记 AI 整理」这个功能里，我直接让 AI 把杂乱的笔记内容输出成 NoteAiOrganized 实体，存进数据库，全程零胶水代码。
3.10 Spring AI 2.0 vs 1.0 差异对比表
一句话总结：Spring AI 1.0 让 Java 项目能接上大模型，Spring AI 2.0 让 Java AI 应用能像真正的企业系统那样长期维护。
四、为什么是 pig 框架
技术栈对齐了，回到脚手架选型。我先讲一下选 pig 的几个硬性理由。
4.1 内置 OAuth2 / RBAC / 字典 / 菜单 / 代码生成器
pig 自带的功能清单：
OAuth2 认证服务器：基于 Spring Authorization Server，token 续签、客户端管理、scope 控制全套
RBAC 权限模型：用户 / 角色 / 菜单 / 按钮 / 数据权限，五层粒度
字典管理：男 / 女、启用 / 禁用、订单状态，全部字典化
菜单管理：动态菜单、菜单缓存、按钮权限
代码生成器：根据表结构一键生成 Entity / Mapper / Service / Controller / Vue 列表页 / 表单页
任务调度：基于 Quartz 的分布式定时任务
日志审计：操作日志、登录日志、API 调用日志
这些东西自己写，保守估计要两周起步。pig 一个 starter 引进来，直接能用。
4.2 单体模式 vs 微服务模式的取舍
pig 支持两种部署模式：
我的选择是单体模式。理由：个人项目没必要搞微服务那套复杂度；单体调试方便，一个进程看所有日志；部署简单，一个 jar 丢服务器就完事。但是！单体模式下 pig 的模块化设计依然保留——认证、权限、字典、业务代码各自独立模块，未来要拆微服务也容易。
4.3 基于 Spring Boot 4.0：版本对齐
这是选 pig 的决定性理由之一。pig 4.0 版本（我用的版本）基于：
版本完全对齐 Spring Boot 4 生态。如果选别的脚手架（比如 RuoYi-Vue-Plus 还在 Spring Boot 3.x），就得等它升完 4.0 才能用上 Spring AI 2.0，而 Spring AI 2.0 要求 Spring Boot 3.4+——降级 pig 4.0 会撕裂依赖链。
4.4 开源直接集成 Spring AI 2.0
pig 是开源项目，源码全开。这意味着我可以直接把 Spring AI 2.0 集成进 pig 系统，不需要改 pig 的核心代码：
<!-- pig 项目的 pom.xml 里直接加 Spring AI 2.0 依赖 --> <dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-starter-model-openai</artifactId> <version>2.0.0</version> </dependency>
Spring AI 2.0 基于 Spring Boot 4.0 + Spring Framework 7.0，跟 pig 4.0 的依赖链完全一致，自动装配无缝整合。
4.5 为什么不用 LangChain4j
LangChain4j 也是 Java 生态的 AI 框架，社区也很活跃。我对比了一下：
选 Spring AI 2.0 的核心理由：Spring 生态原生优先。我的项目用 pig（基于 Spring）、用 Spring Security OAuth2、用 Spring Data JPA，所有这些都是 Spring 一套。Spring AI 跟它们的整合是最顺的，不需要任何胶水代码。
4.6 pig 的代价
讲好处也要讲代价：
开源版功能精简：支付、工作流、报表等高级组件在商业版 PIGX，开源版只有基础 RBAC + 代码生成器
代码风格偏激进：用了一些较新的 Spring 写法，新手可能不适应
pig 4.0 还在快速迭代：偶尔有 breaking change，得盯着版本号
依赖链长：Spring Boot 4 + Spring Cloud 2025 + Spring Cloud Alibaba，版本对齐要细心
但这些代价我都认了。比起自己从零写一套 OAuth2 + RBAC，这些坑都是小坑。
五、前端选型：UniApp 的多端真相
讲完后端讲前端。
5.1 UniApp：「一套代码多端运行」真相
UniApp 的口号是「一套代码，多端运行」。听起来很美，实际用起来有几个真相：
真相一：多端是真的，但各端有差异
UniApp 编译到不同端：App（iOS / Android）原生渲染；H5 是 WebView 渲染；小程序（微信 / 支付宝 / 字节）是各家小程序运行时。每个端的样式、API、组件行为都有差异，要做兼容处理。
真相二：跨端是有成本的
同一套代码跑多端，意味着你要避开每个端的特殊限制。比如微信小程序不支持某些 CSS 特性、H5 和 App 的导航栏行为不同。
真相三：但依然是性价比最高的选择
如果你的目标是「同时覆盖 App + 小程序 + H5」，UniApp 依然是最快的方式。原生写三套代码，工作量是 3 倍；UniApp 一套代码三端跑，工作量是 1.x 倍（多出来的 0.x 是兼容处理）。
5.2 uview-plus 组件库的取舍
UniApp 的组件库选择不多，主流的几个：
选了 uview-plus。理由：跨端兼容好，App / H5 / 小程序都能跑；组件全，覆盖 90% 的常见场景；TypeScript 类型定义完整，IDE 提示友好。
5.3 为什么管理后台用 Element Plus 而不是 Ant Design Vue
App 端用 UniApp + uview-plus，但管理后台（server-ui）是另一回事——后台是 PC 端，不需要跨端。主流的 Vue3 后台组件库：
最后选了 Element Plus。理由其实就一条：pig 框架自带的后台就是 Element Plus 写的。如果换 Ant Design Vue，等于把 pig 的整套 UI 重写一遍，得不偿失。
而且 Element Plus 在 pig 项目里已经验证过——菜单、表单、表格、权限按钮、字典组件全都跟 pig 的 RBAC 体系深度绑定。换库等于把这些绑定全打断。
5.4 一张表说清三端组件库
六、实测依赖版本表（对齐 pig 4.0）
下面这张表是我实测过的依赖版本，全部对齐 pig 4.0 的版本节奏。每一项都跑过 mvn dependency:tree 验证，没有冲突。
6.1 后端依赖（server）
注意：Spring AI 2.0.0 是关键版本。它强制要求 Spring Boot 3.4+，而 pig 4.0 跑在 Boot 4.0 上——依赖链天然对齐，无需 hack。
6.2 前端 App 依赖（uniapp-ui）
6.3 管理后台依赖（server-ui）
七、一张图说清三端依赖关系
上面是文字，下面这张图是我画了三遍才理清的依赖拓扑。核心逻辑：所有版本节奏由 pig 4.0 主导，向下传递约束。
pig 4.0 框架（顶层主导）
│
▼ 强制约束
Spring Boot 4.0.7Spring Cloud 2025.1.2Spring Cloud Alibaba 2025.1.0.0
│
▼ 允许接入
Spring AI 2.0.0MyBatis Plus 3.5.12JDK 21
前端 App（uniapp-ui）+管理后台（server-ui）
│
▼ 各自独立，通过 HTTP API 通信
Vue 3.5Vite 5UniApp + uview-plusElement Plus 2.13
看这张图有几个关键点要记住：
后端版本约束是「刚性」的：pig 4.0 → Spring Boot 4.0 → Spring AI 2.0，一环扣一环，任何一个不能降级
前端版本约束是「柔性」的：前后端通过 HTTP API 通信，前端版本可以独立升级（但建议保持 Vue 3.5 统一）
Spring AI 2.0 是受益方，不是驱动方：它「正好兼容」Boot 4，而不是「强制要求」Boot 4。所以集成 Spring AI 没有给 pig 添麻烦
JDK 21 是甜点，不是门槛：Boot 4 最低要求 JDK 17，但用 17 会丢掉虚拟线程完整优化，所以选 21
八、选型的代价
讲完了好处和版本，必须坦白代价。没有任何一个选型是免费的。
8.1 学习曲线陡
这套技术栈的学习成本，老实说不低：
Spring Boot 4.0：要熟悉 GraalVM AOT 的限制（反射要配置）、BeanRegistrar 新写法
Spring AI 2.0：ChatClient / Advisors / @Tool 三套概念，要花一周理解
pig 框架：OAuth2 + RBAC + 字典 + 代码生成器，配置项多，要花几天摸清
UniApp：跨端兼容处理，每个端都有自己的坑（小程序尤甚）
总学习成本大概是「纯 Spring Boot 3 + 单端 Vue」方案的 1.5-2 倍。但这是一次性投入，做完一个项目就回本了。
8.2 依赖链复杂度
pig 4.0 拉满依赖链后，mvn dependency:tree 输出大概 2000 多行。实际遇到的几个坑：
Spring Cloud Alibaba 版本滞后：阿里系的 Nacos 客户端总是落后 Spring Cloud 半个版本，偶尔要等几周
第三方库的 Boot 4 适配：一些冷门库还没适配 Boot 4，要么换库，要么自己写适配层
Spring AI 2.0 还在演进：API 偶尔有调整，建议锁定 patch 版本，别盲目追新
8.3 Spring AI 2.0 的成熟度风险
这是必须说清楚的——Spring AI 2.0 不是「绝对成熟」。
我的态度是：这些风险可控。Spring AI 2.0 已经 GA（General Availability），核心 API 稳定，剩下的是工具链和文档的完善问题。如果连这点风险都不愿意承担，那就别上 AI 了。
8.4 pig 框架的绑定风险
选了 pig，等于把项目跟 pig 绑定。如果哪天 pig 不维护了，迁移成本是多少？
我的评估是：迁移成本中等。原因：
pig 是开源项目，源码全开，最坏情况可以自己 fork 维护
业务代码跟 pig 框架是「依赖」关系，不是「耦合」关系——业务 Service / Controller 是标准 Spring 写法，换框架不影响
真正绑死的是 RBAC / 菜单 / 字典这些基础设施，迁移需要重新实现，但工作量可预估（约 2-3 周）
九、写在最后
这一篇写得最长，因为选型是项目能不能活下来的第一关。回过头看，几个关键决定：
上 pig 4.0：换来 OAuth2 + RBAC + 代码生成器，省两周
上 Spring Boot 4.0：换来 GraalVM / 虚拟线程 / 可观测性，未来 3 年不过时
上 Spring AI 2.0：换来 ChatClient + @Tool + Advisors，AI 接入零摩擦
App 端用 UniApp：一套代码三端跑，省 1.5 倍人力
后台用 Element Plus：跟 pig 默认搭配，零适配
如果让我用一句话总结这套技术栈：它不是最先进的，但它是最平衡的。
最先进的方案可能是 Rust + SolidJS + 自研 AI 网关，但那不是独立开发者能驾驭的。我需要的是「能在 3 个月内独立完成、能上线、能维护」的方案，pig + UniApp + Element Plus + Spring AI 恰好命中这个甜点。
选型定了，下一关是真正开始改 pig 框架。第 6 篇会写「fork pig 之后我改了哪些东西」——不夸张地说，改 pig 比选 pig 难一倍。
下一篇预告
第 06 篇：《后端初始化：fork pig 框架后我改了什么》——从 fork 仓库到第一个能跑的 Hello World，记录我改动的每一行配置、删掉的每一个模块、加上的每一个自定义扩展。包括：删 PigCodeGenModule / 改 OAuth2 配置 / 接入 Spring AI / 配置文件分层 / 数据库初始化脚本。
