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