去年我带着一个小团队，帮某高校数字办做了一套论文管理系统。需求本身不复杂：学生提交论文、导师审核、教务处归档、导出汇总表。但真正动手之后才发现，越是这种看起来“朴素”的业务系统，越容易在细枝末节里翻车。今天这篇就把整套系统的设计思路、核心代码、踩坑过程完整梳理出来，技术选型就是标题里那套组合：SpringBoot + Vue + MyBatis + MySQL。

如果你正打算做论文管理系统，或者接手过科研处、教务处、企业内部文档库这类“文件流转型”业务，这篇文章可以直接当参考。我不会只给成品源码，而是把每个环节“为什么这么设计”讲清楚，包括数据库状态机、文件存储、并发控制、Nginx部署这些容易被忽略的硬骨头。

先说明一下：为避免不必要的麻烦，文中涉及的学校、人员、项目名全部做了脱敏处理，代码片段也做了简化，但核心设计思路是完整可用的。下面按我当时从需求调研到上线运维的推进顺序来讲。

1. 需求从哪来：论文管理的“脏活累活”与技术破局点

1.1 渠道混乱：U盘、邮箱与微信的三重传输瓶颈

需求方是某高校数字办的一位老师，他给我看了一个真实场景：每年毕业季，导师邮箱里堆着上百封主题为“论文终稿——千万不要打开这个版本”的邮件；学生微信群里不停有人发“老师我改了第32版”；甚至有学生直接揣着U盘堵在办公室门口让导师拷走。

这些方式不是不能用，而是根本无法形成闭环。邮件没有统一的命名规则，微信传输没有留痕、文件被覆盖后无处追寻，U盘更不用提，连最基本的“谁在什么时候交了哪一个版本”都说不清楚。论文工作一旦进入中期检查和盲审阶段，问题就集中爆发：导师不确定学生提交的是否为最终版，教务员整理汇总表要手动打开几十个压缩包。

所以这套系统的第一目标非常明确：让每一篇论文的状态、版本、审核记录都数字化，形成不可抵赖的流程痕迹。

1.2 版本失控：同名文件改来改去，最终稿到底在哪

第二痛点是版本管理。绝大多数学生没有版本意识，文件名从“毕业论文”到“毕业论文最终稿”，再到“毕业论文最终稿(1)(2)(3)”，导师收到的附件乱成一团。即使学校要求用“学号_姓名_题目”命名，交上来的文件依然五花八门。

技术上，系统要做的不只是保存一份文件，而是把每一次提交都存成一个版本记录。同一个学生可以多次提交论文，系统保留历史版本，导师审核时能比较新旧差异，甚至直接下载上一版对照。这个思路听起来简单，实际操作中很多团队会漏掉，只设计一张“论文表”，结果学生重新提交后旧文件直接覆盖，审核记录对不上，到后面查问题根本无从下手。

1.3 审计需求：签字流程追溯与归档规范

更麻烦的是线下签字流程。论文评审意见、导师签字、答辩成绩，全靠纸质单子在学校里转圈。教务处的归档要求很严格：谁提交的、谁审核的、审核意见是什么、最终版本是否存在，这些都要能追溯。

这意味着系统不能只做一个“文件上传下载工具”，它必须内嵌流程引擎的雏形：论文在待审核、审核中、通过、退回修改、已归档这些状态之间流转，每一次流转都要生成一条不可删除的操作日志。最初我把状态流转做得很简单，后来在反复测试中不断加入边界条件，这套状态机设计成了整个系统最核心的部分，后面专门用一整节来讲。

2. 整体架构与技术选型：为什么是SpringBoot+Vue+MyBatis+MySQL

2.1 框架组合的取舍逻辑

先说说很多人问的选型问题：SpringBoot + Vue + MyBatis + MySQL，这套组合是不是太“老”了？我的回答是——对于这类企业内部管理系统，它反而是最稳妥的组合。

SpringBoot的优势在于开箱即用，内置Tomcat、统一的依赖管理、大量的Starter，能让团队把主要精力放在业务逻辑而不是环境配置上。Vue在前端生态里适合快速搭建中后台管理系统，配合Element UI组件库，表格、表单、弹窗、上传这些高频场景基本都有现成方案。MyBatis则解决了一个实际问题：论文查询往往涉及多表关联和很复杂的动态条件，SQL直接写在Mapper XML里，调优、复制到Navicat执行都方便，比JPA的自动生成SQL更可控。

