Java · 03 框架与生态

语言是 Java；批量交付业务默认靠 Spring 体系。这里谈「用什么干活」，不背组件清单。

1. Spring 解决了什么

在 Spring 之前，企业 Java 容易变成：自己拼工厂、自己管依赖、横切逻辑到处复制。

核心价值就两句：

1. IoC / DI：对象怎么创建、怎么装配，交给容器
2. AOP：日志、事务、鉴权等横切逻辑统一处理

没有这两点，就谈不上「Java 企业开发现代默认路径」。

IoC / DI 怎么看

• 本质是 解耦：业务类不自己 new 依赖
• 好处：可测、可替换、生命周期统一
• 代价：「魔法」变多——出问题要会看代理、循环依赖、注入失败原因

判断： 中小项目注解注入足够；过度玩 Bean 后置处理奇技淫巧，收益低。

---

2. Spring Boot：我真正依赖的点

Boot 不是新框架，是 约定 + 自动配置 + Starter，把「能跑起来」的成本压下去。

能力	为何重要
配置外置、多环境	dev/test/prod 不改代码
内嵌容器	部署成 jar 即可，运维路径简单
Starter	依赖版本收敛，少踩兼容坑
Actuator / 默认日志 / 连接池	工程默认项，不必从零拼

判断： 新业务默认 Boot；纠结「纯 Spring XML」没有意义。懂 排除/覆盖自动配置，比背 starter 列表重要。

---

3. Web（MVC）与接口层

• @RestController + 明确 DTO；校验（Bean Validation）放边界
• 统一错误码与异常处理（@ControllerAdvice），前端/调用方才好对接
• Controller 薄：鉴权通过后进 Service；别在接口方法里堆事务与远程调用
• 幂等、限流、签名：按开放程度加，开放 API 必做

接口设计原则：字段稳定、错误可机读、超时与重试语义说清楚。

---

4. 持久化与数据访问

选型	我的直觉
MyBatis / MyBatis-Plus	默认：SQL 可控，适合复杂报表与既有库表
JPA / Hibernate	团队已有或 CRUD 极标准时可用；复杂 SQL 仍易绕回原生
动态数据源 / 读写分离	有真实读写压力与运维能力再上

N+1、大结果集、无索引条件——框架救不了，要在 SQL 与表设计上解决。
相关：后端问题 · 数据库

---

5. 事务（最值钱的一块理解）

必须能讲清：

• @Transactional 靠代理；同类自调用常失效
• 异常被 catch 吃掉、方法非 public，都会让人误以为「加了注解就安全」
• 传播行为先精通 REQUIRED / REQUIRES_NEW，再扩展其它

判断：

• 事务保证「该在一个库事务里的事」
• 跨服务靠状态机 / 补偿 / 本地消息表，不迷信分布式事务框架当银弹
• 长事务里不要调慢远程；先落库状态再异步

相关：后端问题 · 分布式

---

6. 缓存、任务、消息（生态常用件）

能力	常见选择	原则
缓存	Redis	先定更新/失效策略，再谈分布式锁
本地缓存	Caffeine 等	单机热点；注意与 Redis 双层一致性
定时任务	@Scheduled → XXL-JOB	多实例要抢锁或用分布式调度
异步解耦	线程池 → MQ	有削峰/最终一致需求再上 MQ

相关：Redis 面试 · 后端问题 · MQ

---

7. Spring Cloud：用过 ≠ 该用

组件方向	何时才值得
注册/配置（Nacos 等）	已经多服务、要集中配置与发现
Feign / Gateway	已有拆分，需要声明式调用与统一入口
限流熔断	有真实流量与依赖脆弱性

拆服务解决的是 组织与独立演进，不是性能灵丹。
中小团队：模块化单体 + 清晰边界 往往比一上来 Cloud 全家桶更稳。

我在悟空等项目里用过注册、配置、Feign、任务与网关限流——那是 已有架构约束下的维护与交付，不是每个新项目的默认起手式。

---

8. 一张表：我会怎么选

场景	选择
业务 API	Spring Boot + MyBatis-Plus（或团队既有 ORM）
缓存	Redis + 明确策略
任务	本地异步 / XXL-JOB / 队列，按可靠性升
AI 编排	Java 管状态与配额；Python 管模型胶水
拆服务	默认不拆；Cloud 组件仅在已有约束时用

下一篇：04 工程实践