1. 为什么我要做这个“智慧教育实习实践管理系统”
先聊下背景。去年帮某高校信息学院的实验室搭一套实习过程管理系统，最开始A同学找我的时候，需求文档写得特别“理想化”——什么“全面感知实习状态”、“数据驱动决策预警”，听起来很唬人。但翻了半天文档，真正落地的核心诉求其实就两条：一是把散落在各企业导师、辅导员、系主任手里的实习数据收拢到一个平台上，二是让老师能随时看到学生实习的真实状态，而不是等到期末收一份几千字的实习报告了事。
这类系统在市面上有个通称叫“实习实践管理系统”，加上“智慧教育”前缀之后，本质上多了一层数据分析和过程评价的维度。在国内高校的语境下，它通常要对接教务系统的培养方案、企业端的岗位发布、学生端的实习申请、教师端的指导与评价，是一套典型的“多方角色协同+全流程状态机”业务系统。
如果只做一个简单CRUD，那没啥好写的，SpringBoot+Vue三天就能撸完。但这套系统的难点在于：
- 角色多：学生、校内指导老师、企业导师、辅导员、院系管理员、系统管理员，同一个数据在不同角色眼里长得完全不一样。
- 流程长：从实习岗位发布、学生报名、双选确认、报到登记、日志周报提交、月度考核、中期检查，到终期评分、材料归档，一条流程下来状态流转极其复杂。
- 数据关系密：学生选岗位、老师带学生、学生写日志、老师评日志，中间还夹着三方协议、保险信息、考勤记录、成绩评定，表与表之间环环相扣。
更关键的是，大部分在校学生独立开发这种系统时，容易陷入“把页面堆出来”的陷阱——前端写了一大堆表格和表单，后端却是一堆没有事务控制的孤立接口，数据库设计更是一团乱麻，同一个实习记录在五张表里各存了一份副本。我这个项目想做的，就是从数据架构到业务闭环，把这件事完整跑通。
技术栈选择了经典的 SpringBoot + Vue + MyBatis + MySQL，没有引入过分复杂的微服务或中间件。原因是这类业务系统在国内高校部署环境下，一台普通服务器就够了，维护成本必须足够低，需求频繁变动时开发迭代速度要足够快。
2. 业务模型拆解：实习管理的核心痛点和流程闭环
2.1 一个学生从“找实习”到“完成实习”到底要经过多少环节
我最初犯过一个经典错误：一上来就画表、写实体类，结果搞到第三周发现状态机根本对不上，加班重来。后来学乖了，老老实实先把一条完整的实习链路画清楚。这里我把最终梳理出来的业务节点分享出来，这也是整套系统的地基：
- 实习前：学校发布实习计划、企业（或校内虚拟企业）发布岗位、学生浏览岗位并投递、企业筛选/指导老师确认、学生签署安全承诺书。
- 实习中：学生填报报到信息（企业信息、岗位信息、入住宿舍等）、按周提交实习日志、按阶段提交月度总结、指导老师批阅并打分、带教企业导师反馈评价、辅导员跟踪考勤与请假。
- 实习后：学生提交实习报告、企业导师与校内老师共同评定成绩、院系审核归档、系统汇总生成实习台账和数据分析。
我们系统立项时是学院内部一个信息化平台，由某系主任牵头，最初只覆盖“日志-批阅-评分”最小闭环，后续才逐步补上“双选匹配”和“数据看板”。你如果自己独立做毕设或练习项目，建议也是先做最小可用闭环，再层层加码。
2.2 角色权限设计的四个关键视角
这套系统里，唯一不可缺少的角色是“学生”和“指导老师”，但实际使用中必须处理“企业导师”和“院系管理员”。
| 角色 | 核心诉求 | 在系统中的关键操作 |
|---|---|---|
| 学生 | 快速投递岗位、记录实习过程、查看评价 | 投递岗位、写日志、提交周月总结、查看成绩 |
| 校内指导老师 | 随时掌握每个学生的实习动态 | 双选确认、批阅日志、发起预警、评定成绩 |
| 企业导师 | 反馈学生真实工作表现 | 月度评价、考勤确认、实习鉴定 |
| 院系管理员 | 监控全系统运行、导出归档材料 | 配置基础数据、查看统计报表、导出实习档案 |
权限控制在SpringBoot后端用Interceptor+注解完成，前端路由守卫再拦一层。你不用一上来就上Spring Security+OAuth2那套重型方案，如果系统没有外部开放接口需求，基于Session或JWT的轻量鉴权完全够用，但要保证每个Controller方法都有显式的权限声明，不能让管理员接口被学生请求打通了。
2.3 状态机的设计：实习状态流转是系统的“中枢神经”
我见过太多实习生写的系统，页面左边列表一拉，状态字段就是个字符串，前端判断一下显示什么颜色，后端完全不管状态之间的合法性。结果就是学生跳过了“双选确认”直接提交了“报到信息”，数据库里根本没有岗位关联记录。
这套系统的状态流转我认为是最值得花心思的地方。我把核心状态机定义成了这样（简化表述）：
- 实习计划：草稿 -> 已发布 -> 已截止 -> 已归档
- 实习申请：待投递 -> 已投递 -> 待确认 -> 已确认 -> 已拒绝 -> 已撤回
- 实习过程：待报到 -> 实习中 -> 已结束 -> 已中止
- 日志审核：草稿 -> 待批阅 -> 已通过 -> 需修改 -> 已评阅
每个状态下能执行的动作是固定的，我在Service层用枚举+状态表显式管理流转规则。比如“已投递”状态只能执行“确认”或“拒绝”，不能直接跳到“已通过”。前端的按钮显示逻辑全部由后端的“可执行动作接口”驱动，避免前后端状态理解不一致——这个设计在答辩时非常加分。
2.4 一份实习成绩是怎么算出来的
业务上最容易被质疑的是“成绩从哪来”。我们项目里把实习成绩拆成了四个部分：
- 日志/周报平均分（指导老师打分）
- 月度总结分（企业导师评价折算）
- 实习报告终评分（答辩或评审小组给分）
- 平时考勤扣分项（由辅导员录入）
四者加权汇总得到最终成绩，最终成绩保存在实习记录的主表上，直接供成绩单导出。具体权重可以在系统参数里配置，不同学院差异较大，不能写死。
在表结构上，日志表存每次得分，总结表存月度评价，但最终成绩只存一个汇总值，这个过程必须在数据库事务里完成，不能分几次请求凑。我第一次写的时候把成绩计算散落在前端，后面发现只要有一个人手动改库，汇总就对不上了，教训很惨。
3. 数据库设计：核心表结构如何支撑整套业务
3.1 建表的整体思路：宁可多拆关联表，不要把所有字段塞进一张大表
实习管理系统本质上是一个“围绕学生-岗位-教师”三个人物的关系型数据系统。我把核心表归为六组，每组之间靠外键和联合唯一键维护关系：
- 基础档案组：学生表、教师表、企业表、岗位表、院系专业表
- 实习计划组：实习计划表、学生计划关联表、岗位计划关联表
- 申请双选组：学生申请岗位表、双选确认表
- 过程记录组：实习记录表（学号+计划+岗位，唯一活跃记录）、实习日志表、周总结表、月度评价表
- 成绩归档组：成绩评定表、评分项配置表、归档材料表
- 系统支撑组：用户表（统一登录账号）、角色表、用户角色关联表、操作日志表
关键的关联规则：
- 学生表与用户表一对一，学生表存学号、班级、专业、年级等教务信息，用户表只存账号密码状态。
- 实习记录表是这条链路的主档表，一个学生在同一时期只能有一条“有效实习记录”，通过“状态+计划外键”共同约束。
- 日志表外键指向实习记录表，而非直接指向学生表。这样换实习单位以后历史日志还在，但归在不同的实习记录下。
3.2 关于“是否记录日志附件”这一设计取舍
一开始我天真地给学生日志设计了“图片佐证”功能，要求学生上传工作照片。后来发现一个班60个学生，每个星期上传3张，一学期下来就是几千张图，服务器存储压力不小。更重要的是，安全合规上也很麻烦。
最终的方案是：日志正文采用富文本编辑器（简单实现即可），允许插入图片并上传到本地文件服务（Nginx托管目录），但限制单张大小和总上传次数。表里只存文件相对路径，不存Base64，不给数据库添堵。至于视频类附件，直接砍掉，理由很简单：学校实际使用中基本没人认真录视频，日志文字和图片足够支撑批阅。
提示：附件上传务必做文件类型校验，不只是看后缀，还要读文件头。这个在系统上线后帮我挡住了好几次恶意上传尝试。
3.3 树形导航与组织架构的存储方式
院系、专业、班级在页面展示上是一个经典的三级树。数据库里我用了一张部门表，字段包括：id、父级id、层级（1学院/2专业/3班级）、名称、排序号、是否启用。查询时一次性全部查出，在内存中用递归组装成树结构返回给前端。
注意避免使用MySQL递归CTE来查数据。数据量小，递归查询反而给自己找麻烦。一次性load全表的做法在几千行规模下毫无压力，实现简单还容易面试时讲清楚。
3.4 分页查询的几条硬经验
- 日志和成绩类的分页查询，不要用
LIMIT 10000,20这种写法，数据过万之后性能明显下降。改用“游标分页”或“最大ID分页”，但在Web管理端用户习惯按页码翻页，所以这里用了PageHelper插件做常规分页，配合索引优化。 - 必须建立联合索引的表：日志表(实习记录id、创建时间)、成绩表(实习记录id、评分项类型)、申请岗位表(学生id、状态)。
- 所有统计类查询尽量走一张“汇总事实表”，不要在页面上临时count多张表。我单独维护了一张
intern_stat_daily每日统计表，用定时任务刷新关键指标，看板查询速度可以轻松到毫秒级。
4. 后端落地：SpringBoot+MyBatis 的方法论与关键细节
4.1 分包结构与代码分层
我采用的是经典四层分包结构：
com.xxx.intern ├── controller // 只做参数接收与简单校验 ├── service // 业务逻辑、事务控制 ├── mapper // MyBatis接口，只写数据访问 ├── entity // 数据库实体 ├── dto // 前端交互对象，避免把entity直接吐出 ├── vo // 视图对象，组合多表查询结果 ├── common // 统一返回体、异常、工具类 └── config // 全局配置、拦截器、JSON序列化配置很多人在网上看的项目直接把entity返回给前端，省事，但后患无穷。比如用户表里有密码Hash值，实体里有status字段，前端并不需要这些。我统一用DTO/VO做隔离，虽然刚开始多写几个类，但后面迭代加字段时完全不用怕影响接口的兼容性。
4.2 统一返回体与异常处理是效率倍增器
Controller层不要出现裸的Map或Object返回，我会用Result<T>统一包装，结构为：{ code, message, data }。配合@RestControllerAdvice做全局异常处理，把参数校验异常、业务异常、未知异常统一映射成对应的code和HTTP状态。
只有完整返回结构，前端才能抽出一个统一的request.js封装HTTP库。否则每个页面都要重新处理错误弹窗和登录超时，项目根本没法快速交付。这个环节老生常谈但真正的实操里，很少有人真正落到异常码分类。我的分类法很简单：
- 1000 成功
- 2000 参数错误（前端表单校验漏了由后端兜底）
- 3000 权限不足（一般是登录用户角色不符）
- 4000 业务规则不满足（比如状态已锁定，不能重复操作）
- 5000 系统异常（后端代码有Bug或数据库异常）
前端对这几个码在axios拦截器里统一处理，登录超时就跳登录页并清空本地token，2000就把后端返回的具体字段错误信息直接填充到页面提示条上。
4.3 MyBatis 使用的三条铁律
第一，写动态SQL必须用<if>标签，不要硬拼字符串。SpringBoot里用MyBatis最大的诱惑是“原生SQL功能强”，但拼接SQL的注入风险极高，哪怕只是order by的字段名，也会被有心人利用。
第二，批量插入尽量用<foreach>写批量insert。实习计划批量关联学生、批量导入学生账号，都是几百上千条的数据。单条循环insert会很慢，批量insert在MySQL下能快一个数量级。
第三，联表查询返回的字段要映射到VO，而不是多张Entity。MyBatis的resultMap要配全。我见过太多人联表查询直接返回Map，结果前端拿到的字段名和类型到处是坑。
下面用一个日志分页查询的Service层示例来展示完整写法（简化版）：
@Override @Transactional(readOnly = true) public PageResult<InternLogVO> pageLog(LogQueryDTO dto) { // 构造查询条件 LogQueryCondition condition = new LogQueryCondition(); condition.setInternRecordId(dto.getInternRecordId()); condition.setStatus(dto.getStatus()); condition.setStartDate(dto.getStartDate()); condition.setEndDate(dto.getEndDate()); // 查询当前用户有权访问的实习记录ID集合 List<Long> accessibleRecords = permissionService.getInternRecordsByLoginUser(); condition.setAccessibleRecordIds(accessibleRecords); PageHelper.startPage(dto.getPageNum(), dto.getPageSize(), true); List<InternLogVO> list = internLogMapper.selectLogList(condition); return new PageResult<>(list); }事务里我加了一个readOnly=true，这主要是给数据库优化器看的提示。另外查询前必做权限过滤，因为日志数据对学生本人、指导教师、管理员可见度完全不同，如果直接在Mapper层写死“只查自己的”，后续管理员查看功能就无法复用同一个接口了。
4.4 事务与状态机写在一起才不容易出错
状态流转操作天然需要事务保护。以“指导教师批阅日志”为例，一次操作要同时做这么多事：
- 更新日志状态为“已通过”或“需修改”
- 写入批阅评语
- 如果是“已通过”，反查该日志对应的实习记录累计得分
- 决定是否达到月度总结触发阈值
- 写一条操作日志到系统日志表
我直接在Service方法上标注@Transactional(rollbackFor = Exception.class)，注意这里一定要写rollbackFor，因为Spring默认只回滚RuntimeException，像文件IO异常这类受检异常不会自动回滚，极容易造成状态改了但评语没存进去的脏数据。
4.5 登录鉴权与JWT的无感续期
管理系统面向教职工和学生，移动端不在本期范围，所以Session方案其实也够用。但考虑到后期可能要对接企业端小程序，我还是选了JWT方案。实现上：
- 登录成功后签发AccessToken（有效期2小时），同时把用户id、角色、姓名塞进Claims
- 前端把token放localStorage，每次请求在axios拦截器里带
Authorization: Bearer xxx - 后端自定义
AuthInterceptor解析token，解析失败或过期直接返回401 - 用户操作时如果token剩余有效期低于30分钟，响应头里返回新的token（Refresh逻辑），前端检测后静默更新
刷新AccessToken时一定要校验原token的签名和黑名单状态，防止已被注销的账号继续续期。这块逻辑不写在核心链路上会埋雷，我上线后有过一次因为“学生毕业账号未注销，但重新登录后旧token还能续期”的Bug，排查下来就是刷新接口没校验用户状态。
5. 前端工程化：Vue3 + Element Plus 的模块化实战
5.1 为什么选Vue3而不是Vue2
选Vue3不是因为它新，而是因为这套系统的前端复杂度决定了Composition API的复用性远好于Options API。比如日志表单的校验逻辑、分页组件状态、筛选条件联动，用setup函数把相关逻辑聚合到一起，维护时不需要在data、methods、watch之间来回跳。
UI组件库选了Element Plus，成熟稳定、后台管理味正，不用自己造轮子。图标直接内置图标库，减少额外依赖。状态管理用了Pinia，实际上这个系统多数状态都跟着路由走，Pinia主要存用户信息、权限标记、侧边栏折叠状态，没有过度使用。
5.2 路由权限拦截与动态菜单
前端路由不能只做“登录后才能访问”这一层，还必须细分角色可见的路由。我采用了“静态路由排除法”：把所有人都能访问的页面（登录、404、重置密码）做成静态路由；把需要权限的页面统一放到一个模块文件里，前端根据用户角色列表去过滤可用路由，再动态注册。
动态路由注册时注意坑：Vue Router 4 中新增路由必须使用router.addRoute，且要在导航守卫里做“路由已添加”标记，不然点击浏览器刷新后动态路由丢失，导航白屏。
菜单则根据路由meta里的title、icon、roles字段递归生成。这样后端新增了一个页面，前端不用改菜单配置文件，只要在路由表里加一条即可。
5.3 表格页面的通用封装
后台管理系统90%的页面结构是：顶部筛选栏+表格+分页+新增/编辑弹窗+删除确认。这套结构反复写容易烦且易出错。我封装了一个PageWrapper组件，把筛选表单、工具栏、表格、分页全部接管，页面里只需要传表格列配置和查询接口函数。
<template> <page-wrapper :columns="columns" :query-api="fetchLogList" :create-api="handleCreate" :edit-api="handleEdit" :delete-api="handleDelete" /> </template>这里面最核心的是“表格列配置化”和“操作列插槽”，给操作类按钮留具名插槽，避免封装过度导致没法二次定制。比如日志列表里“批阅”按钮需要弹出富文本对话框，我就通过插槽在里面嵌套自己的业务逻辑。
5.4 富文本与文件上传的避坑点
实习日志、学生总结、老师评语都要用富文本编辑器。我在项目里选了WangEditor（轻量，适合Vue），但使用中发现默认的图片上传是把图片转Base64放进HTML里的，文章一长就会极大拖慢页面加载和数据库体积。
解决办法：在WangEditor配置自定义上传地址，让图片走独立的文件上传接口，返回的URL是Nginx静态资源路径，编辑器内只存这段路径。这样富文本内容短小，图片加载走CDN/静态服务器，不会冲击数据库性能。
文件上传接口需要注意：
- 限制类型：jpg、png、pdf、docx等白名单
- 限制大小：图片单张不超过5MB，文档不超过20MB
- 文件名重命名：用UUID或时间戳+随机数，禁止用户原文件名直接落盘
- 文件路径存储：
/upload/2025/04/xxxx.jpg，分目录防止单目录文件过多
5.5 数据看板怎么做才能支撑“智慧教育”
“智慧教育”不能停留在概念阶段，我落地成了三块看板：
- 实习总览：当前实习人数、拟实习人数、已完成人数、中途终止人数，用大数字卡片展示。
- 过程质量：日志按时提交率、批阅平均耗时、月度总结覆盖率，用折线图看趋势。
- 企业分布：合作企业Top10、岗位热门度、学生满意度，用柱状图和饼图展示。
图表选了ECharts，在Vue里直接封装了一个ChartCard组件，只接收option对象，内部处理resize和销毁。数据来源就是前面提到的每日统计表，定时任务凌晨跑一次聚合，前端查询接口只查汇总结果。实测在1000名学生的规模下，看板加载在300ms以内。
数据看板的具体字段要跟系里需求对齐，我一开始做得太“炫”，堆了一堆图表，结果系主任只盯着一个指标：“有多少学生本周没写日志”，其他根本没人看。后来砍掉了80%的图表，保留真正能辅助管理的几个，页面反而清爽很多。
6. 完整开发链路：从初始化到跑通第一条核心流程
6.1 后端初始化与配置
用Spring Initializr创建工程，Java 17 + Spring Boot 2.7.x + MyBatis + MySQL 8.0。这里提醒一下：如果选了Spring Boot 3.x，依赖坐标和部分配置有变化，遇到坑的机会更多，教程也少。不是不能用3.x，而是如果你是首次搭这类系统，2.7.x搭配教材资料最多，排错成本最低。
配置文件里我单独拆了个application-dev.yml，数据库连接、Redis（本项目没用到Redis，纯MySQL本地缓存即可）、日志打印都放里面。MyBatis开启了驼峰映射，SQL日志级别设为DEBUG，方便联调时看到SQL和参数。
6.2 创建数据库与初始化SQL
我建了intern_system库，字符集用utf8mb4，排序规则utf8mb4_general_ci。核心初始化脚本写了：
CREATE TABLE `t_user` ( `id` bigint NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL, `password` varchar(100) NOT NULL, `real_name` varchar(50) DEFAULT NULL, `phone` varchar(20) DEFAULT NULL, `email` varchar(100) DEFAULT NULL, `status` tinyint NOT NULL DEFAULT '1', `create_time` datetime NOT NULL, `update_time` datetime NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;其他核心表大同小异，注意所有表的create_time和update_time都建上，且在插入更新时由MyBatis自动填充（用@TableField(fill = FieldFill.INSERT_UPDATE)配合MetaObjectHandler）。为省事，我统一在SQL里写DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP，两种方式都行，但别混用。
6.3 跑通第一条流程：学生投递 -> 老师确认 -> 写日志
我建议你开发时也按“垂直切条”的方式走，不要先把所有表建完再写接口。
第一步：实现登录和用户权限，先能登录一个学生账号。 第二步：实现岗位发布接口（管理员），学生能看到岗位列表。 第三步：实现学生投递、老师确认接口，把申请状态流转串起来。 第四步：实现学生创建实习记录、写日志、老师批阅这个核心业务环。 第五步：再补条看板、导出Excel、数据统计。
按这个顺序，每一步结束系统都是可用的，而且测试用例能跟着写。我当初一次把所有表写完再开始写接口，结果查询联表一堆错位，调试一个Bug要前后端同步排查半天。
6.4 技术选型的部分替代方案对比
| 选型点 | 本项目选择 | 备选方案 | 为什么这么选 |
|---|---|---|---|
| 后端框架 | SpringBoot 2.7 | 若用JDK8更稳，SpringBoot 2.7已经足够 | 生态资料多，排错容易 |
| ORM | MyBatis | MyBatis-Plus / JPA | 复杂度可控，动态SQL灵活，面试好讲 |
| 前端 | Vue3 + Element Plus | Vue2 + Element UI | 新项目用Vue3，长期维护不吃亏 |
| 数据库 | MySQL 8.0 | PostgreSQL / SQL Server | 高校里MySQL最常见，部署最方便 |
| 鉴权 | JWT | Session / Spring Security | 轻量、前后端分离友好 |
| 文件存储 | 本地磁盘+Nginx | 阿里云OSS / MinIO | 学校环境难以使用云服务，本地最可控 |
7. 上线后真实遇到的五个“坑”和排查思路
系统开发完不等于结束。我把这套系统给某学院内部试运行了几个月，从运维角度真实遇到并解决的问题，这些都比功能代码更值钱。
7.1 并发双选冲突：同一岗位被学生重复投递
现象：两个学生同时对一个岗位发起投递，系统生成两条投递记录，但岗位名额只有1个。
根因：前后端分离后，前端按钮先校验了一次剩余名额，用户A和用户B同时通过校验，两条请求并发落到后端，后端没有做真正的防重校验。
修复：在申请岗位表上加了联合唯一索引(studentId, planId, positionId)，并且Service层用数据库唯一约束兜底，捕获DuplicateKeyException后返回“请勿重复投递”。同时前端按钮提交后立即置灰，服务端响应前不允许重复点击。
7.2 富文本内容中的XSS漏洞
现象：学生日志里插入了一段<script>代码，其他老师打开日志内容时脚本被执行。
根因：富文本编辑器没有做输出端的HTML清洗。保存时内容原样入库，展示时又原样渲染。
修复：后端在保存时统一用Jsoup（Java的HTML解析库）清洗内容，白名单只允许p、br、strong、img、a等常用标签，script、iframe等全部剥离。前端也要在渲染富文本内容时设置v-html后额外做一次白名单校验，双层防御。
注意：很多教程里说“后端把富文本存库，前端直接v-html渲染就完事了”，这是不对的，一条带恶意脚本的日志就能让整个管理后台沦陷。
7.3 超时导致Token过期但前端还停留在页面
现象：老师坐在电脑前写评语，写了20分钟，提交时提示登录过期，内容全部丢失。
根因：AccessToken有效期2小时，我做了刷新机制，但刷新只发生在请求拦截器里。如果用户在页面停留很久不发请求，前端根本不知道token要过期了。
修复：前端在登录后启动一个定时器，每10分钟调用“用户心跳接口”（返回当前用户信息和token剩余时间），如果剩余低于30分钟，自动刷新。刷新时后端重新签发AccessToken并返回新的剩余时间。为了不影响用户输入，刷新全部在axios拦截器里静默完成。
7.4 Excel导入学生名单时中文乱码
现象：管理员在系统里下载学生名单模板，填好中文姓名后上传，数据库里全是问号。
根因：模板生成的CSV文件用Excel打开后另存为ANSI编码，上传时系统用UTF-8读取，中文全部乱码。
修复：导入接口统一读取Excel的.xlsx格式（用Apache POI处理，不推荐让用户上传CSV），且允许用户选择“导入数据中是否含表头”。同时在导入结果里逐行返回成功/失败原因，而不是只给一个“导入完成”的提示。这条处理做到位后，管理员的满意度直接拉满。
7.5 导出成绩单时数据错位
现象：导出的Excel里成绩列和第几行对不上，但页面显示是对的。
根因：导出时用的查询SQL没加ORDER BY，数据库返回顺序不稳定，前端又按固定顺序填充Excel单元格。
修复：所有导出接口的SQL都强制加主键排序，而且导出数据直接用后端VO对象，不再依赖前端二次处理。导出前还要检查当前筛选条件是否导致数据量过大，超过5000行先提示并让用户缩小范围，防止Excel卡死。
8. 答辩与面试中，怎么把这份项目讲出亮点
如果你拿这套系统做毕设或项目经历，面试官/评委大概率会问：“这系统不就是个普通CRUD吗？智慧在哪里？”这个问题最怕回答“主要是加了图表”这种没技术含量的话。我建议从三个层次去讲。
第一层：权限模型。三种角色、状态机的合法流转、操作日志审计。这是“可靠”的体现，能讲出@Transactional回滚、数据库唯一约束兜底这些细节，说明你真的做了有状态管理的系统，不是玩具。
第二层：数据分布与汇总。日志、周报、月度总结分散在过程表中，成绩按权重在多张表计算汇总。我为了实时看板设计了一张每日统计表，用定时任务把数据预先聚合，查询性能从1秒降到100毫秒以内。这个点极有区分度，能体现你对大数据量查询的设计思路。
第三层：赛博化/智慧化的业务落地。比如“实习预警模块”是我后期加的：如果一名学生连续3天没有提交日志，系统自动发站内信提醒指导老师，并在看板上红点标注。这背后是一套简单的规则引擎，可以讲如何用状态字段+定时任务实现自动预警。把这些讲透，评委很容易get到“智慧教育”的具体体现。
不要夸大，不要说“我用了大数据”，你只要把实习日志、成绩权重、预警规则、每日统计这四个模块的细节讲清楚，已经比绝大多数项目强了。
9. 分享一下我最初做这套系统时的一些教训
（写到这里也接近尾声，讲点真实的心得。）
第一，建表前一定要先画状态机。我前前后后改了三版表结构，第一版把“岗位申请”和“实习记录”混在一张表里，上线前发现流程根本转不动，拆表重来浪费了两周。第二版加了“计划”维度后，把“实习记录”独立出来才真正稳定。
第二，前端的表单校验不可全信。字段是否为空、格式是否正确、长度是否超限，后端必须再校验一遍。我用Hibernate Validator做Bean Validation，在DTO字段上标注@NotNull、@Size、@Pattern，配合全局异常处理。前端校验只是体验优化，后端校验才是安全底线。
第三，没有任何一次上线是“最后”一次。整个试运行期间至少更新了三轮功能：加了Excel导出优化、加了自动预警、加了企业导师的独立账号权限。所以你在设计架构时，一定要为“扩展”留余地，比如角色权限表用RBAC模型，后续要加“督导”角色只需要往角色表插一条数据，不用改代码结构。
最后再分享一个实战小技巧：在本地开发时用Docker起MySQL，不要装原生MySQL。这样可以随时用一条命令清空数据重建库，模拟“从零初始化”的环境，避免本地数据污染导致排查问题困难。我自己是在踩了一次“库环境被我改乱，彻底重装”之后，才养成这个习惯的。
如果再让我重新做一次这套系统，我会把精力更多地放在非功能需求上：日志审计的完整性、接口幂等、性能监控、备份恢复策略，而不是堆更多业务功能。毕竟对这类管理后台系统而言，稳定可用比功能丰富重要得多。
