RED韵如果你认真观察过校企合作这个业务，就会发现一个很有意思的现象：两边都带着美好的愿望坐在一起，会后各自回去填Excel、发微信群、打电话追进度。企业HR要一份学生名单，教务老师翻三个表才能凑齐；学生实习交没交周报，带教导师根本不知道；协议到期该续签了，连校办都没个提醒。前阵子我帮一个朋友整理这类材料，他电脑里躺着一堆命名格式五花八门的表格，数据口径还对不上，那一刻我才决定，与其靠线下Excel缝缝补补，不如直接动手做一套Spring Boot校企合作管理平台，把这条长链路从企业入驻、协议签订、岗位发布到学生实习、考核归档全部数字化。
这套系统最终完整落地，技术栈就是Spring Boot + MySQL + Redis那一套非常成熟的组合。整个项目走下来，我发现难点从来不在CRUD本身，而在业务怎么拆、表怎么建、状态怎么流转、部署调试怎么一次过。这篇就把我完整的设计与实现过程复盘出来，包括我在数据库建模、核心流程编码、开发环境搭建、后期部署上线时踩过的具体坑，以及各种取舍背后的原因。如果你准备做类似的中小型管理系统，或者正打算完成一个能真正交付的Spring Boot项目，这篇可以直接拿来当参照。
1. 动手写代码前，先把校企合作的业务拆成一条主线
很多管理系统项目翻车，不是代码写不出来，而是需求压根没理清。校企合作管理平台尤其如此，因为它表面是个后台管理，实际上横跨校内、企业、学生三边，角色诉求差异很大。不把业务边界画清楚，后面做出来的菜单就是一堆孤立的增删改查。
1.1 校企合作管理有哪些参与者
我一开始就把系统角色定成四类，而不是只做"管理员"和"用户"两种。这样后续做数据权限隔离、页面菜单分配、审核流走向时，逻辑才站得住。
| 角色 | 核心诉求 | 平时卡在哪 |
|---|---|---|
| 学校管理员（产教融合办） | 掌握企业合作全景、协议到期情况、学生实习数据 | 数据分散在各学院，统计困难，到期续签没有提醒 |
| 学院教师 / 辅导员 | 审核学生实习申请、分配校内导师、批阅实习材料 | 找不到统一入口，经常被学生私聊催 |
| 企业用户 / 企业导师 | 完善企业资料、发布实习岗位、填写带教评价 | 需要反复提交纸质材料，看不到审批进度 |
| 学生 | 浏览合作企业、投递简历、提交实习周报、查看考核结果 | 不清楚申请走到哪一步，材料提交经常漏交 |
表格列完就发现，这个系统本质上不是给某一方单独用的工具，而是连接四类角色的业务平台。
1.2 核心业务闭环：一条主线把四类角色串起来
校企合作业务可以浓缩成一条主流程：
- 企业提出合作意向，提交资质材料完成入驻
- 学校审核企业资料，通过后建立合作关系
- 校企双方签订合作协议，达成实习合作、订单培养或共建基地等合作事项
- 企业按协议发布实习岗位，学生在线报名申请
- 企业和校内导师协同管理实习过程，学生提交周报、签到记录、成果材料
- 实习结束，企业导师评价、校内导师评分，结果归档并回流到统计看板
这个闭环是后面所有功能模块的骨架。你去看很多做砸的项目，问题往往出现在这里：把校企合作做成了企业信息管理，把实习管理做成了学生数据登记。其实"合作状态"和"实习过程"的推进才是核心。
1.3 从主流程推导出的功能模块清单
在这个骨架基础上，我给平台划定了这样几个功能域：
- 系统管理：用户、角色、菜单、字典、登录日志
- 企业中心：企业注册、资质入驻审核、企业信息维护、合作状态管理
- 协议合作管理：协议的创建、审批、续签提醒、归档
- 岗位实习管理：企业岗位发布、学生报名、录用分配
- 实习过程管理：实习配置、周报提交、导师批阅、异常处理
- 考核归档：企业考核评分、校内导师评分、实习档案生成
- 数据看板：合作企业数、协议到期预警、在岗学生数、考核完成率
这七个模块不是拍脑袋来的，是从主流程拆出来的。有了这个模块清单，后面设计数据库时才不会一会儿加字段一会儿改表。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Spring Boot为主体，这套技术选型其实不需要"创新"
校企合作管理平台是一种典型的中小型信息管理系统。面对这类系统，最怕的不是功能不够新，而是技术选型太重导致维护不下去。
2.1 最终采用的技术栈
| 层次 | 选型 | 选型理由 |
|---|---|---|
| 后端框架 | Spring Boot 2.7.x | 稳定、生态成熟、资料丰富，能覆盖绝大多数管理场景 |
| 持久层 | MyBatis-Plus 3.5.x | 单表CRUD几乎不用写SQL，复杂查询还能手工写XML |
| 数据库 | MySQL 5.7 / 8.0 | 成熟稳定，用户量级完全够用 |
| 缓存 | Redis | 存储验证码、在线Token、字典缓存，也做后续性能扩展的铺垫 |
| 权限方案 | JWT + HandlerInterceptor | 系统角色固定，没必要上完整Spring Security权限体系 |
| 前端 | Vue 3 + Element Plus + Axios | 管理后台通用方案，开发效率高 |
| 构建部署 | Maven + Nginx | 打包、部署、反向代理都是常规操作 |
有人可能会问，Spring Boot 3.x都出来这么久了，为什么不用新版本？我在这类实际项目里吃过亏：Spring Boot 3.0强制要求JDK 17，早期版本的MyBatis-Plus和一些三方组件兼容性还跟不太上，一升级就会冒出各种莫名其妙的问题。项目交付讲究稳定，Spring Boot 2.7.x配上JDK 1.8，是经过大量项目验证的稳妥组合。选型不是越新越好，是越合适越好。
2.2 单体架构为什么比微服务更合适
这套系统我直接采用单体架构，没有引入微服务那一套。原因很实在：系统用户规模撑死几万人，同时在线也就几百人，业务之间没有独立扩展的需求。微服务架构带进来的注册中心、配置中心、网关等组件，单是部署和运维成本就已经超过了项目本身的价值。
单体架构的另一个好处是调试简单。代码在一个工程里，出了问题打日志就能顺着链路找。文件上传、登录态、事务控制都集中在应用内部，不需要跨服务调用，事务一致性问题也少。后期如果真要拆分，可以先按"企业审核、实习过程、统计报表"这三个域把Service层拆开，再渐进演化成独立服务。这个演进路径是清晰的，所以前期没必要拔苗助长。
2.3 工程结构：按业务域分包，而不是按技术层分包
工程包里怎么分，很多人不在乎，实际上对后期维护影响很大。常见错误是Java包下面按controller、service、mapper这样的技术层分顶层目录。这种结构在业务简单时还行，业务一多就会让代码互相纠缠，改一个功能要跨好几个包翻。
我采用了"业务域优先"的分包思路：
text复制com.school.collaboration
├── common // 统一返回、异常处理、常量
├── config // 配置类、拦截器注册、Redis配置
├── security // JWT工具、登录拦截器、当前用户上下文
├── modules
│ ├── system // 用户管理、角色菜单
│ ├── company // 企业信息、入驻审核
│ ├── agreement // 协议管理
│ ├── recr