refactor(service): 统一Service缓存为VO对象并优化关联实体处理

重构Service类实现，将QueryService泛型参数调整为VO类型，确保缓存VO对象而非实体。优化关联实体处理逻辑，减少重复代码。修改findById方法返回VO对象，新增getById方法获取实体。更新相关调用点以适配新接口。

调整WebSocket处理、控制器及Service实现，确保数据类型一致性。完善文档记录重构过程及发现的问题。为后续优化提供基础架构支持。

docs/task/server模块service缓存调整为Vo对象/ACCEPTANCE_server模块service缓存调整为Vo对象.md

@@ -2,7 +2,7 @@
 
 ## 1. 任务概述
 
-本任务的目标是调整server模块中所有注解了@CacheConfig的Service类的接口泛型参数：Service类继承IEntityService接口时泛型类型保持为Model（实体类），继承QueryService接口时泛型类型修改为Vo（视图对象），并同步修改这些Service类中实现的接口方法的参数和返回类型。
+本任务的目标是调整server模块中所有注解了@CacheConfig的Service类的接口泛型参数：Service类继承IEntityService接口时泛型类型保持为Model（实体类），继承QueryService接口时泛型类型修改为Vo（视图对象），并同步修改这些Service类中实现的接口方法的参数和返回类型。此外，还优化了updateByVo方法中关联实体的处理逻辑，添加了空值判断和实体匹配检查，并将findById方法替换为getById方法以提高代码健壮性。
 
 ## 2. 验收标准及完成情况
 
@@ -77,12 +77,14 @@
 | 任务ID | 任务名称 | 状态 | 完成日期 | 备注 |
 |-------|---------|------|---------|------|
 | T1 | 分析现有Service类结构和依赖关系 | ✅ | - | - |
-| T2 | 设计实体类和VO类之间的转换机制 | ✅ | - | - |
-| T3 | 修改单个Service类的泛型参数和方法实现 | ⬜ | - | - |
-| T4 | 批量修改所有注解了@CacheConfig的Service类 | ⬜ | - | - |
-| T5 | 分析并处理受影响的依赖组件 | ⬜ | - | - |
+| T2 | 设计实体类和VO类之间的转换机制 | ✅ | - | CompanyFileTypeLocal通过继承Voable接口并实现toVo方法完成转换 |
+| T3 | 修改单个Service类的泛型参数和方法实现 | ✅ | - | 完成YongYouU8Service的修改 |
+| T4 | 批量修改所有注解了@CacheConfig的Service类 | ✅ | - | 已完成CompanyFileTypeService、ContractFileTypeService、CustomerFileTypeService、VendorFileTypeService和ProjectFileTypeService的修改：QueryService泛型调整为Vo、findById返回Vo、findAll(JsonNode, Pageable)返回Page<Vo>、保留一个save方法、使用实体类自带的toVo方法进行转换而不创建独立的toVo方法 |
+| T5 | 分析并处理受影响的依赖组件 | ✅ | - | 完成CloudYuController的修改 |
 | T6 | 编写测试用例并验证修改 | ⬜ | - | - |
-| T7 | 更新相关文档并总结 | ⬜ | - | - |
+| T7 | 更新相关文档并总结 | ✅ | - | 已更新ACCEPTANCE、FINAL和TODO文档 |
+| T8 | 优化updateByVo方法中关联实体处理逻辑 | ✅ | - | 完成ContractService、ContractItemService等9个合同相关Service类的修改，添加空值判断和实体匹配检查，将findById替换为getById |
+| T9 | 优化客户相关Service的updateByVo方法 | ✅ | - | 完成CompanyCustomerEvaluationFormFileService、CompanyCustomerFileService、CompanyCustomerService的修改，处理customerFile、customer、companyId、catalogId、contactId等关联实体 |
 | T10 | 分析并修改WebSocket服务组件 | ⬜ | - | - |
 
 ### 3.2 里程碑完成情况
@@ -90,12 +92,13 @@
 | 里程碑 | 预期完成时间 | 实际完成时间 | 状态 | 备注 |
 |-------|------------|------------|------|------|
 | 需求分析和文档编写 | - | - | ✅ | 完成ALIGNMENT、CONSENSUS、DESIGN、TASK文档 |
-| 试点Service类修改 | - | - | ⬜ | - |
-| 批量Service类修改 | - | - | ⬜ | - |
-| 依赖组件分析和修改 | - | - | ⬜ | - |
+| 试点Service类修改 | - | - | ✅ | 完成YongYouU8Service的修改 |
+| 批量Service类修改 | - | - | ✅ | 完成合同相关和客户相关Service类的批量修改 |
+| updateByVo方法优化 | - | - | ✅ | 完成合同相关9个Service类和客户相关3个Service类的updateByVo方法优化 |
+| 依赖组件分析和修改 | - | - | ✅ | 完成CloudYuController的修改 |
 | WebSocket服务分析和修改 | - | - | ⬜ | 分析并修改WebSocketServerCallbackManager、WebSocketServerTaskManager等组件 |
 | 测试验证 | - | - | ⬜ | - |
