spring.redis.ssl.enabled=true仅是启用tls开关，证书配置必须通过java config显式构造ssloptions并注入lettuceconnectionfactory，且需同步配置密码、max-redirects及正确证书路径。
spring.redis.ssl.enabled=true 只是开关，不是完整配置
设成 true 后连接直接报 javax.net.ssl.SSLHandshakeException，不是配置错了，而是 Spring Boot 根本没读你写的 keystore 路径——RedisProperties 类压根不解析 spring.redis.ssl.keystore 这类字段。它只把 ssl.enabled 当作一个布尔开关传给 Lettuce，证书材料全得你自己塞进去。
常见错误现象：服务能启动，但一发请求就抛握手失败；或者日志里出现 PKIX path building failed，说明信任链断了。
-
spring.redis.ssl.enabled=true必须配，否则 Lettuce 不走 TLS 握手流程 - 所有证书路径、密码、密钥别名都必须在 Java Config 里显式构造
SslOptions - 不要在
application.yml里硬加ssl-key-store字段——Spring 会静默忽略，不报错也不生效
LettuceConnectionFactory 中手动注入 SslOptions
这是唯一可靠的方式。Lettuce 6.3+（Spring Boot 2.7+/3.x 默认）要求你用 SslOptions.builder() 构建证书上下文，并绑定到 LettuceConnectionFactory 实例上。
关键点：keystore 和 truststore 是两回事，不能混用；路径要用 new File(...) 或 ResourceUtils.getFile(...) 加载，不能只写 classpath 前缀。
- keystore 存客户端私钥和证书，用于向 Redis 证明身份（如果 Redis 配了双向认证）
- truststore 存 CA 根证书，用于验证 Redis 服务器证书是否可信
- 密码字段必须匹配实际 JKS 文件的密码，大小写敏感，空格也敏感
- 端口要确认是 TLS 端口（通常是
6380，不是默认6379）
集群模式下 max-redirects 不够用
开启 SSL 后，Lettuce 在重定向时每个跳转都要重新做 TLS 握手，耗时翻倍。默认 spring.redis.cluster.max-redirects=1 很容易超时失败，报 Cannot retrieve cluster information 或卡在 WAITING_FOR_REDIRECT 状态。
这不是证书问题，是网络延迟叠加握手开销导致的连锁超时。
- 把
spring.redis.cluster.max-redirects改成3或5，尤其跨区域部署时更需要 - 确保所有集群节点都启用了 TLS，且证书域名与节点 host 匹配（否则
No name matching xxx found） - Jedis 对 SSL 集群支持弱，Lettuce 是当前唯一稳妥选择
SSL 和 password 是两套独立机制
有人以为开了 ssl.enabled 就等于“安全登录”，其实不是。SSL 只加密传输层，认证还是靠 Redis 的 AUTH 命令。两者必须分开配，缺一不可。
生产环境漏掉任意一项，都可能被中间人劫持或未授权访问。
-
config.setPassword(RedisPassword.of("xxx"))必须显式调用，不能只靠spring.redis.password——后者在 Java Config 模式下不会自动生效 - SSL 证书校验失败时，连接会中断；密码错误时，Redis 返回
NOAUTH错误，但连接本身是通的 - Google Cloud Memorystore 等托管服务强制要求 SSL，但依然要单独传 password