MySQL就不用多说了，学校这种并发量（同时在线几百人）用它完全足够，运维成本低，招聘也容易。

2.2 项目分层与目录规划

当时我按下面的目录结构来组织后端工程，这个结构几乎是企业级SpringBoot项目的标准范式：

paper-server/ ├── pom.xml ├── src/main/java/com/xxx/paper/ │ ├── PaperApplication.java │ ├── config/ // WebMvc、拦截器、跨域配置 │ ├── controller/ // 接口层，只做参数接收和结果封装 │ ├── service/ // 业务层，核心逻辑都放在这里 │ ├── mapper/ // MyBatis Mapper接口 │ ├── entity/ // 数据库实体 │ ├── dto/ // 入参出参对象 │ ├── common/ // 统一返回结构、异常处理、工具类 │ └── enums/ // 状态枚举、角色枚举 └── src/main/resources/ ├── mapper/ // Mapper XML，写动态SQL └── application.yml

前端用的是Vue3 + Vite + Element Plus，按路由划分了登录页、学生端、导师端、管理员端，组件按业务模块建目录，比如components/paper、components/review、components/upload。

前后端分离，接口全部走RESTful风格，统一返回{ code, message, data }结构。

2.3 核心依赖版本清单

这里给一份我实测过兼容性比较稳定的版本清单，供参考：

这里要提醒一个容易踩的坑：不要盲目追求最新版本。SpringBoot 3.x要求JDK17起步，如果团队还在用JDK8，或者一些老项目需要兼容旧依赖，整套升上去很痛苦。这套系统用JDK8 + SpringBoot 2.7没有任何性能瓶颈，反而省心。

3. 数据库设计与状态机建模：让论文状态可追踪、可回溯

3.1 核心表结构与主外键关系

数据库是整个系统的地基，这一节我最想讲透。论文管理系统表面看表不多，但如果设计得不好，后面扩展一个“查重记录”“答辩评分”都要改表结构。我按下述几张核心表来拆解：

• sys_user：用户表，存放学生、导师、管理员账号，字段包括学号/工号、姓名、密码（BCrypt加密）、角色、所属院系。
• paper_info：论文主表，一次提交产生一条主记录，字段包括论文编号、课题名称、学生ID、导师ID、当前状态、最终文件名、提交次数、创建时间。
• paper_version：论文版本表，每次上传文件插入一条版本记录，记录原始文件名、存储路径、文件大小、MD5值、上传人。
• review_record：审核记录表，记录审核人、审核动作、审核意见、审核时间，以及关联的论文ID和版本ID。
• sys_dict：字典表，存放论文类型、专业方向等可配置选项。

主外键关系上，学生与导师是多对一，论文与版本是一对多，论文与审核记录是一对多。这里要特别注意：不要在paper_info表里直接堆积所有字段，比如把查重率、评语都塞进去，会导致表字段膨胀、逻辑混乱。查重率、评语这类“一次流程中会产生多次”的数据，应该放到独立的扩展表。

3.2 状态字段设计：不再用is_deleted这类“野路子”

我见过一些项目用status（状态）和is_deleted（删除标记）打天下，论文被退回删掉重传，看似可以用 is_deleted 逻辑删除，实际上会带来两个问题：一是审核记录没有对应版本，二是删除操作无法追溯。更好的做法是用状态机来管理论文生命周期。

我设计的状态枚举大致如下：

public enum PaperStatus { DRAFT(0, "草稿"), SUBMITTED(1, "已提交待审核"), REVIEWING(2, "导师审核中"), FIRST_PASS(3, "初审通过"), RETURNED(4, "退回修改"), FINAL_SUBMITTED(5, "终稿已提交"), ARCHIVED(6, "已归档"), FAILED(7, "审核不通过"); private final int code; private final String desc; // 省略构造方法和getter }

注意，我没有在每个流转里加is_deleted，而是用“状态 + 版本”共同表达是否有效。比如学生重新提交，会新建一条 version 记录，paper_info 里的当前版本ID指过去，状态从“退回修改”变为“终稿已提交”，旧的版本记录不会删除，只是不再是“当前版本”。

这个设计的价值在审计时体现得淋漓尽致：如果学生对审核结果有异议，管理员可以拉出所有版本的提交时间、文件MD5、审核意见，整个过程一目了然。这就是我所说的“可回溯”，也是企业级和业余Demo最大的区别。

3.3 扩展表：审核记录、文件多版本与评分明细

审核记录表我刻意设计成了“动作流水”，而不是“审核结果快照”。字段大致是：

CREATE TABLE review_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, paper_id BIGINT NOT NULL, version_id BIGINT NOT NULL, reviewer_id BIGINT NOT NULL, action TINYINT NOT NULL COMMENT '1提交审核 2审核通过 3退回修改 4归档', comment VARCHAR(1024), create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, INDEX idx_paper_version (paper_id, version_id) ) COMMENT '论文审核记录表';

