Pinxian Li1. 为什么做一个论文投稿系统
先交代一下背景。这个项目我内部代号叫"m231论文投稿系统"，起因是所在团队一直用邮箱加Excel表格来管理内部论文投稿和审稿，每次到了集中投稿期，邮箱里几十封附件来回飞，版本混乱、审稿进度全靠手动催，统计工作量更是痛苦。所以决定自研一套轻量投稿系统，把从作者投稿、格式审查、分配审稿人、提交审稿意见，到最后出录用结论的整个流程，全部搬到线上。
这篇文章适合谁看？如果你正准备开发类似的流程管理系统——不只是论文投稿，包括内部项目申报、工单流转、评审打分这类"多人协作+多阶段流转"的系统，都可以参考。这里不只是一个功能清单，而是把每一步的设计权衡、踩过的坑、最后的实现方案都讲清楚，很多细节是需求文档里不会写的。
系统最大的一个特点，是把"状态流转"作为核心引擎。我没把业务逻辑散落在各个接口里，而是集中到一个状态机模块里统一管理，配合数据库锁来做并发控制。这一点后面会展开细讲，也是整个项目里性价比最高的一个设计决策。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 需求拆解：先把"投稿"这件事想透
2.1 核心角色的职责边界
做这套系统前，我把参与方拆成了四类角色：作者、编辑、审稿人、系统管理员。听起来很简单，但每一类角色在真实场景里的诉求其实差异很大。
- 作者关心的是"我的论文到哪一步了"、"意见什么时候回来"、"返修后有没有被正确接收"，最怕的是系统没有任何反馈，投完像石沉大海。
- 编辑是系统的重度使用者，他们关心的是批量分配审稿人是否方便、格式审查是否高效、催审提醒能不能自动触发、月底统计能不能一键导出。
- 审稿人需要的是一个清爽的工作台——待审列表、审稿表单、截止时间提醒，不需要也不应该看到其他审稿人的意见。
- 管理员则关注账号安全、操作审计、数据备份这类平台级事务。
权限体系就是围绕这四个角色来做的，核心原则是"最小可见性"：每个角色只看到自己职责范围内该看的东西。这个原则在执行中会遇到很多边界情况，后面会在权限部分专门讲。
2.2 流程节点与状态设计
投稿系统中，一篇论文的生命周期看起来是一条固定的流水线：提交、查重/格式审查、分配审稿人、外审、返修、终审、录用/拒稿。但真做起来，任何一步都可能被驳回重来，所以流程不是一条直线，而是一张带回路的状态图。
我最终把状态节点收敛为这些：
| 状态 | 含义 | 可流转至 |
|---|---|---|
| DRAFT | 作者保存草稿 | SUBMITTED |
| SUBMITTED | 已提交，待编辑处理 | UNDER_REVIEW, REJECTED |
| UNDER_REVIEW | 审稿中 | REVISION_REQUIRED, ACCEPTED, REJECTED |
| REVISION_REQUIRED | 需返修 | UNDER_REVIEW, REJECTED |
| ACCEPTED | 录用 | 终态 |
| REJECTED | 拒稿 | 终态 |
为什么不像很多复杂系统那样把"编辑部初筛"和"外审中"拆成十几个状态？因为状态多了，维护成本成倍上涨，而且对使用者来说，太细的状态反而看懵。我的经验是，状态粒度要匹配业务的实际管控颗粒度，如果编辑并不需要区分"审稿分配中"和"等待第一位审稿人返回意见"，那就合并成一个 UNDER_REVIEW，具体的中间过程通过子记录去实现。
2.3 核心痛点与解决方案
开发过程中，我提炼出了四个必须优先解决的痛点：
第一，版本混乱。传统邮箱投稿中，作者经常发"更新版""最终版""再改一版"，谁也说不清哪份是最新的。解决方案是建立独立的"投稿版本表"，每次作者上传新文件都新增一条记录，同时保留历史版本，任何时刻都能定位到系统当前使用的是哪个版本。
第二，审稿人指派不透明。编辑指派了谁、几位审稿人、已返回几份意见，这些信息如果靠人工记忆，必然出错。解决方案是审稿分配独立成表，支持一篇论文挂多个审稿人，每个审稿人一个独立记录，既能看到整体进度，又不会让审稿人之间相互干扰。
第三，截止时间不可控。很多流程卡就卡在"没人催"。解决方案是把截止日期字段化，配合一个定时任务，到期前一天自动给审稿人发提醒，超期未返回则抄送编辑介入。
第四，统计难。每月、每季度要统计投稿量、录用率、平均审稿周期，如果全靠人工台账，效率极低。解决方案是把所有状态变更都写入日志表，任何统计需求都可以通过日志表按时间维度聚合出来。
3. 技术选型：为什么是这些组合
3.1 整体架构方案
m231论文投稿系统采用了前后端分离的Web架构。后端是 Spring Boot 3 + M