简介：一份面向科研管理场景的科技项目在线评审系统完整项目包，以Java Web技术栈实现项目申报、专家评审、进度跟踪、资源共享、绩效评估与报表统计等核心功能，面向高校科研人员、评审专家和管理者，也适合正在学习Java Web开发、准备毕业设计或课程项目的学生参考。压缩包共包含909个文件，约1.61MB，其中java源码与class编译类文件构成业务逻辑层，html、css、js负责前端展示与交互，png、gif等图片资源用于界面元素，整体结构清晰，可直接部署运行或对照阅读。目前已有76人浏览学习。资源除可运行的编译类文件外，还保留了源码、配置文件和数据库脚本，便于二次开发与功能扩展；前端页面覆盖登录认证、项目申报、在线评审、后台管理、数据报表等多个典型场景，能帮助读者快速梳理在线评审业务的模块划分与实现细节，也可作为科研管理信息化系统搭建或改进的参考起点。
1. 科技项目在线评审系统：从建表到出分的一条龙方案
拿到一个名为“科技项目在线评审系统.zip”的压缩包，大多数人的第一反应是“这不就是给申报表做个网页收集功能，再让专家打打分么”。真把这个系统落地过的人都知道，在线评审系统最容易翻车的环节根本不在页面，而在流程状态流转、专家分数可信度、以及公示阶段的数据可追溯性。一个评审周期往往横跨两个月，管理员、申报人、评审专家、监督员四类角色在同一套数据模型上并行操作，哪怕一个状态位设计得不够严谨，都会造成评分被覆盖、结果对不上、申诉无据可查的连环事故。
这套系统的核心价值，是把线下评审中“发材料、收打分表、人工汇总、公示复议”这一整套低效流程，压缩成一套可配置、可审计、可复核的在线闭环。对科技管理部门而言，它解决的是评审过程透明度；对申报单位而言，它解决的是进度反馈和申诉通道。适合谁来部署？高校科研处、医院科研科、企业项目管理部门，以及专门承接第三方评审服务的机构。下面我按自己做过的多套此类系统，把这套系统的设计要点、核心代码骨架和最容易踩的坑逐一拆开讲。
2. 评审流程与权限设计：先画状态机再写接口
2.1 评审业务流程拆解：申报、分组、指派、打分、汇总
在线评审系统不是一个简单的 CRUD 应用，它背后是一条严格线性的业务流：申报人提交项目书，管理员做形式审查，通过后进入专家分组与指派阶段，专家在限定时间内完成打分，管理员汇总分数并生成排序建议，最后公示并处理申诉。任何一步跨序操作都会产生脏数据——例如专家还没指派完就生成汇总表，或者申报人在评审中还能修改项目书，都会把评审结果推向不可信。
我一般会在写第一行代码前，先用状态机把全流程枚举清楚。推荐用一套整型状态字段来驱动流转，而不是用一堆布尔值组合。以下是我在实际项目里常用的一套状态定义：
- 0：草稿，申报人可编辑。
- 10：已提交，等待形式审查。
- 20：形式审查通过，进入专家分组。
- 30：已分配专家，等待评审。
- 40：评审中，至少一名专家已提交打分。
- 50：评审完成，全部专家已打分。
- 60：已汇总，分数与排序已生成。
- 70：已公示，接受申诉。
- 80：已归档，流程结束。
很多团队最初会图省事用 status + is_passed + is_reviewed 这类并列字段，这会在后期吃大亏。并列布尔字段难以控制非法组合，例如 is_passed=1 同时 is_reviewed=0 这种状态根本无法识别是哪个环节。单一状态字段配合合法性校验函数，才能保证任何时候看数据都知道项目处在哪个阶段。
2.2 账号与权限矩阵：四种角色不互相串门
在线评审系统的权限设计不复杂，但必须在数据层面就把边界堵死。我按四类角色划分：申报人（项目负责人）、形式审查员（管理员）、评审专家、监督员。每类角色能触碰的数据范围要尽可能收敛，尤其是评审专家，绝对不能访问项目申报书以外的申报人敏感信息，否则容易引发利益冲突的质疑。
实际项目中我会在用户表上挂 role 字段，并且在前端路由、后端接口、数据查询三层都做权限校验，只依赖其中一层都会留下越权漏洞。下面是一份典型的角色权限模板，可以直接抄来改：
| 角色 | 可操作内容 | 不可见内容 |
|---|---|---|
| 申报人 | 编辑本人项目、查看评审状态、提交申诉 | 其他申报人项目、专家信息、评分明细 |
| 形式审查员 | 审查申报资格、指派专家、启动汇总 | 专家评分过程数据 |
| 评审专家 | 查看被指派项目、录入评分、填写意见 | 其他专家的打分、申报人联系方式 |
| 监督员 | 查看全流程日志、导出审计记录 | 无限制（只读） |
这套矩阵还有一个关键点：专家的打分对申报人只能呈现“分项明细”，不能呈现“专家个人评分表”。线上评审的常见争议就是申报人要求公布每位专家给的分数，但实际操作中大多数评审规则只允许公布汇总后的分项均分，这一点要在系统设计时预埋。
2.3 评审配置的数据结构：指标、权重、档位怎么落库
评审指标体系是系统的“业务灵魂”。每个评审批次可以配置一套独立指标，例如：一、项目创新性（30%）；二、研究方案可行性（30%）；三、研究基础与条件（20%）；四、预期成果与应用前景（20%）。每个指标下设评分档位，如优秀（90-100）、良好（80-89）、合格（70-79）、不合格（70以下）。
落库时我建议使用三张表来承载：review_batch（评审批次表）、review_indicator（指标表）、review_indicator_option（档位表）。其中批次表存基本信息，指标表存指标名称、权重、排序号，档位表存每个指标的档位说明与分数区间。不要把档位写死在指标表的文本字段里，否则后期调整档位阈值时全部历史数据都会跟着错乱。
一个批次下可以存在“项目类型”的维度，例如基础研究、应用研究、软科学，不同类型对应不同指标集。那么指标表和批次、项目类型之间要建立多对多关联，用关联表 review_batch_indicator 来维护，字段设计为：batch_id、project_type、indicator_id、weight。这样同一个批次下可以容纳多种评分维度，又不破坏历史数据的稳定性。
3. 核心功能落地：从建表到出分的实现细节
3.1 数据库初始化脚本：五张核心表的建表语句
在线评审系统的核心数据表远比“一个申报表、一个打分表”要多。我把必须初始化的五张表列在这里：project_info（项目申报信息）、expert_info（专家库）、project_expert_assignment（项目与专家关联）、review_score（评分明细）、review_status_log（状态流转日志）。下面给出 MySQL 风格的建表语句，实际使用时光照这个结构改字段长度即可。
CREATE TABLE project_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT, project_no VARCHAR(32) NOT NULL COMMENT '项目申报编号，唯一', project_name VARCHAR(200) NOT NULL COMMENT '项目名称', applicant_uid BIGINT NOT NULL COMMENT '申报人用户ID', project_type TINYINT NOT NULL DEFAULT 0 COMMENT '项目类型：0基础研究/1应用研究/2软科学', status TINYINT NOT NULL DEFAULT 0 COMMENT '评审状态：0草稿/10已提交/.../80已归档', submit_time DATETIME DEFAULT NULL COMMENT '提交时间', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_project_no (project_no), KEY idx_status (status) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='项目申报信息表'; CREATE TABLE expert_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT, expert_uid BIGINT NOT NULL COMMENT '专家用户ID', real_name VARCHAR(50) NOT NULL COMMENT '专家姓名', field_code VARCHAR(50) NOT NULL COMMENT '学科领域编码', is_active TINYINT DEFAULT 1 COMMENT '是否在库可用', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_field (field_code) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='专家信息表'; CREATE TABLE project_expert_assignment ( id BIGINT PRIMARY KEY AUTO_INCREMENT, project_id BIGINT NOT NULL COMMENT '项目ID', expert_id BIGINT NOT NULL COMMENT '专家ID', assigned_by BIGINT NOT NULL COMMENT '指派人用户ID', assigned_at DATETIME DEFAULT CURRENT_TIMESTAMP, review_status TINYINT DEFAULT 0 COMMENT '专家评审状态：0未开始/1已打分', UNIQUE KEY uk_project_expert (project_id, expert_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='项目专家关联表'; CREATE TABLE review_score ( id BIGINT PRIMARY KEY AUTO_INCREMENT, assignment_id BIGINT NOT NULL COMMENT '关联表ID', indicator_id BIGINT NOT NULL COMMENT '评审指标ID', score_value DECIMAL(5,2) NOT NULL COMMENT '专家打的分数', comment_text TEXT DEFAULT NULL COMMENT '分项评语', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_assignment (assignment_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='评分明细表'; CREATE TABLE review_status_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, project_id BIGINT NOT NULL, from_status TINYINT NOT NULL, to_status TINYINT NOT NULL, operator_uid BIGINT NOT NULL COMMENT '操作人用户ID', remark VARCHAR(500) DEFAULT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_project (project_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='状态流转日志表';project_expert_assignment 表中的 UNIQUE KEY（project_id, expert_id）非常重要，它能把“同一个专家被重复指派给同一项目”这种配置错误直接挡在数据库层。review_score 表没有直接关联 project_id，而是通过 assignment_id 间接关联，这样专家每次打分都能精确落位到某个项目，不会因为路径冗余导致分数归属混乱。
3.2 评分汇总算法：去掉异常值再加权平均
评审汇总阶段最常见的需求是“去掉一个最高分和一个最低分，再按权重加权平均”。这个逻辑看起来简单，但实现时会有不少边界条件：某个指标下只有三位专家打分、专家数量只有两人、存在专家弃权的指标等。下面给出一个可用的 Python 实现，处理了这些边界情况。
# 汇总项目得分：剔除每个指标下的最高/最低分后加权平均 def calc_project_score(scores_by_indicator: dict, indicator_weights: dict) -> float: total_score = 0.0 total_weight = 0.0 for indicator_id, scores in scores_by_indicator.items(): # 指标权重 weight = indicator_weights.get(indicator_id, 0) if weight <= 0: continue # 专家人数少于3人时不剔除最高最低，直接取均值 if len(scores) < 3: avg_score = sum(scores) / len(scores) else: sorted_scores = sorted(scores) trimmed = sorted_scores[1:-1] # 去掉最低和最高各一个 avg_score = sum(trimmed) / len(trimmed) total_score += avg_score * weight total_weight += weight if total_weight == 0: return 0.0 return round(total_score / total_weight, 2)这段代码把“剔除异常值”的逻辑集中在指标维度，而不是在项目总分组维度。因为直接对总分剔最高最低会掩盖单个指标内的极端打分；按指标剔除才能让每个维度的评议都相对稳健。调用前需要把权重参数从数据库读出并格式化为字典，且要校验权重总和是否为 100，防止配置错误导致算出的分数偏低。
另一个隐藏逻辑是：当某个指标的专家打分缺失率达到 40% 以上时，这个指标的均分是否仍然可信？我的处理习惯是在汇总时同时输出“最终分数”和“有效样本数”，如果有效样本数不足，在结果列表里标记为“样本不足，仅参考”。这个标记在后续排序和公示中能减少很多争议。
3.3 评审状态流转控制：防止重复打分与中途篡改
线上评审中“专家改了又改”和“管理员误触发状态跳转”是最频繁的事故源。解决方案很直接：所有状态变更走统一接口，不做散装 UPDATE。下面这段 JavaScript(Node.js) 伪代码展示了后端如何校验状态流转合法性。
// 状态流转校验：合法迁移表驱动，杜绝任意的状态跳转 const TRANSITIONS = { 0: [10], // 草稿 -> 已提交 10: [0, 20], // 已提交 -> 撤回草稿 或 形式审查通过 20: [30], // 审查通过 -> 分配专家 30: [40], // 分配完成 -> 进入评审中 40: [50, 30], // 评审中 -> 完成 或 退回重新分配 50: [60], // 评审完成 -> 汇总 60: [70, 50], // 已汇总 -> 公示 或 返回重汇 70: [80, 60], // 公示中 -> 归档 或 退回修改 80: [] // 已归档，终态 }; function transition(project, nextStatus) { if (!TRANSITIONS[project.status] || !TRANSITIONS[project.status].includes(nextStatus)) { throw new Error(`非法状态跳转: ${project.status} -> ${nextStatus}`); } // 执行状态更新并记录日志 return { ok: true, from: project.status, to: nextStatus }; }这段代码的核心是把状态迁移图显式定义出来，让非法跳转在第一时间抛错。比散落在业务代码里十几个 if 判断可读性强得多，也让后来接手的人不敢乱加判断。配合 review_status_log 表，每次迁移都有操作人、时间、原因，出了问题可以直接回溯。
另外要补充的是并发干扰问题：专家提交打分和管理员撤回“评审中”状态同时发生时，很容易出现打分写完后又被状态回退，导致专家看到“未打分”但数据库里其实有分数。解决办法是在提交打分的事务里加一个条件：UPDATE project_expert_assignment SET review_status=1 WHERE id=? AND review_status=0。若影响行数为 0，说明本次打分已被撤回，前端就提示“该轮评审已重新分配”。
3.4 消息通知与评审进度跟踪：给专家和管理员的待办清单
评审周期里最消耗管理员精力的事就是“催办”。每个专家手里五到十个项目，哪个评了哪个没评，靠 Excel 来回发实在太原始。系统里至少要内置一个待办中心：专家登录后看到“待评审项目清单”，管理员看到“每位专家的已评/未评数量”。
待办数据的生成建议做实时查询而非物化表，因为评审周期短、数据量小（通常几百个项目），物化表反而引入同步延迟问题。一个常用的 SQL 统计查询是：
SELECT e.id AS expert_id, e.real_name, COUNT(a.id) AS total_count, SUM(CASE WHEN a.review_status = 1 THEN 1 ELSE 0 END) AS finished_count FROM expert_info e LEFT JOIN project_expert_assignment a ON a.expert_id = e.id WHERE e.is_active = 1 GROUP BY e.id, e.real_name ORDER BY finished_count / total_count ASC;这条 SQL 按“完成进度升序”排序，管理员一眼就能看出谁还没开工。需要注意 LEFT JOIN 的使用，否则没有分配任何项目的专家会被过滤掉，待办看板就不完整。催办逻辑可以做成每天上午九点扫描一次，给未完成专家推送一条待办提醒；但千万别做成实时触发，否则每分配一个项目就发一次提醒，专家很快就把消息屏蔽了。
4. 部署与使用避坑：评审系统最容易翻车的高危场景
4.1 状态栏显示“已汇总”但分数为空：汇总任务静默失败
现象：管理员点击“生成汇总”后，系统显示汇总完成，但项目列表里的总分一栏为空，导出结果里也只有分项分数没有总分。
原因：绝大多数情况下是评分明细表里存在“已初始化但未打分”的空记录。例如专家进入打分界面后只保存了评语，没提交分数；或者表单里分数输入框被前端校验清空但记录仍被INSERT。汇总算法遍历到这些空分数时直接抛异常或产生 NULL，任务管理器把异常吞掉只更新了状态位。
解决：在汇总前加入校验步骤，先把异常数据检测出来：
SELECT assignment_id, COUNT(*) AS invalid_rows FROM review_score WHERE score_value IS NULL OR score_value < 0 OR score_value > 100 GROUP BY assignment_id;汇总逻辑改成两阶段：先执行业务校验，校验不通过时返回错误列表而不是标记完成。同时将汇总任务的执行结果写入日志表，任何一步失败都要留下可查看的错误信息，绝不静默处理。
4.2 专家分两次提交打分，第二次覆盖了第一次的评语
现象：专家反馈第一次提交时漏填了某项评语，重新进入补填后再次提交。结果总分没变，但第一次写的一整段评语丢了。
原因：代码里实现“保存评分”用了 DELETE + INSERT 策略。每次提交都先删除该专家该项目的所有评分记录再重新插入。这样虽然简单可靠，但会把中途未提交的评语草稿一并清掉。如果专家在第一次提交后对某项指标单独写过补充意见，这个意见不是通过正式表单提交而是系统内部的 draft 表，就会在 DELETE 时被连带清理。
解决：评分保存改为 UPDATE + INSERT 的方式。每条 review_score 记录保存时先按 assignment_id + indicator_id 做 UPDATE，若影响行数为 0 则 INSERT。这样专家的历史评语才能保留。同时表结构里要区分“草稿”和“正式提交”字段，避免专家保存一半时数据被误读成有效评分。
4.3 项目明细附件导出乱码：文件名变成了“%E9%A1%B9%E7%9B%AE”这类字符串
现象：管理员从后台导出申报书附件，下载下来的文件名是一长串 URL 编码字符，Windows 上打开时中文名完全丢失。
原因：后端对文件名做了 URL 编码用于传输，但前端下载时没有 decode；或者后端生成下载响应头时没有设置正确的 Content-Disposition。浏览器按原始 URL 编码名称保存，中文自然乱掉。
解决：在后端设置 Content-Disposition 时用 RFC 5987 规范：
from urllib.parse import quote filename = quote(project_name) + '.pdf' response.headers['Content-Disposition'] = f"attachment; filename*=UTF-8''{filename}"同时在前端下载时，如果拿到的是文件流，就显式用后端返回的文件名。不要把文件名交给前端 JS 自己猜，十有八九会猜错编码。
4.4 评审批次复制后，历史项目的指标权重被一起改掉
现象：管理员创建新一批评审时，复制了上一批的项目类型和指标配置。复制完成后，上一批已经公示完的旧项目总分全部变了。
原因：指标关联表 design 时共用了一份权重记录，新批次复制时只改了 batch_id 但没有新建 indicator_id，导致新旧批次指向同一组权重记录。后续调整权重时把旧数据也一并更新。
解决：批次复制时必须执行深层复制，关联表要生成新的 indicator_id，而不是沿用旧指标。同时在权重更新入口做保护：若批次状态大于 50（已汇总），禁止修改权重并提示先归档或复制新批次。这样就把数据不可变的边界放到业务层，而不是依赖操作者自觉。
4.5 监督员导出审计日志时，日志文件过大导致页面卡死
现象：年度评审结束后，监督员要导出全量操作日志，每次点击都转圈几分钟，最后浏览器报“无响应”。
原因：日志表没有做分区或归档，一年下来几十万条记录全量导出，单次查询把数据加载到内存后拼接 CSV 再返回，服务端和客户端双双崩溃。
解决：给导出功能增加时间范围筛选和分批导出的机制。监督员先选起止日期，系统按天分批写文件，最后打包下载。同时在日志表的 created_at 字段上建好索引，避免全表扫描。这一步看似简单，实际部署时很多团队把它留到上线后才发现，属于典型的设计时欠账。
5. 评审数据的导出、公示与审计：让结果经得起复核
5.1 评审结果导出：解决 Excel 打开乱码的老毛病
评审结果导出是每个管理员都会反复使用的功能。最稳妥的做法是把文件生成为 CSV 而不是 xlsx，因为 CSV 可以被 Excel、WPS 以及各种脚本直接读取，不容易出现格式兼容问题。但 CSV 有一个经典坑：Excel 打开 UTF-8 编码的 CSV 文件时中文乱码，原因是 Excel 默认按本地编码解析无 BOM 的 UTF-8 文件。
我的导出实现里会在文件开头写入 BOM 标记：
import csv def export_result_csv(rows, file_path): with open(file_path, 'w', encoding='utf-8-sig') as f: writer = csv.writer(f) writer.writerow(['项目编号', '项目名称', '总分', '排序', '状态']) for r in rows: writer.writerow([r['project_no'], r['project_name'], r['total_score'], r['rank'], r['status_name']])写文件时使用 utf-8-sig 编码，相当于自动加上 BOM。导出后的文件用 Excel 双击打开，中文标题和内容都不会乱。如果导出对象是 xlsx，还需要注意单元格文本格式问题——项目编号这类字段容易被 Excel 自动识别为数字，丢失前导零或变成科学计数法。一般做法是导出的项目编号列强制写成文本格式，例如在前面拼一个单引号或在代码里设置 cell format。
5.2 公示与申诉流程：用状态字段驱动页面变更，不要在页面写死逻辑
公示期是评审系统最容易出现“展示与实际不一致”的阶段。展示页面里写着“公示中”，数据库里的项目状态实际已是“已归档”；申诉人提交申诉，管理员回复后状态没变，用户反复提交相同申诉。这些都是典型的“页面逻辑与状态脱节”问题。
我建议公示与申诉绑定在 project_info.status 字段上。页面只根据 status 渲染不同的界面区块：
- status = 70 时，显示“公示中”以及申诉提交按钮。
- status = 80 时，显示“已归档”，不再显示申诉入口。
- 申诉提交后，写一条 review_appeal 记录，并把 status 暂时切回 65（申诉处理中），处理完后再回到 70。
申诉表 review_appeal 的字段包括项目 ID、申诉人 ID、申诉内容、回复内容、处理人、处理时间、状态。整个申诉流程严格遵循“提交-处理-回复-归档”的线性状态流。公示页面的所有展示逻辑都按状态驱动，避免出现“数据已经处理但页面没刷新”的问题。
5.3 操作日志与审计：把每一次操作变成可重建的证据链
评审系统上线一段时间后，监督员最多的需求是“查一下某个项目在哪一步被谁改过”。如果日志记录不完整，这种排查几乎无法完成。我设计 review_status_log 表时专门加了一个字段 prev_data_snapshot 来存放操作前的关键数据快照，例如修改前的分数、修改前的批次号。每次操作前先快照，操作后再写日志，这样即使有人误改了数据，审计人员也能知道原值是什么。
快照字段建议存 JSON 字符串，只保留业务关键字段，不把整行大字段塞进去。例如专家修改分数时，快照内容只需要记录当时的 score_value 和 comment_text，不用把整个项目申报书都复制一份。这样既控制了日志表体积，又足够支撑复查。
日志的展示要区分“谁在什么时候看到了什么”和“谁在什么时候改了什么”。前一类是访问日志，后一类是变更日志。监督员更关心后一类。在权限配置项里，我把“变更日志查看”单独开给监督员，不占用管理员的权限范围，避免管理员自己也能删改日志的印象。所有的日志修改操作都走审计接口，不允许直接打开数据库改数据，这是底线。
6. 把系统打磨成生产级工具的三个进阶配置
6.1 给评审配置快速的合理性校验器
指标体系配置是个“高权限低门槛”的动作，初学者也能进去增删指标。正因如此，配置错误的发生率非常高。一个常见的错误是权重合计写成 95 或 102，直到汇总功能跑出来分数偏低才发现。我给系统写了一个前置校验器，在保存指标时立刻校验：权重总计必须等于 100，指标数量必须在 3-8 个之间，每个指标的档位区间必须连续无重叠。校验不过就阻止保存，并把具体错误位置显示出来。做成后端校验的原因很简单：前端绕过很容易，后端校验才是真正的闸门。
6.2 给评审过程设置快速完成的异常标记
线上评审有一个线下评审没有的问题：专家可能在线“秒评”。一分钟内给十个项目连续打分，分数还都很接近，这种数据基本没有评审价值。我的做法是在打分提交接口里记录“进入页面时间”和“提交时间”，每次提交时校验页面停留时间。如果某项评分的停留时间低于 30 秒，就打上 suspicious 标记，不直接阻断提交，但管理员在汇总界面能看到“该条评分用时异常”的提醒。这个设计比直接拒绝打分更尊重专家体验，也让异常数据浮出水面而非混在正常数据里。
6.3 定时备份与灾难恢复演练
评审系统不像互联网应用那样流量巨大，但它的数据不可再生——专家打分一旦丢失，整个评审周期就要重来，损失远超一般业务数据。我部署时落地了一个系统级定时任务：每天凌晨两点执行数据库全量备份，保留最近 30 天；每周一对备份文件做一次恢复演练，把备份恢复到测试库，校验表数量和记录条数。做过一次恢复演练，你才会发现备份任务可能因为磁盘写满而连续静默失败五天。这不是技术难题，但疏忽一次就是事故。搭配备份的告警阈值也很简单：备份文件大小低于前一天的一半就发告警，基本能把大部分故障提前揪出来。
做过几套评审系统之后最大的体会是：这个系统的代码量不大，但每个环节都在考验对业务规则的理解。评分汇总算法可以临时写，但状态机设计、权限边界和审计追溯必须在开工前就想清楚。中途返工的成本，远超你想象。这套方案我前后迭代过好几次才稳定下来，希望帮到你少踩几步我踩过的坑。
本文还有配套的精品资源，点击获取