之所以要把version_id和action分开，是因为一次论文流转里可能会连续审核多个版本。比如学生一次初始提交，导师退回，学生再提交，导师通过。如果只用一张“审核结果字段”去更新论文主表，中间环节就没法完整还原。把动作变成流水的另一个好处是，以后可以对这些数据做统计，比如“某专业平均被退回次数”“导师平均审核时长”，这些可量化的指标对教务处很有价值。

我建议任何做这类业务系统的人都把“记录动作”和“更新状态”分开处理，前者是数据真相，后者是方便查询的冗余。哪怕为此多写几十行代码，也非常值。

4. SpringBoot后端实现：业务闭环的关键细节

4.1 登录认证与RBAC权限控制

权限设计用的是经典RBAC：用户表、角色表、用户角色关联表，再由后端接口做细粒度校验。由于是单体项目，没有引入专门的权限框架（比如Shiro或Spring Security），而是用拦截器 + 自定义注解解决。

核心思路是：登录接口核验账号密码，签发一个Token（我用的是JJWT生成的JWT），存到前端LocalStorage。每次请求在Axios拦截器里带上Authorization: Bearer <token>。后端写一个AuthInterceptor，解析Token、获取用户ID和角色，存到ThreadLocal里供业务层使用。

public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录、验证码等公开接口 if (request.getRequestURI().contains("/login")) { return true; } String token = request.getHeader("Authorization"); if (token == null || !token.startsWith("Bearer ")) { throw new BusinessException(401, "未登录或登录已过期"); } // 解析JWT，解析失败则抛401 Claims claims = JwtUtil.parse(token.substring(7)); UserHolder.set(claims.get("userId"), claims.get("role")); return true; } }

前端路由守卫也做了一层控制：路由meta里声明roles，比如/student/paper-submit只允许ROLE_STUDENT访问。但请记住，前端的隐藏按钮只是体验优化，真正的权限判断必须放在后端。很多人的接口只查登录态、不查角色，结果学生调接口就能干导师的活，这是安全生产事故级别的低级错误。

4.2 论文提交、审核与退回的并发控制

论文提交这个接口是整个系统的并发重灾区。毕业季最后几天，几百个学生同时点击提交，如果没有控制，很容易出现重复提交、文件丢包、状态错乱。

我的方案是三管齐下：

第一，paper_info表为student_id建唯一索引，并且status不能是“草稿”状态。也就是说，一名学生同一时间只能存在一条非草稿的主记录。想重复提交必须走“重新提交”逻辑，先关闭旧记录。

第二，状态流转统一用乐观锁。更新SQL里带上WHERE status = #{expectStatus}，影响行数为0就说明状态已经被别人改过了，直接抛出“当前状态已发生变化，请刷新页面”。

<update id="changeStatus"> UPDATE paper_info SET status = #{newStatus}, current_version_id = #{newVersionId} WHERE id = #{paperId} AND status = #{expectStatus} </update>

第三，文件上传单独做幂等。上传接口会先计算文件的MD5，如果同一个学生已经在当前版本上传过同MD5的文件，直接返回“文件已存在，请勿重复上传”，避免学生手滑连点两次产生两份相同文件。

这里还有个小技巧：审核接口也要用版本号校验。导师审核时前端会带上传入 versionId，后端必须核对这个版本确实是当前版本，否则可能出现导师审核的是旧版本、学生已经提交新版本的情况。这个校验不加上，后面扯皮会非常严重。

4.3 文件上传与存储路径规划

论文文件以PDF和Word为主，单文件一般在5MB到30MB之间。我当时的存储方案很简单：上传到服务器本地目录/data/paper-files/{year}/{paperId}/，按年份和论文ID分目录，文件名改为uuid.pdf，原始文件名存到数据库。这样做的好处是：文件系统天然支持目录隔离，不依赖第三方存储，迁移时只需要打包目录。

