refactor(service): 修改IEntityService泛型为VO类型并优化缓存策略

重构所有注解@CacheConfig的Service类，将IEntityService泛型从实体类改为VO类
实现实体与VO之间的转换逻辑，使用VO替代实体进行缓存以避免序列化问题
更新相关依赖组件和测试用例，确保功能完整性和系统兼容性
优化Redis缓存配置，清理旧缓存数据并验证新缓存策略有效性

docs/task/ALIGNMENT_接口泛型修改.md

@@ -0,0 +1,78 @@
+# IEntityService接口泛型修改任务对齐文档
+
+## 1. 项目上下文分析
+
+### 1.1 项目结构与技术栈
+- **项目**: Contract-Manager
+- **模块**: server模块
+- **技术栈**: Java 21, Spring Boot 3.3.7, Spring Data JPA 3.3.7, Redis (用于缓存)
+
+### 1.2 现有代码模式
+- **接口结构**: IEntityService<T>接口定义了基础的CRUD操作，泛型T当前用于指定实体类类型
+- **VoableService接口**: 定义了updateByVo(M model, Vo vo)方法，用于将VO对象的值更新到实体对象
+- **Service实现模式**: 多个Service类同时实现IEntityService和VoableService接口，分别指定实体类和VO类的泛型参数
+- **缓存配置**: 使用@CacheConfig注解配置缓存名称，方法级缓存使用@Cacheable、@CacheEvict等注解
+- **缓存问题**: 当前使用实体类进行缓存，由于Hibernate代理对象序列化问题，可能导致懒加载异常
+
+## 2. 需求理解确认
+
+### 2.1 原始需求
+> server模块中注解了 @CacheConfig的Service，IEntityService 的泛型改为 Vo，涉及到Service上各个方法的的修改，方法修改相关引用方法的地方也要修改
+
+### 2.1.1 扩展需求
+> 使用VO替代实体缓存，因为使用redis服务，需要避免代理对象序列化，彻底规避懒加载问题
+
+### 2.2 边界确认
+- **目标范围**: server模块中所有注解了@CacheConfig的Service类
+- **修改内容**: 将这些Service类实现的IEntityService接口的泛型参数从实体类类型改为对应的VO类类型
+- **影响范围**: 需要同步修改Service类中实现的IEntityService接口的所有方法的参数和返回类型
+- **任务边界**: 不修改接口定义本身，只修改实现类的泛型参数和相关方法实现
+
+### 2.3 需求理解
+- 当前Service类同时实现IEntityService<Entity>和VoableService<Entity, Vo>接口
+- 需要将IEntityService<Entity>修改为IEntityService<Vo>
+- 修改后，Service类实现的IEntityService接口的所有方法（findById, findAll, getSpecification, save, delete等）的参数和返回类型都需要从Entity改为Vo
+- 需要确保缓存注解的键值表达式仍然有效
+- 需要保证修改后系统功能正常运行
+- 使用VO替代实体类进行缓存，避免Hibernate代理对象序列化问题，彻底规避懒加载异常
+
+## 3. 疑问澄清
+
+1. **数据转换问题**: 如何处理从实体类到VO的转换和从VO到实体类的转换？
+   - 系统中已有VoableService接口提供updateByVo方法，可能需要利用现有转换机制
+
+2. **缓存键表达式**: 修改泛型后，缓存注解中的键表达式（如@CacheEvict(key = "#p0.id")）是否需要修改？
+   - 需要确认VO类是否与实体类具有相同的属性结构
+
+3. **依赖影响**: 修改Service泛型后，对调用这些Service的其他组件（如Controller、其他Service）会有什么影响？
+   - 需要评估依赖影响范围并考虑如何处理
+
+4. **事务处理**: 修改后事务处理是否会受到影响？
+   - 需要确保事务边界正确维护
+
+5. **查询规范**: getSpecification方法如何适配从Entity到Vo的转换？
+   - Specification是基于JPA实体类的，这可能需要特殊处理
+
+6. **缓存对象转换**: 如何确保缓存中存储的是VO对象而不是实体类对象？
+   - 需要确保所有缓存的方法都返回VO对象，并在存储前完成转换
+
+## 4. 初步决策
+
+基于现有项目代码分析，做出以下初步决策：
+
+1. **泛型修改策略**: 对于每个注解了@CacheConfig的Service类，将IEntityService<T>的泛型T从实体类改为对应的VO类
+
+2. **方法适配方案**:
+   - 对于返回类型为T的方法，需要在方法内部进行实体类到VO的转换
+   - 对于参数为T的方法，需要在方法内部进行VO到实体类的转换
+   - 对于findAll等查询方法，需要修改Specification的泛型类型
+
+3. **缓存键处理**: 假设VO类与实体类具有相同的ID属性和其他缓存键中使用的属性，因此缓存注解可能不需要修改
+
+4. **依赖处理**: 需要评估并处理所有调用修改后Service的组件，确保它们适应新的接口定义
+
+5. **特殊方法处理**: 对于getSpecification等基于JPA实体的方法，可能需要特殊处理或保留原有实现
+
+6. **缓存策略**: 确保所有标注@Cacheable的方法都返回VO对象，并在存储前完成从实体类到VO的转换，以避免代理对象序列化问题
+
+这些决策将在后续的共识和设计阶段进一步细化和确认。