定位
Quarkus 是 Red Hat 主导的 Java 框架，为云原生和 GraalVM 设计。核心能力有两个：构建期依赖注入（启动快）和原生镜像（启动几十毫秒、内存几十 MB）。
它不是 Spring Boot 的替代品，是补充——在冷启动敏感的场景里，它明显更合适。
安装与创建
# 用 CLI
curl -Ls https://sh.jbang.dev | bash -s - trust add https://repo1.maven.org
quarkus create app com.example:demo
1. 或用 Maven 插件
mvn io.quarkus.platform:quarkus-maven-plugin:create
-DprojectGroupId=com.example -DprojectArtifactId=demo
cd demo
./mvnw quarkus:dev # 开发模式，热重载
最小示例
// src/main/java/com/example/GreetingResource.java
package com.example;
import jakarta.ws.rs.*;
import jakarta.ws.rs.core.MediaType;
@Path("/hello")
@Produces(MediaType.APPLICATION_JSON)
public class GreetingResource {
@GET
@Path("/{name}")
public Greeting hello(@PathParam("name") String name) {
return new Greeting("Hello, " + name);
}
public record Greeting(String message) {}
}
没有 main 方法，没有配置类。 启动后 /hello/world 直接可用。
核心概念
1. 构建期初始化
Spring Boot 在运行时扫描注解、构建 Bean 图。Quarkus 在构建时就做完这些，生成字节码。
| Spring Boot | Quarkus | |
|---|---|---|
| Bean 图构建 | 运行时反射 | 构建时生成 |
| 启动时间 | 5-15 秒 | 0.5-2 秒 |
| 内存（空项目） | 200-300 MB | 60-100 MB |
| 首次构建 | 快 | 慢一些 |
代价：构建期做的事多，增量编译比 Spring 慢。热重载（quarkus:dev）做得不错，但全量构建要等。
2. 原生镜像
./mvnw package -Pnative
./target/demo-runner
1. 启动 ~0.05s，内存 ~40MB
这是 Quarkus 最大的卖点。原生镜像把 JVM 和类加载过程都去掉了，直接编译成机器码。
代价： – 构建要 3-10 分钟，需要 GraalVM 环境和大量内存 – 反射、动态代理、运行时代码生成默认不可用，需要额外配置（Quarkus 内置了很多框架的适配） – 调试困难（没有 JVM 工具链）
3. 扩展（Extension）机制
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-rest-jackson</artifactId>
</dependency>
Quarkus 的扩展不只是加依赖，还包含构建期处理逻辑（为原生镜像做适配）。所以在 Quarkus 里要选它生态内的扩展，而不是随便引 Spring 的库。
常见坑
① 用 Spring 的思维写 Quarkus
Quarkus 不用 Spring 的注解（@Service、@Autowired），用 CDI（@ApplicationScoped、@Inject）。混着用会失效。
② 原生镜像下第三方库不可用
用了反射的库（很多老库）在原生镜像里会失败。要么找 Quarkus 官方适配，要么放弃原生模式。
③ 构建期和运行期的边界
Quarkus 里很多配置在构建期就固化了。改配置要重新构建，不能像 Spring 那样改配置文件重启。
这一点在容器化部署时要特别注意。
什么时候选它
- Serverless / FaaS：冷启动从秒级降到几十毫秒，这是质变
- 容器密度要求高：一台机器想跑几十个服务，内存省下来很可观
- Kubernetes 上大量小服务：启动快意味着扩容响应快
- 开发体验：
quarkus:dev的热重载确实好用
不选它的场景： – 常规企业应用（Spring Boot 生态和人才储备优势太大） – 需要大量第三方库（Quarkus 适配不全） – 团队没有 GraalVM 经验还硬上原生镜像
一个冷静的判断
Quarkus 的「启动快」在大多数业务场景里没有价值。
常驻服务一天重启一次，启动 8 秒还是 0.5 秒，用户感知不到。真正有价值的只有三种情况：
- Serverless：每次请求都可能冷启动
- 弹性伸缩：扩容时新实例要秒级可用
- 开发环境：频繁重启时的等待时间（这一条对开发者体验影响很大）
如果不符合上面任何一条，选 Quarkus 的理由就只剩「内存省」。那要先算算：省下的内存值不值多出来的学习、构建时间和生态适配成本。
大部分项目的正确答案是 Spring Boot。 生态和人才的差距，比性能差距重要得多。