@Testcontainers启动Redis容器可行但属集成测试，非单元测试；应明确验证目标——测交互逻辑用Mock，测连通性才用容器，且需静态声明、手动start、配合@DynamicPropertySource正确注入地址。
直接用 @Testcontainers 启动 Redis 容器是可行的，但 Spring Boot 单元测试里混用它容易翻车——因为“单元测试”本不该依赖真实中间件，而 Testcontainers 本质是集成测试工具。真要跑，得先明确：你测的是 Redis 交互逻辑（比如序列化、连接池行为），还是单纯想验证业务代码能连上？前者建议 Mock，后者才该上容器。
为什么 @SpringBootTest + Testcontainers 不算单元测试
Spring Boot 的单元测试应聚焦单个类/方法逻辑，不加载完整上下文。一旦加了 @SpringBootTest，就启动了整个 ApplicationContext，还拉起 Docker 容器，执行时间从毫秒级跳到秒级，违背单元测试快、隔离、可重复的原则。常见误用是：为测一个 RedisTemplate 调用，硬套 @SpringBootTest，结果 CI 测试套件越来越慢。
- 真正需要容器的场景，属于集成测试层，应单独归类，命名如
RedisIntegrationTest，而非UserServiceTest - 如果只是验证缓存逻辑是否触发，用
@MockBean RedisTemplate更轻量、更可控 -
@DataJpaTest或@WebMvcTest这类切片注解，压根不兼容 Testcontainers —— 它们会主动排除 Redis 自动配置，导致容器启了也连不上
GenericContainer 启动 Redis 容器的关键参数
不用 RedisContainer（它已被标记为 deprecated），改用 GenericContainer 更稳定，尤其在国内环境：
- 镜像必须显式指定国内可用版本，例如
registry.cn-hangzhou.aliyuncs.com/library/redis:7.2-alpine，避免拉取redis:latest卡死 - 禁用 AOF：通过
withCommand("redis-server", "--appendonly", "no")，否则容器可能因挂载卷权限失败而退出 - 端口暴露不能只靠
withExposedPorts(6379)，必须配合waitingFor(Wait.forRedis())（需引入testcontainers-module-redis）——只等端口通，Redis 进程未必 ready - 务必声明为
static字段，并在@BeforeAll中手动start()，否则@DynamicPropertySource取不到 IP 和映射端口
@DynamicPropertySource 注入 Redis 地址的坑
这个注解常在容器还没完全启动时就执行，导致注入的仍是 localhost 或空值：
- 错误写法：
@DynamicPropertySource(staticMethod = "redisUri")，其中redisUri()直接调用未初始化的容器实例 →NullPointerException - 正确写法：用 lambda 引用已启动的静态容器，例如
dynamicProperties.bind("spring.redis.host", () -> REDIS.getContainerIpAddress()) - 别忘了端口要用
REDIS.getMappedPort(6379)，不是默认 6379 —— Docker 随机映射后，宿主机访问必须用映射端口 - Spring Boot 3.1+ 可尝试
@ServiceConnection，但它对 Redis 支持有限，仍需手动注册RedisConnectionFactoryBean
替代方案：Mockito + RedisTemplate 模拟足够覆盖多数场景
90% 的缓存逻辑测试，其实不需要真实 Redis。比如验证 key 生成规则、过期时间设置、JSON 序列化异常处理：
- 用
@MockBean RedisTemplate替代容器，再 mockopsForValue().set(...)行为 - 若需验证序列化器行为（比如
StringRedisSerializervsJackson2JsonRedisSerializer），直接 new 一个RedisTemplate实例，set 对应 serializer，不依赖 Spring 上下文 - 对连接异常的测试，mock
RedisConnectionException抛出即可，比等容器崩掉更稳定
最易被忽略的一点：Testcontainers 启动的容器生命周期绑定在 JVM 进程上，但 JUnit 5 的 @TestInstance(Lifecycle.PER_CLASS) 和静态容器字段必须严格匹配，否则多个测试类之间可能复用失败的容器状态。别图省事把容器声明成非 static，也别在 @AfterEach 里 stop 它——那是 Testcontainers 自己该干的事。
