技术栈选型

这一课你将能做到

1. 用结构化框架评估技术选型：从业务约束到团队能力，给出可辩护的结论
2. 说清楚 Java/Spring、Go、Node.js 各自的甜蜜点，以及本站为什么是 Spring Boot
3. 解释响应式编程解决的真正问题，并判断本站是否值得引入 WebFlux

为什么要学

「用什么技术栈」是每个新项目的第一道架构决策，也是最难以回头的决策之一。选错了，三个月后全员吐槽、一年后推倒重来。技术选型比拼的不是谁懂得多，而是谁能把「合适」论证清楚。

人话：选技术栈像选交通工具。法拉利（Go 极致性能）跑得快但维护贵、修车师傅难找；丰田（Java/Spring）不是最快，但皮实、配件遍地、会修的人多。你要先想清楚是跑赛道还是跑滴滴。

先建立图像

主流后端栈的定位地图：

性能 →
高 │  Go/Rust          C++
   │   (并发/云原生)      (极致性能/系统级)
   │
中 │  Java/Kotlin       Node.js
   │  (企业级/生态最全)   (IO密集/前后端统一)
   │
低 │  Python            Ruby
   │  (AI/脚本/胶水)     (快速原型)
   └─────────────────────────────
     生态成熟度低 ←———→ 生态成熟度高

跟着做

步骤 1：结构化选型框架（七问法）

为本站选后端栈，依次回答：

问题	本站的答案	指向
1. 团队熟悉什么？	3 人都是 Java 背景	Java/Kotlin
2. 业务类型？	CRUD 为主 + 事务 + 复杂查询	成熟 ORM 生态
3. 性能要求？	万级日活，无极端并发	不需要 Go/Rust
4. 招人难度？	三线城市远程团队	Java 简历最多
5. 生态依赖？	需要支付、OSS、短信 SDK	阿里云 Java SDK 最全
6. 长期维护？	计划维护 5 年以上	选常青树不选新锐
7. 未来演进？	可能拆微服务	Spring Cloud 成熟

结论：Spring Boot 3 + Java 21。每条理由都可追溯。

步骤 2：Spring vs Go 的真实对比

维度          Spring Boot                Go
──────────────────────────────────────────────────
启动速度      3-10s（可用 CRaC 优化）      毫秒级
内存占用      300MB+                     30MB+
并发模型      线程池（虚拟线程大幅改善）     goroutine 原生轻量
开发效率      注解驱动，样板代码多但框架全    显式代码，简洁但轮子少
企业功能      事务/安全/批处理开箱即用       需要自行组装
适用场景      业务复杂的企业应用            基础设施/高并发中间件

Java 21 虚拟线程缩小了差距：

// 以前：线程池 200 个线程是瓶颈
// 现在：虚拟线程百万级，写法和同步代码一样
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    executor.submit(() -> {
        // 阻塞 IO 不再浪费 OS 线程
        return courseMapper.findById(id);
    });
}

步骤 3：响应式编程的边界判断

// WebFlux 写法：全部链路非阻塞
@GetMapping("/courses/{id}")
public Mono<CourseDTO> get(@PathVariable long id) {
    return courseRepo.findById(id)          // R2DBC 非阻塞驱动
        .flatMap(c -> reviewRepo.countByCourse(id)
            .map(count -> new CourseDTO(c, count)));
}