申请书处理流程与“草稿—归档”双通道
1. 为什么要把主流程拆成两条通道
申请书相关需求并不只是一件事：既要支持频繁编辑（可随时改、可随时预览），又要支持归档与后端处理（上传后进入抽取/预览/评分链路）。如果把两类需求混在一条链路里，会出现：
- 编辑时被迫反复上传文件，成本高且体验差
- 上传记录和编辑内容耦合，导致状态管理复杂且容易出错
因此项目把前端的“文档处理”拆成两条通道：
- 草稿通道：面向编辑体验，内容以结构化数据存储，可高频保存
- 归档通道：面向后端处理，统一用文件上传触发后端抽取与评分
2. 结构分层：让复杂流程有稳定承载点
当交互包含队列、并发、重试、状态回写时，页面本身不适合承载这些细节。项目采用一种更“工程化”的分工：
- 页面负责布局与入口（把组件拼起来）
- 组件负责呈现与交互（点击、选择、展示状态）
- store 负责流程与状态（队列推进、并发控制、错误回写）
- API 层负责网络细节（统一鉴权、统一解析、统一错误）
这样做的直接效果是：页面代码不会因为流程变复杂而失控，排查问题也更容易定位到“流程层还是 UI 层”。
3. 申请书处理：用队列化降低并发带来的不确定性
用户可能一次提交多份文件。把所有请求同时打出去，常见问题是：
- 某些浏览器会变得不响应（大量并发读文件/发请求）
- 请求失败率上升，且失败原因不可解释
- 状态回写顺序错乱，列表展示与实际处理不一致
解决思路是“少量并发 + 排队推进”：一次只允许少数任务在运行，其余等待。前端为每个任务维护一份明确状态（等待、进行中、成功、失败），并把错误信息写回到对应条目，用户能够看懂每一步发生了什么。
4. 评分操作：把动作设计成可重复、可追踪
评分动作的关键并不是按钮本身，而是“可追踪”：
- 同一条目在评分时必须防止重复触发
- 成功或失败都要落到条目状态上
- 如果用户正在查看详情，详情展示要与列表同步
同时，为了提升效率，支持“多选后一次提交”的评分方式：前端只负责收集目标、发起请求、回写结果；评分本身由后端统一执行，避免在前端引入任何与模型相关的复杂性。
5. 文档中心：编辑体验与后端归档的解耦
文档中心面向“我自己的申请书/任务书”，核心能力是：
- 草稿可创建、可编辑、可删除
- 编辑过程中自动保存（减少“忘记保存”导致的丢失）
- 需要归档时一键导出并提交（与后端文件处理链路对齐）
自动保存采用延迟触发策略：输入时只标记改动，短暂停顿后再提交更新，既减少请求，又能保证用户离开页面前内容已落盘。
6. 元数据提交：让后端能“直接用”
归档上传不仅提交文件，也会提交描述信息（例如学号、项目名、负责人等），让后端能建立检索与权限边界。
任务书在此基础上额外提交博客入口地址，用于后端维护“学号 → 博客入口”的映射表。这样后端爬虫或分析服务不必解析复杂表单结构，只需读取绑定表即可开始工作。
7. 管理端联动：管理员视角的“快速定位”
管理员的核心诉求是“快速定位数据”，因此后台提供：
- 权限相关页面：便于管理用户权限并跳转查看其材料
- 数据相关页面：便于查看绑定表等后端需要的基础数据
这部分入口由路由访问控制统一保护，避免普通用户进入后台页面。
8. 小结
这篇笔记强调的是“流程设计”而不是“页面罗列”：把编辑与归档分成两条通道，把复杂流程放进 store，把网络细节放进 API 层，把 UI 做成可解释的状态展示。这样系统才能在功能继续增长时仍保持可维护与可扩展。