上传接口用Spring的MultipartFile，做三重校验：

• 后缀名校验：只允许.pdf, .doc, .docx；
• MIME类型辅助校验：不允许只认后缀，因为后缀可以随便改；
• 大小限制：单文件不超过50MB，Spring配置里设置max-file-size和max-request-size。

spring: servlet: multipart: max-file-size: 50MB max-request-size: 100MB

文件存储路径不要写在业务代码里，用一个FileProperties配置类管理，并且下载接口提供带时效的Token校验，不能直接把文件路径暴露出去。别人直接拿https://xxx/paper-files/2024/1/xxx.pdf就能下载所有论文，这种安全问题上线前一定要自查。

4.4 审核流水的写法和MyBatis动态SQL

审核相关的操作我封装成了一个ReviewService，核心方法就是submitReview和withdrawPaper。每次审核都会做两件事：插入review_record流水 + 更新paper_info状态。两步必须放在同一个事务里，任何一步失败都要回滚。

@Transactional(rollbackFor = Exception.class) public void submitReview(Long paperId, Long versionId, Long reviewerId, String action, String comment) { PaperInfo paper = paperMapper.selectByIdForUpdate(paperId); // 校验状态机允许的流转，比如 REVIEWING 状态下才允许通过或退回 PaperStatus targetStatus = PaperStatusTransition.getTarget(paper.getStatus(), action); if (targetStatus == null) { throw new BusinessException("当前状态不允许执行该操作"); } reviewRecordMapper.insert(buildRecord(paperId, versionId, reviewerId, action, comment)); paperMapper.changeStatus(paperId, targetStatus.getCode(), paper.getStatus()); }

动态SQL主要体现在论文列表查询上。管理员列表页有很多筛选条件：学号、姓名、院系、状态、提交时间范围。如果直接拼接SQL字符串，一是SQL注入风险，二是条件一多代码就变成一团乱麻。MyBatis的<where>+<if>标签正好解决这个问题：

<select id="selectPaperPage" resultType="com.xxx.paper.dto.PaperQueryDTO"> SELECT p.id, p.paper_no, p.title, u.student_no, u.name AS student_name, p.status, p.submit_count, p.create_time FROM paper_info p LEFT JOIN sys_user u ON p.student_id = u.id <where> <if test="studentNo != null and studentNo != ''"> AND u.student_no LIKE CONCAT('%', #{studentNo}, '%') </if> <if test="title != null and title != ''"> AND p.title LIKE CONCAT('%', #{title}, '%') </if> <if test="status != null"> AND p.status = #{status} </if> <if test="startTime != null"> AND p.create_time &gt;= #{startTime} </if> <if test="endTime != null"> AND p.create_time &lt;= #{endTime} </if> </where> ORDER BY p.create_time DESC </select>

这种写法既安全又清晰，是我个人比较推荐的MyBatis使用姿势。要注意的是，动态SQL里的<和>一定要转义成<>，否则XML解析直接报错，这也是新手最容易踩的坑之一。

5. Vue前端实现：从表格页面到审核工作台

5.1 路由、权限与请求拦截器

前端工程结构我按业务角色划分，路由表里声明了三个主要模块：学生端、导师端、管理员端。学生端只有“我的论文”和“提交论文”，导师端有“待审核列表”和“已审核列表”，管理员端有“论文总览”“审核监控”“用户管理”。

路由守卫是前端的“第一道门”：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('paper_token'); if (!token && to.path !== '/login') { next('/login'); return; } const role = localStorage.getItem('paper_role'); if (to.meta.roles && !to.meta.roles.includes(role)) { next('/403'); return; } next(); });

Axios请求拦截器做了三件事：自动加Token、统一错误弹窗、401跳转登录页。响应拦截器里我特意处理了后端返回的业务异常码，比如10010表示当前状态已变化，会给出“请刷新后重试”的提示，而不是简单地把报错信息铺在页面上。

5.2 提交表单的校验与多文件上传

学生提交论文的表单字段包括：课题名称、专业方向、论文类型、论文摘要，以及主文件上传。这里我额外增加了一个“论文附件”上传，用于存放查重报告或原创性声明。

前端校验要做两件在服务端很难优雅实现的事情：文件类型检查和文件大小预检。虽然后端已经校验了，但把校验前置，能让学生在上传瞬间就发现问题，而不是等500错误。

