每年评奖评优季，学校里最头疼的就是各类奖学金、荣誉称号的申报汇总。我见过太多用Excel来回传文件的场景：班长收一份、辅导员改一版、学院再整合一次，经常出现版本冲突，学生交的材料格式五花八门，评审环节的流转记录更是查无对证。这种状态持续了几年之后，我决定不再等了，直接基于SpringBoot+Vue+MyBatis+MySQL这套技术栈，从零做起一个前后端分离的评奖评优管理系统。源码完整、有配套部署教程，学生端提交申请、管理端发布奖项和审核、评审过程留痕、公示结果导出，这些都能在系统里闭环跑通。
这篇文章不是空谈架构，而是把我做这个项目的完整过程掰开揉碎：数据库表怎么设计、JWT登录认证怎么处理、Vue的token全链路怎么走、从本地到服务器怎么部署、联调时踩过哪些坑，全部讲清楚。适合三类人看：正在做毕业设计的学生、想系统上手前后端分离项目开发的初学者、以及学校里确实需要这类信息化工具的负责老师。不管你基础如何，只要跟着文章里每一章走，这套系统都能跑起来。
1. 评奖评优的业务痛点和前后端分离选型逻辑
1.1 旧模式下的评奖评优乱象
评奖评优这件事，看似是"按条件筛人、按名额定人"的简单流程，实际落地时牵扯的环节非常多。以优秀学生奖学金为例，通常时间线是：学校发布通知、学院收到名额、辅导员通知班级、学生准备材料、班级评议、辅导员审核、学院汇总、学校终审、名单公示。每个环节都涉及大量的信息登记、材料核验和意见流转。
传统手工作业的问题很典型。第一是数据重复填写，学生在申请表上填一遍个人信息，到了班级汇总表再填一遍，学院名单又填一遍，学号姓名专业这些字段反复录入，一旦中间某次抄错，后面核账就是灾难。第二是材料分散无法追踪，一个学生的成绩单、获奖证书、社会实践证明往往散落在不同邮件、不同微信聊天记录里，评审时很难快速查证。第三是评审过程不透明，谁在哪个环节批的、批了什么意见，全凭经办人记忆，出了问题说不清楚。
这些痛点的根子在于缺少一个统一的数据入口和流转载体。业务上需要一个系统，让学生只录一次信息，让评审链路上所有人都看到同一份数据，让每一次审核操作都留下痕迹。这是我做这个项目的业务出发点。
1.2 为什么选前后端分离而不是传统单体页面
技术选型阶段，我认真比较过两条路线：一是SpringBoot模版引擎渲染服务端页面，二是前后端彻底分离。最终选择后者的理由很实际。
前后端分离最直接的好处是并行开发效率高。前端同学拿着接口文档做页面，后端同学专注于接口和业务逻辑，互不阻塞。虽然单人开发时这种并行优势不明显，但项目边界清晰了，前端代码只关心渲染和数据交互，后端代码只关心接口和数据处理，每一边的复杂度都降了一个量级。
另一个原因是前端生态的成熟。Vue的组件化开发、Element UI的现成组件，做表单、表格、弹窗这类管理型页面几乎不用从零写样式，效率比JSP塞标签库高太多了。而且前端脱离开后端服务之后，页面部分完全可以独立部署到Nginx或CDN上，后续如果要做小程序端或者App端，后端接口是可以直接复用的，不需要推倒重来。
1.3 技术栈选型：为什么是SpringBoot+Vue+MyBatis+MySQL
技术栈的每一项，我都基于项目实际需求做过对比。
后端框架里，SpringBoot相比传统SSM省去了大量XML配置，内嵌Tomcat让应用一个java -jar就能启动，对单体管理系统的开发体验非常友好。Spring生态的整合能力也强，Spring Security、Spring Validation这些后面都能直接接进来。
持久层我用MyBatis而不是JPA，核心原因是这类管理系统有大量多条件组合查询和统计报表需求。MyBatis的SQL完全自己掌控，动态SQL标签可以很自然地拼出"按状态+奖项+学号模糊搜索"这种条件，性能调优时可以直接改SQL上索引，心里有底。JPA虽然开发速度快，但复杂查询的SQL生成不可控，排查问题还要先搞明白它生成的SQL长什么样，在这个场景下反而是负担。
前端选Vue是综合了学习成本、社区资料和生态。Vue的响应式机制上手快，Element UI把表格、表单、日期选择器、上传组件都备齐了，非常适合快速搭建后台管理界面。数据库选MySQL则是稳妥之选，开源免费、部署简单、资料丰富，学校场景的数据量完全不会成为瓶颈。
2. 核心表的拆解设计与关键SQL实战
2.1 需求驱动的表结构规划
评奖评优系统的数据模型，我按业务实体拆成了五张核心表：用户表、学生表、评奖项目表、申请记录表、评审记录表，外加一张公示信息表。
用户表承载登录账号和角色信息，学生表承载学生的基本信息，两者通过用户ID关联。评奖项目表描述"评什么奖"，包括奖项名称、评选学年、名额、申请开始结束时间。申请记录表描述"谁申请了什么奖"，存状态、申请材料路径、申请时间。评审记录表存历次评审意见和状态变更。
这个设计的核心思路是：申请数据是不断流转的，必须有独立的表记录每一次状态变化。很多入门项目会用一个字段存状态，把评审意见堆在一列里，这会导致两个问题——历史意见丢失、无法还原流转过程。评审记录表的存在让整条审核链路上每个环节的操作都有据可查。
2.2 五张表的建表SQL与字段设计说明
下面给出几张核心表的建表SQL，字段注释直接写在DDL里，方便后面对照。
CREATE TABLE sys_user ( id BIGINT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL UNIQUE COMMENT '登录用户名', password VARCHAR(100) NOT NULL COMMENT 'BCrypt加密后的密码', role VARCHAR(20) NOT NULL COMMENT '角色: STUDENT/COUNSELOR/ADMIN', student_id BIGINT DEFAULT NULL COMMENT '关联的学生ID，学生角色非空', status TINYINT DEFAULT 1 COMMENT '账号状态: 0禁用 1正常', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='系统用户表';CREATE TABLE student ( id BIGINT AUTO_INCREMENT PRIMARY KEY, student_no VARCHAR(20) NOT NULL UNIQUE COMMENT '学号', name VARCHAR(50) NOT NULL COMMENT '姓名', class_name VARCHAR(50) COMMENT '班级', major VARCHAR(64) COMMENT '专业', grade VARCHAR(10) COMMENT '年级', phone VARCHAR(20) COMMENT '手机号', email VARCHAR(64) COMMENT '邮箱' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学生信息表';CREATE TABLE award_project ( id BIGINT AUTO_INCREMENT PRIMARY KEY, award_name VARCHAR(100) NOT NULL COMMENT '奖项名称', academic_year VARCHAR(20) NOT NULL COMMENT '评选学年，如2024-2025', total_quota INT NOT NULL COMMENT '总名额', remaining_quota INT NOT NULL COMMENT '剩余名额', apply_start DATETIME NOT NULL COMMENT '申请开始时间', apply_end DATETIME NOT NULL COMMENT '申请截止时间', status TINYINT DEFAULT 0 COMMENT '0草稿 1已发布 2已截止 3已结束', description TEXT COMMENT '评选条件说明', created_at DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='评奖项目表';CREATE TABLE award_application ( id BIGINT AUTO_INCREMENT PRIMARY KEY, project_id BIGINT NOT NULL COMMENT '评奖项目ID', student_id BIGINT NOT NULL COMMENT '申请学生ID', materials_path VARCHAR(255) COMMENT '证明材料存储路径，多个用逗号分隔', reason TEXT COMMENT '申请理由', status TINYINT DEFAULT 0 COMMENT '0待初审 1通过 2退回 3已获奖', review_comment VARCHAR(255) COMMENT '最近一条评审意见', submit_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_project (project_id), KEY idx_student (student_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='申请记录表';CREATE TABLE award_review ( id BIGINT AUTO_INCREMENT PRIMARY KEY, application_id BIGINT NOT NULL COMMENT '申请记录ID', reviewer_id BIGINT NOT NULL COMMENT '评审人用户ID', old_status TINYINT NOT NULL COMMENT '评审前状态', new_status TINYINT NOT NULL COMMENT '评审后状态', comment VARCHAR(255) COMMENT '评审意见', created_at DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='评审记录表';这里有个设计细节值得说：申请记录表的review_comment字段存的是最新一条评审意见，方便列表页直接展示；但完整的历史意见都在award_review表里。这种"读时冗余、写时全量"的做法在中小型系统里很实用，避免了每次查列表都要去连评审记录表的开销。
2.3 状态机设计与时间的边界处理
状态是这个系统的灵魂。我前期设计时将申请状态定义为整型常量：0待初审、1通过、2退回、3已获奖。后来评审链路上发现必须区分"待班级初审"和"待学院审核"，于是拆成了更加细粒度的状态。实际编码时我建议把状态常量定义在枚举类里，避免魔法数字散落各处。
时间边界是另一个容易出错的地方。评奖项目表里有apply_start和apply_end两个时间字段，学生申请接口必须在"当前时间介于两者之间"时才能提交。这个判断如果放到应用层，要考虑服务器时区；我建议直接用数据库的NOW()和字段比较，让数据库统一处理时间基准。下面的SQL就是典型的判活写法：
SELECT * FROM award_project WHERE id = #{projectId} AND status = 1 AND NOW() BETWEEN apply_start AND apply_end这种写法既锁定了项目必须处于"已发布"状态，又完成了时间窗口判断，一次查询搞定，避免了先查出来再在Java里比来比去的繁琐逻辑和潜在误差。
3. SpringBoot+MyBatis后端：从JWT认证到动态SQL
3.1 后端项目结构与分层
后端工程我按Maven标准结构组织，包名用com.example.award。Controller层只做参数接收和结果包装，Service层处理业务逻辑，Mapper层直接与数据库交互。学生申请奖项的流程就是一个典型例子：Controller收到申请请求后，Service先校验项目状态和申请时间，再检查是否重复申请，最后插入申请记录装配返回结果。
@PostMapping("/awards/{projectId}/apply") public Result apply(@PathVariable Long projectId, @RequestBody ApplyRequest req) { Long studentId = UserContext.getCurrentUserId(); applicationService.submit(studentId, projectId, req); return Result.success(); }Service里几个校验缺一不可：项目是否存在、是否在申请窗口内、学生是否已经申请过同一个奖项。这些校验任何一个漏掉，都会在后续评审环节埋雷。重复申请的判断用一条count查询就能挡住，但要注意加唯一索引兜底，防止并发请求下数据库层面出现脏数据。
3.2 JWT登录认证的实现与拦截方案
登录认证我用的JWT，依赖选用jjwt库。用户在登录接口提交用户名密码，后端校验通过后生成token返回给前端。token里放userId和role两个核心声明，过期时间设置为24小时。为了支持前后端分离部署，认证信息不依赖Session，所有状态都由前端在请求头里携带。
JwtInterceptor实现了HandlerInterceptor接口，在preHandle里从Authorization头取出token并校验，无效就返回401。校验通过之后把userId存入ThreadLocal，方便Service层随时获取当前操作人。这个模式在管理系统中非常常用，相当于给每个请求都打上了"当前是谁在操作"的标记。
public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if ("OPTIONS".equalsIgnoreCase(request.getMethod())) { return true; } String token = request.getHeader("Authorization"); if (!StringUtils.hasText(token) || !JwtUtil.verify(token)) { response.setStatus(401); return false; } JwtPayload payload = JwtUtil.parse(token); UserContext.set(payload.getUserId(), payload.getRole()); return true; } }对于学生和管理员接口的差异化控制，我选择在拦截器里做粗粒度校验，配合HandlerInterceptor判断请求路径前缀，比如/api/admin/**路径强制要求ADMIN角色。细粒度的数据权限则在Service里校验，比如学生只能查询自己的申请记录，参数里的studentId必须等于当前登录人的ID。
3.3 MyBatis动态SQL处理多条件筛选
评审后台的申请列表是典型的多条件查询场景：按奖项、按状态、按学生姓名或学号模糊搜索。完全为每种组合写独立SQL不现实，用MyBatis的动态SQL就非常顺手。
<select id="selectApplicationPage" resultType="com.example.award.entity.Application"> SELECT a.*, s.student_no, s.name AS student_name, p.award_name FROM award_application a LEFT JOIN student s ON a.student_id = s.id LEFT JOIN award_project p ON a.project_id = p.id <where> <if test="projectId != null"> AND a.project_id = #{projectId} </if> <if test="status != null"> AND a.status = #{status} </if> <if test="keyword != null and keyword != ''"> AND (s.name LIKE CONCAT('%', #{keyword}, '%') OR s.student_no LIKE CONCAT('%', #{keyword}, '%')) </if> </where> ORDER BY a.submit_time DESC </select>这里有几个细节很容易踩坑。LIKE后面的参数拼接，MyBatis里直接用'%' #{keyword} '%'是没问题的，但要注意SQL注入防护，不能用字符串拼接的方式直接拼keyword进去。另外ONLY_FULL_GROUP_BY模式下，涉及GROUP BY的查询要小心SELECT列的选择问题。
多条件查询的性能受数据库索引影响非常大。我在award_application表上建了project_id和student_id的联合索引，查询评审列表时会先按project_id过滤，索引能有效命中。如果数据量达到几十万，建议再加复合索引(project_id, status)，把状态过滤也走索引，效果会更明显。
4. Vue前端的页面结构与token全链路处理
4.1 前端工程初始化和依赖安装
前端用Vue CLI创建项目，选择Vue 3，同时安装vue-router、axios、pinia（状态管理）和Element Plus。Element Plus组件库对管理后台场景的覆盖非常全面，表格、表单、弹窗、上传、消息提示都是现成的，几乎只需要关注业务逻辑。
vue create award-frontend cd award-frontend npm install vue-router@4 axios pinia element-plusNode版本是个容易踩坑的点。我当时本机安装了较新的Node版本，导致node-sass编译失败，后来换成sass就解决了。给新手的建议是直接用LTS版本的Node，配合npm源设置国内镜像，装依赖能省下不少时间。项目创建完先把Element Plus完整引入跑通，后续做按需引入优化体积，避免一开始就卡在构建配置上。
4.2 axios拦截器与路由守卫的token处理
前后端分离的token处理，核心就是两条：请求发出前把token带上，收到401时做统一处理。我把token存到localStorage里，登录成功后写入，前端所有axios请求通过请求拦截器统一在header里附加Authorization。
axios.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = token } return config }) axios.interceptors.response.use( response => response.data, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token') router.push('/login') } return Promise.reject(error) } )路由守卫负责页面级的访问控制。在路由配置里，给需要登录的页面标记requiresAuth属性，给管理员页面标记requiresAdmin属性。全局前置守卫里判断：没有token且目标页需要登录，就重定向到登录页；有token但角色不是管理员且访问了管理员页面，就重定向到首页。
router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') const role = localStorage.getItem('role') if (to.meta.requiresAuth && !token) { next('/login') } else if (to.meta.requiresAdmin && role !== 'ADMIN') { next('/') } else { next() } })这里有个小技巧：token失效时，响应拦截器弹出统一提示，然后把用户踢回登录页。但要注意避免在登录页本身上也触发这个逻辑，否则会形成死循环。我当时遇到过一次——token过期后页面跳到登录页，登录页发出的某个匿名请求也返回401，又触发了一次跳转。解决方案就是拦截器里判断一下当前是否已经在/login，或者对白名单请求不做401处理。
4.3 学生端和管理端的核心页面实现
页面结构上，我按角色分了两条线。
学生端主要包含评分项目列表、申请表单、我的申请三个页面。项目列表用el-card展示奖项卡片，每张卡片显示奖项名称、名额数、申请截止时间，状态为"可申请"的卡片有"去申请"按钮。申请表单用el-form承载，包含申请理由的textarea和证明材料上传组件，el-upload设置action指向后端的文件上传接口，携带token上传后拿到文件路径回填到表单里。我的申请页面用el-table展示历次申请记录和状态标签。
管理端是重头页面。奖项管理页负责发布、编辑、启停评奖项目，分配名额，设置申请时间窗口。评审管理页是核心操作页：左侧按奖项筛选，右侧表格列出待审核的申请，点击"审核"弹窗里显示学生信息和申请材料，填写通过/退回意见后提交。公示管理页则负责一键生成获奖名单，发布到公示区，支持导出Excel。
// 评审提交的核心逻辑 async function submitReview(row, decision) { const res = await updateReview(row.id, { newStatus: decision, comment: reviewComment.value }) if (res.code === 200) { ElMessage.success(decision === 1 ? '已通过' : '已退回') loadList() } }前端这些页面看似简单，真正的难点在与后端的数据格式对齐。比如Java里的Long类型传到前端会变成Number，超过JavaScript安全整数范围时精度会丢失，导致某些ID比较出错。我处理的办法是后端在返回JSON时把ID转成String类型，或者让前端用字符串方式处理ID字段，保证每次点击操作都能定位到正确的记录。
5. 从本地到服务器的完整部署流程
5.1 面向服务器的环境准备
部署这个系统需要的软件环境不复杂，但每一步都有细节需要注意。服务器以CentOS为例，需要提前装好JDK 17、MySQL 8.0、Nginx和Node环境。JDK版本在SpringBoot 3.x下建议还是17以上，如果项目基于SpringBoot 2.x，JDK 8就够用，版本选择不能混着来。
MySQL安装完以后，第一件事是改root密码，第二件事是设置字符集。建库时一定用utf8mb4，否则中文和emoji符号会出现乱码。我实际部署时专门给系统建了一个独立账号，只授予业务库的权限，避免直接用root账号跑应用带来的安全风险。
5.2 后端Maven打包与云端启动
后端打包前，先检查application.yml里的数据库连接、文件存储路径、日志路径等配置，改成服务器实际环境。数据库的初始化脚本可以直接用本地的SQL文件在服务器上source导入，但要注意把测试数据清一清，避免把本地测试记录带到生产环境里。
mvn clean package -DskipTests java -jar award-server.jar --spring.profiles.active=prod后端启动后，用curl或浏览器直接访问应用的健康检查接口，确认服务已经起来了。这一步卡住通常有两个原因：一是MySQL端口3306没在安全组开放，二是application.yml里数据库地址填错。我的排查思路是先在服务器上执行mysql命令确认数据库能连，再检查java进程日志里报的异常信息，按日志定位问题。
生产环境运行建议用nohup或者systemd来守护进程。我习惯写一个systemd服务文件，配置Restart=always，这样即使进程异常退出，系统也能自动拉起来，不至于等用户反馈了才发现服务挂了。
5.3 前端打包与Nginx部署方案
前端打包前要改一个关键配置：Vue项目的publicPath。如果站点部署在域名根路径下，publicPath可以保持'/'；但如果是部署在子路径下，比如http://ip:8081/award/,就要把publicPath改成'/award/'，否则JS和CSS资源路径全部404。这一步是很多人部署后白屏的头号原因。
npm run build # 构建产物在 dist 目录dist目录拷贝到服务器的指定位置之后，用Nginx托管静态资源，同时把/api开头的请求反向代理到后端的8080端口。Nginx的配置如下：
server { listen 80; server_name your-domain.com; root /opt/award/dist; index index.html; location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location / { try_files $uri $uri/ /index.html; } location /uploads/ { alias /opt/award/uploads/; } }访问根路径时，前端路由接管页面跳转。使用history模式的路由，刷新或直接访问某个子路径时Nginx找不到对应文件，try_files会把请求打到index.html上，由前端路由自行解析。这是SPA部署的标准配置，不理解这条规则的部署者会在刷新404这个问题上卡一天。
部署完成后，在全流程验证一遍：登录、浏览奖项、学生提交申请、管理端审核、公示结果。我把这套验证脚本固定下来，每次发版或迁移服务器都按这个顺序跑一遍，可以快速发现环境级别的配置问题。
6. 开发联调中的高频问题与最终处理方案
6.1 跨域问题：开发代理与生产环境的差异
前后端分离必然遇到跨域。开发阶段我在Vue的vue.config.js里配置了devServer代理，把/api开头的请求全部转发到localhost:8080，这样浏览器没有跨域问题，调试效率最高。生产环境用Nginx反向代理，同样规避了跨域，因为前后端域名相同。
// vue.config.js module.exports = { devServer: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } }如果你非要通过后端添加CORS头来解决跨域，也不是不行，但要注意指定允许的来源和请求头。切忌使用allowCredentials(true)加allowOrigin("*")的组合，这会导致浏览器直接拒绝响应。我的建议是：开发走代理，生产走Nginx，后端不做跨域配置，这套方案最干净。
6.2 MyBatis特殊字符比较与日期动态SQL的坑
写过MyBatis查询的人应该都遇到过特殊字符问题。筛选时间为"申请截止时间大于当前时间"的SQL，在XML里直接写大于号没问题，但小于号必须转义：
<if test="applyEnd != null"> AND apply_end < NOW() </if>小于号在XML解析阶段会被当作标签开头，必须用<或者把整段SQL包进<![CDATA[ ]]>里。我在学生申请页的判断和评审列表的时间筛选里都踩过这个坑，尤其是应用截止时间的比较逻辑，写错一次会导致所有项目都显示为不可申请,排查时还以为是权限或时间格式的问题。
日期动态SQL另一个坑是时区问题。服务器默认时区、MySQL时区、应用连接的时区配置不一致时，NOW()返回的时间可能与本地观察的时间相差8小时。我的处理方式是统一在JDBC连接串上写serverTimezone=Asia/Shanghai，让数据库和应用按同一时区工作。
6.3 打包后的资源404与前端的版本兼容问题
前端打包后白屏或资源404是常见问题。出现这类问题不要慌，按三个步骤排查：第一，浏览器开发者工具里看Network面板的JS请求返回什么状态码，如果是404，多半是publicPath配置不对；第二，看dist目录的index.html里引用的路径前缀，确认资源实际位置与请求路径相符；第三，如果是history模式下刷新404，检查Nginx的try_files配置是否生效。
另一个常犯的错误是前端组件库版本和Vue版本不匹配。Element Plus要求Vue 3，Element UI则是Vue 2的组件库，装混会导致组件无法渲染且控制台报错。这类问题在项目初期就要锁定版本号，package.json里用精确版本而不是^号模糊匹配，避免安装依赖时自动升级到不兼容版本。
6.4 并发申请场景下的数据一致性处理
学生集中在截止时间前提交申请是常见场景，此时系统面临并发写入的考验。最典型的问题是名额超发——多个请求同时读到剩余名额为1，同时通过校验并插入申请记录。数据库层面，只靠应用层的判断挡不住并发。
我采用的方案是在申请记录表的project_id和student_id上加了唯一索引，确保同一个学生对同一个奖项只能有一条生效申请。然后再用事务和行锁处理名额扣减，SQL如下：
UPDATE award_project SET remaining_quota = remaining_quota - 1 WHERE id = #{projectId} AND remaining_quota > 0这条语句利用数据库行锁和条件更新，保证并发下名额不会扣成负数。如果更新影响行数为0，说明名额已满，业务层立刻抛出异常回滚整个事务。这个思路比先查再更安全得多，也是我做这个项目过程中处理数据并发最值得分享的一个经验。
说到这儿，我把这套评奖评优管理系统从业务设计到技术落地、再到部署上线的完整链路都过了一遍。你拿到源码之后，先按第5章的流程把环境搭起来、把系统跑通，然后重点读第2章的建表SQL和第3章的接口实现，把核心流程的代码缕清楚。后续想扩展的话，可以往三个方向走：对接学校统一身份认证做单点登录、加上消息通知模块让状态流转实时触达、把评审环节改成匿名评分和自动汇总。我自己在这次开发里最大的体感是：一个系统能不能用得好，七成在数据模型和状态机设计，代码反而是水到渠成的事。希望这份经验能帮你少踩几个坑。