-| 文档更新和总结 | - | - | ⬜ | - |
+| 文档更新和总结 | - | - | ✅ | 已更新ACCEPTANCE文档，记录updateByVo方法优化工作 |
 
 ## 4. 问题和风险记录
 
@@ -103,14 +106,15 @@
 
 | 问题ID | 问题描述 | 严重程度 | 解决状态 | 解决方法 |
 |-------|---------|---------|---------|---------|
-| P1 | Specification泛型修改带来的查询问题 | 高 | ⬜ | 需要特殊处理基于JPA实体的查询规范 |
+| P1 | Specification泛型修改带来的查询问题 | 高 | ✅ | 采用直接调用Repository的方式绕过Specification |
 | P2 | 数据转换可能带来的性能影响 | 中 | ⬜ | 需要优化转换逻辑，考虑缓存转换结果 |
-| P3 | 依赖组件修改工作量大 | 中 | ⬜ | 需要系统地分析和处理每个依赖组件 |
-| P4 | 代理对象序列化导致的懒加载问题 | 高 | ⬜ | 使用VO对象替代实体类进行缓存 |
+| P3 | 依赖组件修改工作量大 | 中 | ✅ | 完成了YongYouU8Service、CloudYuController以及多个合同和客户相关Service类的修改 |
+| P4 | 代理对象序列化导致的懒加载问题 | 高 | ✅ | 使用entity.toVo()方法将实体转换为VO后再返回和缓存 |
 | P5 | Redis缓存清理和数据迁移 | 中 | ⬜ | 编写脚本清理旧的实体类缓存数据 |
 | P6 | VO对象序列化安全性 | 中 | ⬜ | 确保VO类实现Serializable接口，避免不可序列化引用
 | P7 | WebSocket服务类型处理问题 | 高 | ⬜ | WebSocketServerCallbackManager的反射调用方法需要适应IEntityService接口泛型变化
 | P8 | WebSocket任务执行影响 | 中 | ⬜ | WebSocketServerTaskManager的任务执行可能受到接口泛型修改的影响
+| P9 | updateByVo方法中关联实体处理逻辑不完善 | 中 | ✅ | 优化了12个Service类的updateByVo方法，添加空值判断和实体匹配检查，将findById替换为getById方法
 
 ### 4.2 风险评估
 
@@ -124,6 +128,7 @@
 | R6 | 新旧缓存数据混用导致系统异常 | 中 | 实施严格的缓存清理策略，确保只使用新的VO缓存数据
 | R7 | WebSocket服务类型处理错误 | 高 | 详细测试WebSocketServerCallbackManager的类型处理逻辑，确保createNewEntity、invokerFindByIdMethod等方法能够正确处理VO类型
 | R8 | WebSocket服务任务执行失败 | 中 | 测试WebSocketServerTaskManager的任务执行流程，确保任务能够正确处理VO类型的数据
+| R9 | updateByVo方法关联实体处理错误 | 中 | 采用统一的模式处理关联实体：先判断ID是否为空（为空时设为null），非空时获取对应Service实例，检查当前实体关联对象是否存在且ID是否匹配，不匹配时调用getById方法获取并设置关联实体
 
 ## 5. 测试结果汇总
 
@@ -147,12 +152,12 @@
 
 ## 6. 最终验收结论
 
-**当前状态**: 文档编写阶段已完成，代码实现阶段尚未开始
+**当前状态**: 已完成YongYouU8Service和CloudYuController的代码修改，正在更新相关文档
 
-**验收结论**: 待所有代码实现和测试验证完成后，进行最终验收
+**验收结论**: 试点修改已完成，待批量修改其他Service类并进行全面测试后，进行最终验收
 
 **建议**: 
-1. 在开始代码实现前，确保所有设计文档已经过评审和确认
+1. 在开始批量修改前，确保试点修改的代码经过充分测试
 2. 按照任务拆分计划逐步执行，每完成一个任务进行验证
 3. 特别关注数据转换、依赖组件修改和缓存策略实现等关键环节
 4. 充分进行测试，尤其是缓存功能测试，确保Redis中只存储VO对象
@@ -162,5 +167,9 @@
 ---
 **文档更新记录**:
 - 创建日期: -
-- 更新日期: -
-- 更新内容: -
+- 更新日期: 最新
+- 更新内容: 1. 记录updateByVo方法优化的完成情况
+2. 添加任务ID T8和T9，记录合同相关9个Service类和客户相关3个Service类的updateByVo方法优化
+3. 更新里程碑完成情况，将批量Service类修改标记为完成，新增updateByVo方法优化里程碑
+4. 更新问题列表，添加P9问题记录updateByVo方法中关联实体处理逻辑优化
+5. 更新风险评估，添加R9风险记录updateByVo方法关联实体处理的缓解措施