const beforeUpload = (file) => { const allowTypes = ['application/pdf', 'application/msword', 'application/vnd.openxmlformats-officedocument.wordprocessingml.document']; if (!allowTypes.includes(file.type) && !/\.(pdf|doc|docx)$/.test(file.name)) { Message.error('仅支持PDF、Word文件'); return false; } if (file.size > 50 * 1024 * 1024) { Message.error('文件大小不能超过50MB'); return false; } return true; };

用Element Plus的el-upload，通过http-request自定义上传方法，覆盖默认行为，从而方便加进度条和Token请求头。上传成功后，将返回的文件ID存到表单隐藏字段，提交论文时才真正把这些文件ID关联到主记录上。这里必须保证“先传文件再提交记录”，否则会出现提交记录成功但文件丢失的半成品状态。

5.3 审核工作台：状态筛选、行内操作与批量操作

导师端的审核工作台是使用频率最高的页面，体验好坏直接决定系统是否被接受。我做的是左树右表：左侧按学生院系分类，右侧是论文列表，列表支持按状态、时间、是否已读筛选。

每行论文提供“审核”“下载文件”“查看历史版本”三个操作入口。审核弹窗里展示：当前论文基本信息、最新版本的文件名、大小、上传时间，以及一个文本域让导师填写意见。导师点击通过或退回，前端调审核接口，成功后立即刷新当前列表并清空筛选条件中对应的状态项。

批量操作我也加了，主要用于管理员：批量归档、批量导出汇总表。批量操作最容易出现的坑是“部分成功部分失败”。我的策略是：前端逐条调用接口，而不是一次性传ID数组给后端；每调完一条，就更新这一行的状态，失败的行标红并提示原因，这样用户知道到底哪几条失败了、为什么失败。

5.4 前端性能：虚拟滚动与大表格缓存

论文列表在管理员端可能有上万条数据。如果直接把所有数据查出来渲染成DOM，浏览器直接卡死。分页是必须的，但分页在审核场景下也有问题：导师经常连续审核几十条，每换一页就重新请求一次，体验很碎。我在前端做了一层“列表缓存”：用keep-alive缓存列表页组件，翻页后返回列表不重新请求；审核成功后将当前行数据从列表中标记为已审核，并显示绿色状态，而不是粗暴地刷新整个列表。

至于数据量特别大的导出场景，我建议不要前端导出所有字段，而是把筛选条件传回后端，由后端异步生成Excel，再提供下载链接。前端直接包一条导出接口跑半天，这在企业级系统里是致命的体验问题。这个方案后面部署时还解决了内存溢出的问题，我在第六节会细说。

6. 性能、安全与踩坑实录：上线前必须解决的问题

6.1 分页查询慢：从全表扫描到索引优化

第一个线上问题发生在压力测试阶段：管理员论文总览页，接口响应时间从200ms直接飙升到6秒。我查了慢SQL日志，发现ORDER BY create_time导致文件排序，加上LEFT JOIN sys_user关联，导致临时表非常大。

排查链路是这样的：

1. 用EXPLAIN SELECT...看执行计划，发现paper_info表走了全表扫描，type=ALL；
2. 检查索引，发现只建了主键索引；
3. 分别加idx_status(status)、idx_create_time(create_time)、idx_student_id(student_id)；
4. 再次执行计划，type变成了range，Extra里不再出现Using filesort。

加完索引后，同样的查询压测从6秒降到了350ms。这里想提醒一句：不要迷信“数据量小不需要索引”，论文系统一年数据量不大，但毕业季三个月的数据可能集中爆发，尤其是多条件筛选场景，索引缺失会让整个系统在高峰时段崩掉。

6.2 并发提交带来的重复数据问题

第二坑是学生反复点击提交按钮，产生了多条paper_info记录。当时我先加的是前端按钮防抖:loading状态，把提交按钮在请求期间设为禁用，但很快发现这并不能彻底解决问题——有人用脚本直接调接口。

最终修复在后端：paper_info表加了student_id的唯一索引，并且调整了提交逻辑，不再用“先查再插”，而是直接INSERT ... ON DUPLICATE KEY UPDATE处理，同时在事务里用SELECT ... FOR UPDATE锁行。这个组合拳打下去，重复提交基本被杜绝。顺便说一句，并发场景只靠前端防抖或只靠唯一索引都不够，前端防抖是体验，后端锁是底线。

6.3 XSS防护与文件类型安全

