异步架构设计：从同步阻塞到异步队列的改造，深刻理解了"提交即返回、状态可追踪、失败可重试"的设计理念。内存队列 + 线程池在单体应用中性价比极高。SSE 流式交互：EventSource + SseEmitter 的组合实现了类 DeepSeek 的实时输出体验。流式设计中需特别注意连接生命周期管理、中断恢复、缓冲区同步等问题。状态机实践：五状态模型配合指数退避重试，有效提升了系统的容错性。WAR

而“病情诊断书导入分析”功能是这个模块的重要补充——用户上传自己的诊断书，系统帮助分析，让用户更好地理解自己的病情和医嘱。该功能的目标是：用户上传诊断书图片、PDF或扫描件后，系统自动完成文字识别、关键信息提取、结构化分析，最终生成通俗化的解读报告。Qwen-VL不是完美的，但对于“智愈”项目的诊断书OCR需求，它的语义理解能力、手写体优势、零模板适应，使其成为实训项目的最佳选择。我们人类看到一张

本篇博客完成了"病情诊断书导入分析"模块的完整功能设计与技术选型。继承：基于 Qwen-VL 构建识别能力，不做重复选型复用：最大化复用"智愈"系统现有的文件上传、AI 集成、知识查询能力混合：AI 做理解与提取，本地数据库做知识关联，各取所长新建诊断书分析相关的数据表实现 DiagnosisController 与 DiagnosisService扩展 ApiService 支持 Qwen-VL

传统诊断书识别方案采用"OCR 提取文字 → NER 结构化"的两阶段流水线，需要维护两套模型和复杂的中间数据转换。本模块利用 Qwen-VL 多模态模型的强大能力，一次 API 调用完成文字识别 + 语义理解 + 结构化输出三项任务，架构更简洁，维护成本更低。

在上一篇博客中，我们设计了文档管理子系统的四层架构、数据模型、状态机、异步任务队列和 API 接口规范。本文将从设计图走向代码，详细阐述每个核心模块的编码实现过程。原表仅包含基础字段（id、user_id、file_name、image_url、analysis_result、create_time），无法支撑异步任务的生命周期管理。我们通过迁移脚本为现有表新增了 6 个字段：2.2 字段设计说明

四层架构：UI → API → Service → DAO，职责清晰，层次分明数据模型：扩展表，引入状态枚举和进度跟踪文件存储：基于阿里云 OSS，设计了存储层级、命名规范和访问策略异步任务：采用线程池 + 内存队列，实现异步解耦和削峰填谷API 规范：统一响应格式，设计了 8 个标准 RESTful 接口下一篇博客：将进入具体的编码实现环节，包括数据库迁移脚本、线程池配置、异步任务执行器、状态机

传统诊断书识别方案采用"OCR 提取文字 → NER 结构化"的两阶段流水线，需要维护两套模型和复杂的中间数据转换。本模块利用 Qwen-VL 多模态模型的强大能力，一次 API 调用完成文字识别 + 语义理解 + 结构化输出三项任务，架构更简洁，维护成本更低。

本篇博客完成了"病情诊断书导入分析"模块的完整功能设计与技术选型。继承：基于 Qwen-VL 构建识别能力，不做重复选型复用：最大化复用"智愈"系统现有的文件上传、AI 集成、知识查询能力混合：AI 做理解与提取，本地数据库做知识关联，各取所长新建诊断书分析相关的数据表实现 DiagnosisController 与 DiagnosisService扩展 ApiService 支持 Qwen-VL

而“病情诊断书导入分析”功能是这个模块的重要补充——用户上传自己的诊断书，系统帮助分析，让用户更好地理解自己的病情和医嘱。该功能的目标是：用户上传诊断书图片、PDF或扫描件后，系统自动完成文字识别、关键信息提取、结构化分析，最终生成通俗化的解读报告。Qwen-VL不是完美的，但对于“智愈”项目的诊断书OCR需求，它的语义理解能力、手写体优势、零模板适应，使其成为实训项目的最佳选择。我们人类看到一张