爬一手好线杆说句实话，实习管理系统这类项目在校园里已经不算新鲜了。但很多同学拿着一个Java SpringBoot + Vue3 + MyBatis的“高校实习信息发布网站系统源码”，要么照着一篇博客敲完发现跑不起来，要么跑起来之后不知道怎么改、怎么扩展、怎么应付答辩。我这次把整套系统的设计思路和实现细节完整过了一遍，从表结构到动态SQL，从Vue3组合式API到部署上线，把值得说的部分都整理出来，希望对正在做课程设计、毕业设计，或者想学前后端分离项目实战的同学有点帮助。
这个系统的核心业务很直接：学校需要管理学生实习的全过程，企业发布实习岗位，学生浏览岗位并投递简历，教师和企业对学生进行筛选审核，管理员负责整体数据维护和监管。技术栈方面选择了Java SpringBoot + Vue3 + MyBatis + MySQL，前端Vue3做界面交互，后端SpringBoot提供API接口，MyBatis负责数据库访问，MySQL存数据，是一个典型的、也是目前企业里最主流的前后端分离落地组合。
如果你正准备根据这样一个标题从零做一遍，或者手里有源码但看不懂它的设计逻辑，这篇文章可以给你一条完整的参考路线。我尽量把“为什么要这么设计”讲清楚，而不只是贴一堆代码让大家自己看。
1. 项目整体设计与业务需求拆解
1.1 实习管理业务的真实痛点
先不要把技术想复杂，我们从业务角度出发。高校实习信息发布网站系统，本质上解决的是三个问题：信息分散、流程不透明、数据难统计。
信息分散，指的是过去实习岗位可能通过班级群、老师口头通知、纸质表格来发布，学生找信息靠运气。流程不透明，指的是学生投递简历之后，企业到底看没看、老师有没有审核、最后是录还是没录，所有环节没有人能实时知道。数据难统计更麻烦，学院要统计这个学期有多少学生找到了实习、分布在哪些行业、薪资范围如何，如果靠人工汇总，一个星期都出不来准确结果。
这个系统用一套完整的角色权限把各方串起来了。学生注册后维护个人简历，在线浏览岗位库，一键投递，随时查看状态。企业注册后发布岗位，查看收到的简历，对投递者进行操作。教师端可以看到自己名下学生的投递情况，协助审核。管理员统一管理所有用户、岗位和内容。这样一来，信息从分散变成了集中，流程从黑箱变成了每个节点都可追踪。
1.2 角色权限与业务闭环设计
系统划分了四个核心角色：学生（student）、教师（teacher）、企业（enterprise）、管理员（admin）。角色不同，看到的菜单和操作权限完全不同。这是前后端分离项目中很关键的一环，后端接口需要做权限校验，前端路由也要按角色动态生成，否则任何人都能访问管理接口，系统等于裸奔。
我实际落地时采用的方式是：登录时后端根据用户角色返回不同的菜单标识，前端拿到标识后动态注册路由，然后在Axios请求拦截器里统一带上Token，后端通过拦截器校验Token并判断角色。第一版图省事只做了前端菜单隐藏，结果抓到接口照样能拿数据，后来才把后端权限补上。这个顺序大家一定要注意，前端控制只能解决体验问题，安全必须靠后端。
业务闭环的起点是企业发布岗位，管理员审核通过后岗位变为已发布状态。学生在前台浏览并进行投递，投递记录进入待筛选状态。企业端对学生进行通过或拒绝操作，同时在教师端能看到本专业学生的投递情况。整个链路结束之后，管理员通过统计报表查看整体数据，形成一个完整的业务闭环。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术选型与架构设计
2.1 技术栈选择的实际考量
选型这件事，很多人觉得是看哪个火用哪个，其实核心是看“够不够用、好不好招人、资料多不多”。Java SpringBoot做后端接口是绝对的主流，生态成熟，遇到问题几乎都能搜到解决方案。Vue3目前在高校和企业内部系统里覆盖率极高，组合式API写起来比Vue2的Options API更清晰，而且和TypeScript配合得更好。MyBatis作为持久层框架，灵活度很高，SQL都由自己控制，特别适合这种有大量多条件筛选查询的业务系统。MySQL就不多说了，中小型项目的默认选择，开源免费、资料最全。
一个需要提醒的点：项目里不要盲目引入太多依赖。我看到很多新手项目里塞了一堆乱七八糟的starter，结果启动时各种版本冲突。这个系统我用的核心依赖其实很少，SpringBoot Web、MyBatis Starter、MySQL驱动、Lombok、Hutool工具类、JWT认证相关，加上一个PageHelper做分页，足够了。依赖少，出问题的概率就低，排查起来也快。
2.2 前后端分离架构与目录规划
前后端分离的好处不用多说，接口复用、独立部署、团队协作互不干扰。实际开发中我习惯把项目分成两个根目录：前端internship-web、后端internship-server，两者完全独立，只在联调阶段通过URL对接。
后端使用经典的三层架构：controller负责接收请求和返回响应，service负责业务逻辑，mapper负责数据库操作。实体类entity、传输对象dto/vo、通用结果类Result分开存放。有人觉得包分多了麻烦，但项目一旦过几千行代码，不分层的产物就是改一个需求要翻遍所有文件。
前端的目录我大致这样规划：
code复制src/
api/ // 按业务模块封装的接口请求
assets/ // 静态资源
components/ // 通用组件
layout/ // 主布局
router/ // 路由配置
store/ // Pinia状态管理
utils/ // 工具函数，axios封装
views/ // 页面组件，按模块分目录
这种结构的好处是职责清晰，新增一个页面时知道文件应该放哪里，新增一个接口时知道api文件应该改哪里，多人协作时不容易冲突。
2.3 数据库表结构设计要点
数据库设计是这类系统里最重要的一环，表结构如果设计得乱七八糟，后面写SQL的时候会痛苦到怀疑人生。我按业务模块划分了核心表：用户表、学生信息表、企业信息表、实习岗位表、简历表、投递记录表、通知公告表。
用户表是登录认证的基础，角色字段用整数表示，1管理员、2教师、3学生、4企业。学生信息表、企业信息表都和用户表通过user_id字段关联。这样设计的考虑是：账号登录和业务资料分离，避免一张表里塞太多冗余字段，后续扩展用户资料时也不用改表结构。
岗位表是业务核心，字段设计时要注意几个点。薪资字段我用了两个整数字段salary_min和salary_max，而不是一个字符串，这样后续做薪资区间筛选时可以直接用SQL比较大小。实习周期实习时间用字符串存，因为不同岗位的时间描述方式差异太大，强行结构化反而难用。状态字段status用整数，0草稿、1待审核、2已发布、3已下架，状态流转在后端逻辑里严格控制。
投递记录表是整个系统里业务量最大的表，也是面试时经常被问到的点。核心字段有投递学生student_id、岗位post_id、简历resume_id、状态status、申请时间apply_time、处理时间handle_time。这里要注意给student_id和post_id建联合索引，因为最频繁的查询就是“某个学生投了哪些岗位”和“某个岗位收到了哪些投递”。
3. 后端核心模块实现细节
3.1 统一响应结构与全局异常处理
后端接口设计的第一步，是先约定一个统一的返回格式。如果没有统一格式，每个人写的接口各返各的，前端联调时就得天天对着接口文档猜字段。我用了一个很简单的Result类，包含code、message、data三个字段。code为200时表示成功，其他数字表示业务失败，401表示未登录，403表示无权限。
全局异常处理同样重要。SpringBoot的@RestControllerAdvice可以统一捕获异常，避免未处理的异常直接把堆栈信息抛给前端。我在实际项目里捕获了业务异常、参数校验异常、数据库异常和兜底的Exception，每个都返回对应的错误码。这样前端拿到的是友好的提示文案，而不是一片红色的报错信息。
3.2 JWT认证与权限拦截
登录认证这块，我使用JWT做无状态认证。用户登录成功后，后端用Hutool的JWT工具签发Token，把用户ID和角色信息放进Token里，返回给前端。前端把Token存在localStorage里，每次请求在拦截器中放到请求头。后端写一个拦截器，专门解析Token并校验有效期，再把当前用户信息放进ThreadLocal供后续使用。
权限控制上，我做了一个@RequireRole注解，标注在Controller方法上，拦截器里比对当前用户角色和注解要求的角色是否匹配。比如投递接口只允许学生调用，岗位审核接口只允许管理员调用。这套方式简单有效，不需要引入Spring Security那么重的完整框架，对课程设计和中小型项目来说是性价比最高的方案。
ThreadLocal这一块提醒大家用完要记得remove，否则在高并发场景下可能出现用户信息串号的问题。我在实际开发中踩过这个坑，排查了很久才发现是线程池复用导致ThreadLocal里旧数据没清掉。
3.3 岗位发布与多条件分页查询
岗位搜索是系统使用频率最高的接口，也是MyBatis动态SQL最能体现价值的地方。学生端需要按岗位名称、城市、行业、薪资范围、发布时间等条件组合筛选，如果每个组合都写一条SQL，那工作量无法想象。MyBatis的if标签配合where标签可以很好地解决这个问题。
以城市和薪资查询为例，动态SQL大致是这样的：
xml复制<select id="selectPostPage" resultType="com.example.vo.PostVO">
SELECT p.*, e.ent_name, e.industry
FROM tb_post p
LEFT JOIN tb_enterprise e ON p.ent_id = e.id
WHERE p.status = 2 AND p.deleted = 0
<if test="postName != null and postName != ''">
AND p.post_name LIKE CONCAT('%', #{postName}, '%')
</if>
<if test="city != null and city != ''">
AND p.city = #{city}
</if>
<if test="industry != null and industry != ''">
AND e.industry = #{industry}
</if>
<if test="minSalary != null">
AND p.salary_max >= #{minSalary}
</if>
<if test="maxSalary != null">
AND p.salary_min <= #{maxSalary}
</if>
<choose>
<when test="sortType == 1">
ORDER BY p.create_time DESC
</when>
<when test="sortType == 2">
ORDER BY p.salary_max DESC
</when>
<otherwise>
ORDER BY p.view_count DESC
</otherwise>
</choose>
</select>
分页使用PageHelper插件，只要在查询前调用PageHelper.startPage(pageNum, pageSize)，然后正常执行查询语句，返回结果就会被自动包装成带total和分页信息的对象。要注意PageHelper只对紧随其后的第一条SQL生效，中间不能穿插其他数据库操作，这是一个很常见的误用点。
3.4 投递流程与状态流转控制
投递功能看似简单，就是一个insert操作，但业务上有一堆约束要处理。学生不能重复投递同一岗位，学生必须完善了简历才能投递，已下架的岗位不允许投递。这些校验逻辑放在service层，而不是Controller层，这样才能保证不同入口调用时逻辑一致。
投递状态我用一个状态机来理解：1表示待筛选，企业端对简历做出处理后，状态变为2已通过或3未通过。学生如果投错了岗位，在待筛选状态下可以撤销，撤销后状态变为4。后端定义一个状态流转常量类，所有状态变更都通过统一方法处理，避免在业务代码里到处写死数字。
批量操作也值得一提。比如教师端需要把多个学生的投递记录一键标记为已查看，如果一个个循环update，数据量上来之后性能会很差。这里我用了MyBatis的foreach标签做批量更新，并在JDBC连接串中添加rewriteBatchedStatements=true参数，实测导入几千条数据时速度快了好几倍。
4. 前端Vue3实现要点
4.1 工程搭建与依赖配置
前端使用Vite作为构建工具，创建项目时选择Vue3 + JavaScript模板。Vite相比Webpack最大的优势就是快，启动项目秒级响应，开发体验非常好。项目依赖除了Vue3全家桶外，UI组件库选择了Element Plus，图表用ECharts，富文本编辑器用wangEditor，HTTP请求用Axios，状态管理用Pinia。
Element Plus的引入方式有两种：全量引入和按需引入。全量引入简单省事，但打包体积大；按需引入需要额外配置，但对最终部署更友好。我的建议是课程设计直接用全量引入就好，把精力花在业务实现上，正式商业项目再考虑按需加载。
启动项目后直接在vite.config.js里配置开发代理，解决本地联调的跨域问题：
javascript复制export default defineConfig({
plugins: [vue()],
server: {
port: 3000,
proxy: {
'/api': {
target: 'http://localhost:8080',
changeOrigin: true
}
}
}
})
这样前端请求/api/开头的接口时，会自动转发到后端8080端口，前端不用在axios配置里写完整的后端地址，也规避了CORS跨域的问题。
4.2 Pinia状态管理与登录状态持久化
Pinia是Vue3官方推荐的状态管理库。在这个系统里，我主要用Pinia存储登录用户信息和权限标识。用户登录成功后，把用户基本信息、角色、Token存到Pinia，同时写入localStorage。页面刷新时，Pinia里的状态会丢失，所以需要在App加载时从localStorage恢复用户状态，然后根据角色动态生成路由。
登录流程大致是这样的：用户输入账号密码，前端调用登录接口，拿到Token和用户信息后存入Pinia和localStorage，然后调用loadUserInfo获取更完整的用户资料，再根据用户角色调用菜单接口。整个流程串起来之后，页面刷新就不会掉登录状态了。
这里有一个很实用的经验：不要把用户的所有信息都放到Pinia里，只需要放当前页面一定会用到的数据，比如用户名、角色、头像。其他资料在需要时再请求接口获取，这样能减少状态不同步带来的bug。
4.3 Axios封装与Token自动携带
Axios如果不封装，每个页面都写一遍请求逻辑，代码会非常冗余。我在utils/request.js里创建了一个axios实例，设置基础URL和超时时间，然后通过请求拦截器自动附加Token。响应拦截器统一处理返回结果，当code为401时自动跳转到登录页，当code为其他错误时用Element Plus的Message组件弹出提示。
关于Token过期的问题，我用的处理方式是：后端在Token过期时返回code为401，前端拦截器收到401就清除本地存储并跳转到登录页。这种做法简单直接，适合课程设计。如果要做得更完善，可以加刷新Token机制，登录后同时返回AccessToken和RefreshToken，前者过期后用后者重新换取，用户就不会在使用过程中突然被踢下线了。
4.4 核心页面的数据流与组件设计
前台岗位列表页是系统里最复杂的页面。页面左侧是筛选条件面板，右侧是岗位卡片列表。用户选择城市、输入关键词、点击筛选后，前端把筛选条件封装成params对象传给后端接口。每次筛选条件变化时重新请求数据，使用loading状态避免用户重复点击，列表滚动到底部时自动加载下一页，实现无限滚动效果。
岗位详情页里展示了企业信息、职位描述、工作要求、薪资福利等。由于职位描述是用富文本编辑器发布的，返回的是一段HTML字符串，前端要用v-html渲染，这里必须注意XSS风险，后端要对富文本内容做过滤，不允许script标签直接入库。
投递记录页是学生查看自己投递状态的核心入口。页面用表格展示数据，状态列根据数字转成对应标签展示，待筛选显示为黄色Tag、已通过显示为绿色Tag、未通过显示为红色Tag。同时提供撤销投递操作按钮，只有待筛选状态的记录才允许撤销。
后台管理端的统计页面用ECharts做了三个图表：企业发布岗位数量排名柱状图、每月投递量趋势折线图、各专业学生投递情况饼图。数据来源是后端专门的统计接口，通过SQL分组聚合统计，比如统计投递趋势的SQL核心就是用DATE_FORMAT函数按月分组然后count。
5. 数据库初始化与系统部署
5.1 MySQL初始化与初始化数据准备
数据库设计好后，需要把建表语句整理成sql脚本。我习惯在脚本中加入初始数据，包括管理员账号、测试学生账号、演示企业和一批岗位数据。这样其他同学拿到项目后，执行一条命令就能把数据库初始化好。
连接MySQL时的配置要特别注意几个坑。MySQL 8.0之后驱动类是com.mysql.cj.jdbc.Driver，和老版本的com.mysql.jdbc.Driver不同。JDBC连接串里必须加serverTimezone参数指定时区，否则会报错。
yaml复制spring:
datasource:
driver-class-name: com.mysql.cj.jdbc.Driver
url: jdbc:mysql://localhost:3306/internship_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai
username: root
password: 123456
如果是跟着MySQL安装教程装的8.0版本，建库的时候要注意字符集设置，统一使用utf8mb4，因为utf8mb4支持emoji表情和更多特殊字符，而且和utf8mb4_general_ci排序规则兼容性最好。建表语句里也要显式指定字符集，否则连接串设了编码表结构不对一样乱码。
5.2 后端打包与前端构建部署
后端部署的第一步是mvn clean package打包，打包前要注意配置文件里不要写死了数据库密码，最好通过环境变量注入。打包成功后生成internship-server.jar文件，命令行执行java -jar就能启动服务。
一个让新手非常头疼的问题是：本机用的JDK8，但项目用SpringBoot 3.x构建，而SpringBoot 3.x要求JDK17以上。如果你用的SpringBoot版本太高，启动时经常会报UnsupportedClassVersionError，这是因为JDK版本不匹配。课程设计项目建议直接使用JDK8 + SpringBoot 2.7.x组合，稳定且市面上的教程几乎都适用。
前端构建很简单，执行npm run build之后生成dist目录，包含静态文件。部署方式有两种：一种是直接用Nginx托管前端静态文件，同时把/api请求反向代理到后端端口；另一种是直接把dist目录扔进后端项目的resources/static里，让SpringBoot同时提供前端页面和API接口。我推荐第一种，毕竟前后端分离的项目如果部署还混在一起，就失去了分离的意义。
5.3 Nginx配置与域名访问
Nginx配置的核心是端口监听、静态文件路径、API代理和前端路由兼容。Vue3采用的是history模式路由，页面刷新时Nginx会返回404，需要配置try_files把所有请求都引导到index.html。这一点不配置好的话，会出现“首页能打开，一刷新子页面就404”的诡异问题。
nginx复制server {
listen 80;
server_name your-domain.com;
location /api/ {
proxy_pass http://127.0.0.1:8080/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location / {
root /www/wwwroot/internship/dist;
index index.html;
try_files $uri $uri/ /index.html;
}
}
部署完成后可以通过http://your-domain.com访问系统。HTTP协议下请求是明文传输的，如果登录密码被中间人截获就麻烦了，有条件的话建议配置HTTPS，申请免费证书的成本已经很低了。
6. 常见问题与排查技巧实录
6.1 SpringBoot启动与配置类问题
这一块是初学者翻车最频繁的地方。最近网上很多人反馈SpringBoot版本太高导致项目起不来，原因多半是SpringBoot 3.x需要JDK17以上，而本机装的是JDK8。碰到这类问题，最直接的解决办法是先把JDK版本对齐，或者把项目降到SpringBoot 2.7.x。还有一种情况是依赖下载不下来，Maven卡在downloading...，多半是镜像源问题，在settings.xml里配置阿里云镜像可以解决。
另外一个高频报错是“Failed to configure a DataSource”，通常有三种原因：pom.xml里依赖了数据源相关包但没配置数据库连接；application.yml里配置了但连接参数有误；数据库服务没启动。解决思路很简单，自查顺序是：数据库有没有启动、账号密码对不对、连接串格式对不对、驱动的依赖有没有引入。
6.2 MyBatis映射与SQL问题
Mapper接口方法对应找不到SQL语句，报Invalid bound statement，是MyBatis项目里最经典的报错。原因一般是三种：Mapper接口和XML文件的namespace不匹配；XML文件没放在MyBatis扫描路径下；接口方法名和XML里的id不一致。我在项目里把XML文件放在resources/mapper目录，然后在application.yml里配置mapper-locations指定扫描路径，同时用@MapperScan注解扫描接口包，这样基本不会出问题。
XML里写查询条件时，小于号、大于号这类特殊符号要转义。如果写成p.salary_min < #{maxSalary}，XML解析直接报错，需要转换成<和>。我在前面的动态SQL示例里已经用了转义后的写法，这是MyBatis开发的基本功。
MyBatis缓存也是各路面试题里的常客。一级缓存是SqlSession级别的，默认开启，同一个SqlSession执行两次相同的查询会命中缓存。二级缓存是namespace级别的，默认关闭，开启后需要实体类实现Serializable接口。在并发场景下二级缓存如果使用不当，很容易出现脏数据问题，所以这个项目里我保持默认配置，没有开启二级缓存。
6.3 前端状态与渲染问题
Vue3的响应式系统比Vue2变化很大，很多人会把Vue2的思维带过来，结果出现“数据变了但页面不更新”的问题。最典型的场景是使用reactive定义数组，然后直接按下标赋值：list[index] = data，这在Vue2里没问题，但Vue3中reactive数组通过下标直接赋值是能触发更新的，如果用的是ref定义的数组按下标赋值就不行。更稳妥的做法是使用splice或者整体替换数组。
还有一类问题是组件渲染时机。用v-for渲染长列表，数据源更新后页面没有立即刷新，检查一下是不是对数组做了push之外的操作，或者使用了索引作为key。如果key变化频繁，Vue会重新渲染整个列表，性能会明显下降。这里建议优先使用业务ID作为key，而不是数组索引。
6.4 数据与性能问题
投递记录数量上来之后，分页查询会变慢。排查思路是先看SQL执行计划，确认是否走索引。我在投递表的student_id、post_id字段上建了联合索引，查询性能明显改善。如果索引已经建了还是慢，看看SQL里有没有函数包裹索引列，比如WHERE DATE(create_time) = '2025-01-01'这种写法会导致索引失效，应该改成范围查询。
还有一个容易被忽视的问题是数据库连接池。SpringBoot默认连接池是HikariCP，配置里设置一个合理的最大连接数，默认10在并发高的时候可能不够。我一般会调到30，同时设置连接超时时间，防止出现连接泄漏后整个服务不可用。
数据备份这块也提一句，虽然课程设计阶段很多人不在乎，但真正上线后数据是无价的。我习惯写一个简单的shell脚本，每天凌晨用mysqldump备份整个数据库，保留最近7天的备份文件，这样即使出现误删数据的情况也能恢复。
写在最后
整套系统做下来，我的真实感受是：技术选型不是越新越好，项目里最高频的动作其实就是增删改查加条件筛选，把SpringBoot、Vue3、MyBatis这套组合吃透，已经能覆盖很大一部分企业级应用的开发需求。
如果你拿到源码第一件事不知道该干什么，我建议按这个顺序来：先把数据库脚本跑了，再把后端启动起来，前端npm install之后npm run dev，然后把系统所有页面点一遍，搞清楚每张表、每个接口、每个页面之间是怎么串起来的。跟着业务走通第一遍之后，再去研究代码细节，效率会高很多。
最后分享一个小经验：这个系统后续如果想扩展，最有价值的方向是消息通知模块，把企业审核结果、实习录用通知做成站内信加邮件双重通知，整个系统的用户体验会拉升一个档次。实习管理不只是一个信息展示网站，真正走到深处你会发现，校园里一切和流程相关的问题，最后拼的都是对业务的理解深度。