Spring Cache 找不到 Hazelcast 缓存管理器

应用已经创建 HazelcastInstance，加入 Hazelcast starter 后却仍找不到 HazelcastCacheManager，@Cacheable 也没有走预期的 Hazelcast 缓存。先检查运行类路径里有没有 hazelcast-spring，不要马上再手工创建第二个集群实例。

通用 Hazelcast 支持与 Spring Cache 适配是两层能力。Spring Boot 的 Hazelcast 缓存自动配置需要 HazelcastInstance，同时需要 com.hazelcast:hazelcast-spring 提供相应 CacheManager 类。Spring Boot 4.2.0-M2 将这项适配依赖设为可选；已有 HazelcastInstance 不会自动补上 Spring Cache 所需的类。

增加适配模块，保持版本管理一致

如果选择的是 Spring Cache 的 HazelcastCacheManager，并且项目使用 Spring Boot BOM 管理 Hazelcast 版本，可在已有依赖配置中增加：

<dependency>
    <groupId>com.hazelcast</groupId>
    <artifactId>hazelcast-spring</artifactId>
</dependency>

这段依赖声明以相关版本已被项目 BOM 管理为前提。没有版本管理时，应先对齐 Hazelcast core 与 spring 模块的兼容版本，不任意给它填一个最新版本。也要检查它是否误放在 test、provided 或其他不会进入应用运行类路径的配置中。

保留现有 Hazelcast 配置、集群连接方式和缓存名，不为了满足自动配置顺便新建另一套 HazelcastInstance。项目还需按原方式启用 Spring 缓存注解；依赖存在不自动证明注解已经拦截到业务调用。

区分 Spring Cache 与 JCache

Hazelcast 可以通过原生 Spring CacheManager，也可以通过 JCache 接入。spring.cache.type=hazelcast 对应前者，选择 jcache 则应核对 JCache 提供者和配置，不能混用两套条件来判断同一个 Bean。

查看实际运行依赖树和条件评估报告，先确认类可见、实例可用，再确认最终选择的 CacheManager 类型。如果应用已经自己声明 CacheManager，自动配置可能退让；此时不断增加依赖并不能替换已存在的 Bean。

用项目已有缓存方法验证首次调用、相同键再次调用以及失效后的行为，核对命中的是原集群和预期缓存名。避免仅直接调用 HazelcastInstance 成功，就认定 Spring 注解路径已经接通。

回退时恢复依赖和缓存类型配置，保留原来的集群数据与业务入口。依赖选择仍遵守项目的稳定版本与兼容范围，不必为接入缓存切换到预发布版本，也不应通过清空共享缓存来证明自动配置生效。