这篇写 Java 后端测试里一个很常见的坑：本地 H2 单测全绿，CI 或预发一连 PostgreSQL/MySQL 就翻车。字段默认值、SQL 方言、唯一约束、事务隔离、索引行为，全都可能和你想的不一样。Testcontainers 的价值不是“更时髦”，而是让集成测试尽早面对真实依赖。
本文适用于 Java 17/21、Spring Boot 3.x、JUnit 5、Testcontainers。资料只用于核对事实：Spring Boot 支持 Testcontainers service connection，Testcontainers 提供 JUnit Jupiter 集成。正文按工程落地写，不复述官方文档。
业务场景：Repository 测试全绿，线上 SQL 却报错
订单服务有一批 Repository 测试，使用 H2 跑得很快。一次新增 JSON 字段和部分索引后，本地测试没问题，预发连 PostgreSQL 直接报 SQL 语法错误。问题不在业务代码，而在测试环境替你撒了一个温柔的谎：它根本不是生产数据库。
我不是说 H2 不能用。纯粹 DAO 映射、简单 CRUD、非常轻量的单元测试可以继续用。但只要你验证的是数据库方言、迁移脚本、约束、索引、事务行为，就应该尽量用真实容器。
问题复现：CI 偶发失败通常不是偶然
Testcontainers 刚接入时，团队最容易遇到三类问题：容器启动慢，测试数据互相污染，Spring Context 和容器生命周期混在一起导致偶发失败。表面看像 CI 不稳定，本质通常是测试边界没设计好。
比如 A 测试插入了固定手机号，B 测试也插入同一个手机号；本地按顺序跑没事，CI 并行后就撞唯一索引。真实数据库帮你暴露了问题，但测试代码必须负责隔离和清理。
踩坑原因：只把容器跑起来还不够
很多文章停在“启动一个 PostgreSQLContainer”，但生产项目真正麻烦的是生命周期。容器是每个类一个，还是整个测试套件共用？数据库 schema 谁初始化？测试数据谁清？CI 没有 Docker 缓存怎么办？这些问题不回答，测试会越来越慢，最后被团队关掉。
我的原则是：少数核心集成测试用真实容器，覆盖最容易和生产不一致的路径；普通业务分支仍然用单元测试和 slice test 保持速度。不要把所有测试都塞进容器，也不要完全不用容器。
代码案例：Spring Boot 3 的 ServiceConnection 很香
Spring Boot 3.1 之后，@ServiceConnection 可以减少很多手写 JDBC URL 的样板代码。下面这个 Repository 测试会启动 PostgreSQL 容器，并把连接信息注入 Spring 测试上下文。
@DataJpaTest
@Testcontainers
class OrderRepositoryTest {
@Container
@ServiceConnection
static PostgreSQLContainer postgres =
new PostgreSQLContainer<>("postgres:16-alpine");
@Autowired OrderRepository repository;
@Test
void shouldRejectDuplicateOrderNo() {
repository.save(new OrderEntity("NO-1001"));
assertThatThrownBy(() -> repository.saveAndFlush(new OrderEntity("NO-1001")))
.isInstanceOf(DataIntegrityViolationException.class);
}
}
如果项目还没升级到支持 @ServiceConnection 的版本，可以用 @DynamicPropertySource 手动注入 spring.datasource.url、用户名和密码。关键是不要把容器端口写死，Testcontainers 会映射动态端口。
诊断步骤：CI 偶发失败我这样查
第一，看容器日志。 数据库是否真的启动完成？迁移脚本是否成功？不要只看 JUnit 失败断言。
第二，看测试数据隔离。 固定手机号、固定订单号、固定用户名这类数据最容易在并行测试里互相污染。
第三，看 Spring Context 缓存。 频繁使用不同配置会让测试上下文重复创建，测试会越来越慢。
第四，看容器生命周期。 静态容器、每类容器、单例容器各有取舍。速度和隔离要根据模块风险决定。
第五，看 CI 环境。 Docker 权限、镜像拉取速度、磁盘空间、并行度，都会影响 Testcontainers 稳定性。
上线检查：让集成测试成为门禁
- 关键数据库行为使用真实数据库容器覆盖，不再依赖 H2 猜测。
- 迁移脚本和生产一致，测试启动时自动执行。
- 测试数据可重复、可清理，不依赖执行顺序。
- CI 缓存常用镜像，失败时保留容器日志和应用日志。
- 把慢测试分组，普通 PR 跑核心集合，夜间跑完整集合。
我的经验总结
Testcontainers 不是为了替代所有单元测试，而是补上“真实依赖行为”这块短板。Java 后端最怕测试环境太假，越早发现方言、约束、迁移和事务问题，线上越少背锅。
我的建议是小步接入：先挑一个最容易翻车的 Repository 或消息消费链路，用 Testcontainers 跑稳；再沉淀基类、数据工厂和 CI 策略。测试不是越多越好，而是每一层都知道自己在证明什么。