论文摘要、审核意见都是文本域，如果不处理直接入库再渲染回页面，容易被注入脚本。我在后端做了一个全局的XSS过滤：对请求参数里的<script>、javascript:等危险关键字做HTML转义，同时在前端渲染时尽量用textContent而不是v-html。对教育行业系统来说，安全合规很重要，这类漏洞一旦被审计出来，会很麻烦。

文件类型安全也踩过坑。学生上传一个改后缀的exe，虽然校验通过，但实际内容是可执行文件。我的补救方案是用Apache Tika做内容级MIME检测，或者至少解析文件头魔数。对于不太重要的系统，一个简单的方案是：文件保存时用Files.probeContentType再确认一次，但要注意这个API在某些系统上并不完全可靠，核心文件还是建议Tika。

6.4 部署后常见线上问题

部署到生产环境后，其他小坑也不少，这里挑三个最常见的：

• 时区问题：MySQL连接串里没写serverTimezone=Asia/Shanghai，导致时间差8小时。这个我在第一周就遇到过，数据库时间全对不上。
• 磁盘打满：文件没做定时清理，测试环境传了几百个PDF，磁盘直接满了。后来加了一个定时任务，每天扫描临时目录，删除7天前未关联正式论文记录的文件。
• 跨域问题：前端开发时用http://localhost:5173访问，后端运行在8080端口，必须配CORS。上线后用Nginx同域反代，跨域就消失了。

7. 部署上线与日常运维：一套完整的落地流程

7.1 环境初始化与初始化数据

系统准备好后，部署时我建议用一台4核8GB的云服务器，操作系统用Linux。MySQL单独跑在同一台机器的Docker里，Java服务用systemd管理，前端静态文件交给Nginx。初始化脚本要做三件事：建库建表、导入初始管理员账号、初始化字典数据。

管理员账号的密码必须用BCrypt加密后导入，我吃过明文密码的亏，一台测试机被扫到弱口令入侵，从那以后所有初始化数据都强制加密。

7.2 前后端打包与Nginx反代配置

前端构建：

npm run build

构建产物在dist/目录，把这个目录上传到服务器/var/www/paper-web/。后端工程用Maven打成jar包：

mvn clean package -DskipTests

关键配置就在Nginx上，我贴一份核心配置：

server { listen 80; server_name paper.example.com; root /var/www/paper-web; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_read_timeout 120s; client_max_body_size 100m; } location /files/ { alias /data/paper-files/; internal; # 内部跳转，不直接暴露文件下载地址 } }

注意两点：一是client_max_body_size要大于Spring配置的文件上传限制，否则Nginx会先把请求拦下来，返回413；二是下载文件要放在internal内部location里，由后端生成带签名的临时URL来跳转，避免论文文件被爬虫或搜索引擎收录。

7.3 备份策略与监控提醒

论文系统最重要的资产就是数据和文件，备份方案是每天凌晨3点对MySQL做全量dump，文件目录用rsync同步到另一台备份机或者对象存储。备份保留近30天，保留策略用脚本自动清理久于30天的文件。

监控方面没有上太重的东西，我写了一个简单的Shell脚本，每分钟检查Java进程和Nginx进程是否存活，挂了就自动重启，并把告警消息推到钉钉群。真正上线后，这套“轻量监控”反而比重量级APM更有用，因为论文系统的压力模型很清晰——毕业季流量高，其他时间基本平稳，一个简单的探活脚本足以应对99%的问题。

一点实践心得

这套系统从前到后走完，前后用了一个半月。回头复盘，最大的收获倒不是技术，而是在一套真实业务里摸清了“数据流”和“状态流”该怎么拧成一股绳。论文管理系统听起来简单，但真正难的是那些看不见的部分：状态机的边界、并发控制、文件版本的追溯、部署后被人访问时的安全防线。如果一个系统看不到历史、防不住并发、挡不了误操作，代码写得再花哨都只是Demo，不是产品。

最后分享一个亲测有用的建议：开发这类系统时，先别急着写代码，和真实的业务方坐在一起，把他们现在用U盘、QQ传文件的整个过程完整走一遍。你会发现，纸上流程图里永远画不出来的“老师让我先交电子版再补纸质版”这类柔性场景，才是最影响系统成败的细节。把那些柔性场景转化成状态机和版本记录里的字段，才是这套源码真正的价值所在。希望这篇分享能帮你少走一些弯路。