标书上传至解析任务排队：产品流程说明¶
本文面向产品与业务同学，说明从用户在客户端上传文件到云端存储，到「解析任务」进入后台排队的主路径。不展开接口字段与底层实现细节，仅勾勒环节先后与责任分工。
一句话¶
用户把招标文件直传到对象存储（OSS） → 在应用里点确认解析 → 服务端校验文件、抽出全文正文（Markdown）并写入数据库供后续环节复用 → 落库解析任务与标书状态 → 把「执行全文解析」写入 Redis 任务队列 → 后台 Worker 取队执行任务。
流程图（主路径）¶
flowchart LR
A[用户在标书下发起上传] --> B[申请上传凭证]
B --> C[浏览器直传文件到 OSS]
C --> D[用户确认「开始解析」]
D --> E[服务端校验文件是否存在、格式与大小]
E --> F[从文件抽取全文正文 Markdown]
F --> G[将 Markdown 写入数据库<br/>供后续解析与检索复用]
G --> H[生成/更新解析任务并绑定标书<br/>状态写入数据库]
H --> I[任务投递至 Redis 任务队列]
I --> J[解析 Worker 从队列取任务并执行]各阶段在业务上代表什么¶
| 阶段 | 用户侧感知 | 系统侧在做什么（概要） |
|---|---|---|
| 申请凭证 | 选文件、拿到可上传的授权信息 | 校验文件类型等规则，签发短时有效的上传许可 |
| 直传 OSS | 进度条上传完成 | 文件落在对象存储指定路径，与标书、用户空间对应 |
| 确认解析（开头几步） | 点击确认后短暂等待，再看到「任务已创建」等 | 从 OSS 读取文件；校验可读、格式与大小 |
| 正文入库 | 通常无单独页面 | 将文件整理为 Markdown 全文，先写入数据库；后续 Worker 做深度解析、检索、再加工时直接复用，避免重复从原始文件抽文 |
| 任务与标书写库 | 同一确认流程内 | 解析任务档案（进度、文件引用等）、标书与任务的绑定关系、标书「解析中」等状态，以数据库为准存档 |
| 入队（Redis） | 一般无单独界面 | 向 Redis 任务队列投递一条「谁来执行、执行哪一次」的调度消息：多机部署时抢任务、排队、重试策略在这里完成；不替代数据库里那份正式任务记录 |
| Worker 执行 | 列表/详情里状态从处理中到完成或失败 | 独立进程从队列领到活以后，读取库中已存的 Markdown 与任务信息，跑耗时的全文解析流水线，结果回写数据库；首屏流式体验可走单独的「事件流」（此处不展开） |
数据库 和 Redis 任务队列 各自干什么（产品视角）¶
| 业务数据库 | Redis 任务队列 | |
|---|---|---|
| 像什么 | 电子档案柜：任务详情、标书状态、全文正文副本、解析结果都要长期可查、可审计 | 车间叫号机：接下来谁干哪一单的临时纸条 |
| 主要存什么 | 任务与标书信息、确认后落库的 Markdown、解析完成后的概况/评分/需求等结构化结果 | 待执行 / 重试中 的任务调度信息（哪次解析、参数指纹等，具体以研发实现为准） |
| 谁依赖谁 | 产品页面上看到的「任务是否完成、结果是否已有」以库表为准 | Worker 消费队列只是为了被叫醒干活；干完活的证据仍写回数据库 |
| 缺了会怎样 | 没有库：无法稳定展示历史与结果 | 没有队列：多台机器时不好协调谁执行任务，也难做排队与失败重试 |
一句话：数据库 = 真相来源（What happened / 结果是什么）；Redis 队列 = 工作派发（Who does it next）。
与「快速概览解析」的关系（可选路径）¶
用户连上解析事件流时，若尚未有 Worker 在处理对应排队项，系统会补一次入队，避免「页面开了但没人干活」。整体仍服从「先入队、再被 Worker 执行」的节奏。
文档维护¶
- 如产品流程有阶段合并或重命名（例如与订阅、多文件版本有关），请同步更新本页流程图与表格，技术细节可链到研发内部设计文档。