你在配置文件里认真写好了 Redis 的连接池参数——最大连接数、最大空闲、等待超时，写得明明白白。启动一切正常，日志里没有任何报错。可一到大促、压测或流量高峰，应用就开始大面积超时、报"连接耗尽"。你把配置文件翻来覆去看了十遍，数值明明没错，为什么不生效？
现象
平时单人测试一切正常，只有在并发上来之后才出问题。典型报错：
org.springframework.data.redis.RedisConnectionFailureException:
Cannot get Jedis connection; nested exception is
redis.clients.jedis.exceptions.JedisExhaustedPoolException:
Could not get a resource from the pool
或者表现成接口大面积超时、连接数被打满。而启动日志里没有任何一条"配置未生效"的提示——这正是最坑的地方。
根因
根因通常是一句：依赖里少了连接池实现库，框架的连接池自动配置就"以该库存在为条件"，缺库时整段配置被静默忽略。
以 Spring Boot 搭配 Redis 为例。你在 application.yml 里写的是这样的参数：
spring:
data:
redis:
host: <IP>
port: 6379
lettuce:
pool:
max-active: 50
max-idle: 20
min-idle: 5
这套 lettuce.pool.* 参数要真正被采用，前提是 classpath 里存在一个连接池实现（Lettuce 依赖 commons-pool2）。如果构建时没有把它引进来，自动配置类会发现自己"没有可用的池实现"，于是干脆不装配带池的连接工厂，退回到一个简单、无池的实现。
关键在于：这种退化不会报错、不会告警。框架的设计初衷是"没有池也能用"，所以它选择安静地降级；而你的配置文件仍然在那里，看起来一切正常。结果就是：你认为自己配了池，实际跑的是一个没有上限控制、行为完全不同的连接工厂。高并发一到，连接就被打爆。
这类问题的通用模式是："配置存在"和"配置被采用"是两件事。 很多框架用"条件装配"——只有某个类或某个 bean 存在时，这段配置才生效。缺了前提条件，配置就被忽略，而且往往是静默的。
解决
第一步，先确认你真正在用哪个连接池。 看依赖树里有没有池实现库：
# Maven
mvn dependency:tree | grep -i commons-pool
# Gradle
./gradlew dependencies | grep -i commons-pool
第二步，把缺的池依赖补上。 以 Lettuce 为例：
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-pool2</artifactId>
</dependency>
补上依赖、重新构建后，lettuce.pool.* 里的参数才会真正被读取。
第三步，验证参数确实生效——这是最关键、也最容易被省略的一步。不要只看"启动没报错"，要主动去查。可以打开 Redis 侧的监控，压测时观察连接数：
redis-cli info clients
# connected_clients:xx
如果 max-active 配的是 50，压测时连接数应该稳定在 50 以内；如果连接数一路飙升到远超这个值，说明池配置根本没生效。另一种办法是在应用里打印实际使用的连接工厂类型，确认它带不带池。
延伸与预防
把这个教训抽象出来，就是一条通用规则：凡是"条件装配"，都要主动验证，而不是相信它默默生效。
- 看依赖树，不看你的 yaml。参数写得对不对是次要的，前提条件（依赖、bean、开关）在不在才是决定性的。
- 升级或裁剪依赖时格外小心。为了给包"瘦身"删掉某个看起来用不到的库，很可能正好删掉了某个自动配置的前提条件，于是配置悄悄失效。这类问题往往要等到线上高并发才暴露。
- 给关键配置加监控。连接池的当前连接数、等待队列长度，都是值得报警的指标——它们能在"连接耗尽"变成用户可见故障之前给出信号。
一句话："启动不报错"从来不等于"配置被采用"。 对任何你依赖其生效的配置，都准备一条独立的验证路径。