4. 过期时间配置方式：代码硬编码、配置文件、配置中心与环境变量

在集成测试中，缓存过期时间的配置来源直接影响测试用例的设计与断言策略。不同配置方式决定了测试环境如何获取过期时间值、如何覆盖默认值、以及如何在回归冒烟中验证配置的正确性。本章详细分析四种主流配置方式的技术特点、测试关注点与验证方法。

4.1 四种配置方式对比总览

4.2 代码硬编码方式

硬编码是将过期时间直接写在 Java 代码或注解中，例如 @Cacheable(value = "users", expire = 300) 或 RedisCacheManager.setDefaultExpiration(600)。这种方式在回归冒烟测试中风险最高，因为测试环境无法在不修改代码的前提下改变过期时间。

// 硬编码示例：直接在缓存配置类中定义过期时间
@Configuration
public class CacheConfig {
    @Bean
    public RedisCacheManager cacheManager(RedisConnectionFactory factory) {
        RedisCacheConfiguration config = RedisCacheConfiguration.defaultCacheConfig()
            .entryTtl(Duration.ofSeconds(300)); // 硬编码 300 秒
        return RedisCacheManager.builder(factory)
            .cacheDefaults(config)
            .build();
    }
}

4.3 配置文件方式（YAML / Properties）

配置文件是 Spring Boot 生态中最常见的配置方式。过期时间通过 application.yml 或 application.properties 中的自定义属性注入，支持多环境文件（dev / test / prod）隔离。

# application.yml 示例
cache:
  redis:
    default-ttl: 600        # 单位：秒
    user-cache-ttl: 300
    product-cache-ttl: 900

// Java 配置类读取配置文件
@Configuration
@ConfigurationProperties(prefix = "cache.redis")
public class RedisCacheProperties {
    private long defaultTtl = 600;
    private long userCacheTtl = 300;
    private long productCacheTtl = 900;
    // getter / setter 省略
}

集成测试中，可以通过 @TestPropertySource 或 @DynamicPropertySource 覆盖配置文件中的过期时间，验证缓存行为是否符合预期。

@SpringBootTest
@TestPropertySource(properties = {
    "cache.redis.default-ttl=10",   // 测试环境覆盖为 10 秒
    "cache.redis.user-cache-ttl=5"
})
public class CacheExpiryTest {
    @Test
    public void testShortTtlEviction() {
        // 验证 5 秒后用户缓存自动失效
    }
}

4.4 配置中心方式（Apollo / Nacos）

配置中心支持运行时动态修改过期时间，无需重启应用。集成测试需要额外关注热更新场景下的缓存一致性。

// Nacos 配置示例（Data ID: cache-config.yaml）
cache:
  redis:
    default-ttl: 600
    user-cache-ttl: ${USER_CACHE_TTL:300}  # 支持占位符回退

// Apollo 监听配置变更
@ApolloConfigChangeListener("cache-config")
public void onChange(ConfigChangeEvent changeEvent) {
    if (changeEvent.isChanged("cache.redis.user-cache-ttl")) {
        String newTtl = changeEvent.getChange("cache.redis.user-cache-ttl").getNewValue();
        // 触发缓存管理器刷新
        refreshCacheManager(Long.parseLong(newTtl));
    }
}

4.5 环境变量方式

环境变量是容器化部署（Docker / Kubernetes）和 CI/CD 流水线中最推荐的配置方式。它天然支持环境隔离，且不污染代码仓库。

# Docker 运行示例
docker run -e CACHE_DEFAULT_TTL=120 -e USER_CACHE_TTL=60 my-app:latest

// Spring Boot 自动读取环境变量
@Value("${CACHE_DEFAULT_TTL:600}")
private long defaultTtl;

@Value("${USER_CACHE_TTL:300}")
private long userCacheTtl;

4.6 配置优先级与覆盖关系

当多种配置方式共存时，需要明确优先级顺序。Spring Boot 的配置优先级从高到低为：环境变量 > 配置中心 > 配置文件 > 代码硬编码。集成测试必须验证最终生效的过期时间是否符合预期。

4.7 集成测试验证清单

• 配置读取验证： 确认应用启动时正确加载了预期来源的过期时间值。
• 优先级验证： 同时设置多种配置方式，验证高优先级覆盖低优先级。
• 热更新验证： 针对配置中心方式，动态修改过期时间并验证缓存行为变化。
• 边界值验证： 测试 TTL=0（永不过期）、TTL=1（最短过期）、TTL=极大值（如 86400 秒）等边界。
• 配置缺失验证： 模拟配置中心宕机或环境变量未设置，验证应用是否使用默认值或优雅降级。
• 多缓存区域验证： 不同缓存区域（userCache、productCache）使用不同 TTL，验证各自独立生效。