启动报错IllegalStateException: Error processing condition，根本原因是spring-data-redis版本冲突；需用IDEA的Dependency Analyzer定位标红冲突依赖，右键Exclude指定groupId/artifactId（如redis.clients:jedis），并验证mvn dependency:tree确保commons-pool2等传递依赖唯一。
启动报错 IllegalStateExeption: Error processing condition，八成是 spring-data-redis 版本打架
这不是 Redis 配置写错了，而是 Maven 把两个不同版本的 spring-data-redis 同时塞进了 classpath。Spring Boot Starter 自带一个（比如 2.7.8），而你显式引入的 redisson-spring-boot-starter 或 spring-data-redis 又带进来另一个（比如 2.7.5 或 3.0.2）。Spring Boot 的条件注解（@ConditionalOnClass、@ConditionalOnMissingBean）一碰上类加载不一致，直接抛这个错。
别急着改代码或降级版本——先确认冲突点在哪。最省力的方式就是打开 IDEA 的 pom.xml，切到底部的 Dependency Analyzer 标签页，选 Conflicts 子页。有冲突的依赖会标红，一眼就能看到谁和谁在抢同一个 groupId/artifactId。
用 Maven Helper 一键排除冲突的 redis.clients:jedis 或 org.apache.commons:commons-pool2
常见组合是：spring-boot-starter-data-redis 拉了 jedis 4.1.2 和 commons-pool2 2.11.1，但你自己又加了 jedis 4.3.1 ——结果运行时加载的是旧版 Jedis 的类，调用新版方法就崩。
- 在
Dependency Analyzer → Conflicts中找到标红的jedis或commons-pool2 - 右键它 → Exclude（不是 Remove，Exclude 才会生成
<exclusion>） - 插件会自动在对应依赖块里补上
<exclusions>块，例如排除掉传递进来的旧版 jedis：
<dependency>
<groupId>org.redisson</groupId>
<artifactId>redisson-spring-boot-starter</artifactId>
<version>3.29.0</version>
<exclusions>
<exclusion>
<groupId>redis.clients</groupId>
<artifactId>jedis</artifactId>
</exclusion>
</exclusions>
</dependency>
注意：<exclusion> 里不能写 <version>，Maven 不认。
为什么不能只靠 <properties> 统一版本？
Spring Boot 的父 POM 确实通过 <properties> 管理了 spring-data-redis 版本，但这个机制只对「没声明 version 的 starter」生效。一旦你显式写了 <version>3.0.0</version>，Maven 就按 nearest definition wins 规则优先采用你写的那个——哪怕它和 Spring Boot 内部期望的不兼容。
所以更稳妥的做法是：
- 删掉所有显式声明的
spring-data-redis、jedis、lettuce-core版本号 - 只保留
spring-boot-starter-data-redis或官方推荐的redisson-spring-boot-starter - 用
<properties>覆盖时，必须核对 Spring Boot 官方支持矩阵（比如 Boot 3.2.x 对应spring-data-redis 3.2.x，不支持 3.3.x）
排除后还要验证 commons-pool2 是否真被干掉了
commons-pool2 是个隐形地雷：Jedis 和 Lettuce 都依赖它，但不同版本对连接池配置项的支持差异很大。比如 maxWaitMillis 在 2.11+ 改成了 maxWait，配置没改就会静默失效。
排除完再执行一次：
mvn dependency:tree -Dincludes=org.apache.commons:commons-pool2
确保输出里只剩一个版本，且是你主动引入的那个。如果还出现两次，说明某个依赖没 exclude 干净，得回 Dependency Analyzer → All Dependencies as Tree 里顺藤摸瓜找源头。
真正麻烦的从来不是“怎么排除”，而是排除之后没人检查 runtime 行为是否一致——比如连接池参数失效、序列化器不匹配、甚至 Redis 命令返回类型悄悄变了。
