简介：一份面向Java毕业设计的高校实习信息发布网站论文参考文档，适合正在撰写毕业设计论文或需要搭建同类选题框架的本专科生使用。文档完整呈现毕业论文的摘要、目录、课题背景、开发目的与意义等主体结构，并结合管理员与用户双角色模式，梳理了职位实习信息发布、公告管理、在线交流等典型功能模块；同时围绕 B/S 架构、MVC 设计模式、Spring Boot、MySQL、MyBatis 等技术栈展开论述，为论文写作和系统设计提供思路参考。包体为单个 docx 文件，大小约 1.31MB，文件内容集中、便于直接查阅和排版修改。该资源目前已有 176 人浏览学习，适合作为毕业设计开题、论文初稿和格式参考的补充材料，可帮助理解该类毕业设计的选题思路、章节安排和关键技术描述方式。需要注意的是，该文档仅作为论文参考，并不包含项目源码和数据库文件。
1. 这个 Java 实习信息发布网站要解决的信息不对称问题
高校实习信息发布网站这种题目，在 Java Web 项目里出现频率极高，但大多数实现只停在「能跑」：岗位列表、学生投递、管理员审核，三个页面一拼就交差。这套系统真正值钱的不是页面数量，而是「岗位发布 — 简历投递 — 进度审核」这条主链路的业务规则和数据一致性，以及围绕它写出来的论文文档能不能把设计取舍讲清楚。这套方案面向两类人：一是要做毕业设计或课程设计的学生，可以把表结构和后端分层直接平移进自己的项目；二是想快速搭一套实习信息管理后端的 Java 开发者，需要知道哪里是坑。下面的实现统一使用 Spring Boot 2.7 + MyBatis + MySQL 5.7，兼容绝大多数学校的答辩环境，每一步都给出可复现的代码和参数。
2. 实习信息发布网站的表设计：从角色用例到 MySQL 建表
2.1 三方角色与用例：学生、企业、管理员各要什么
高校实习信息发布网站和普通招聘网站的区别在于「学校在场」：管理员要审核企业资质，学生投递简历后由企业处理，但学校能看到整体进展。围绕这个场景，角色的用例可以拆成三组：
- 学生端：注册登录、完善个人简历、浏览岗位列表、按关键词搜索、投递简历、查看投递状态
- 企业端：注册并提交资质材料、发布实习岗位、下架岗位、查看投递列表、标记通过或拒绝
- 管理员端：审核企业资质、管理学生与企业账号、发布实习公告、按学院或专业统计投递数据
每个角色对应后端一套独立的 Controller 前缀，例如/api/student、/api/company、/api/admin，这样在权限拦截时能靠 URL 前缀一把梭。用例边界定清楚之后，数据库的表数量基本也就定了。我见过不少把评论、收藏、消息全塞进表设计的方案，最后表有 20 张，代码却只写了 5 张，论文里只能贴建表语句硬凑字数。这个规模的项目，6 张主表足够覆盖全部演示场景。数量少不代表设计简单，关键在字段粒度：比如薪资字段拆成最高值和最低值两个列，比只存一个「面议」字符串更有利于将来做筛选和排序。
2.2 核心表设计：岗位、投递、简历三张表的字段与建表语句
先看整体表结构，论文里的数据库设计章节可以直接复用这张总表：
| 表名 | 职责 | 关键字段 |
|---|---|---|
| t_company | 企业信息与资质审核 | id、company_name、credit_code、contact_name、contact_phone、audit_status |
| t_job | 实习岗位发布 | id、company_id、job_title、job_type、salary_min、salary_max、need_num、apply_num、deadline、detail、status |
| t_resume | 学生简历主体 | id、student_id、real_name、school、major、graduate_year、skill_tags、self_eval |
| t_delivery | 投递行为记录 | id、student_id、job_id、status、create_time、update_time |
| t_notice | 站内公告 | id、title、content、publish_time |
| t_user | 统一登录账号 | id、username、password、role、status |
建库时最容易踩的坑是字符集。MySQL 5.7 默认 latin1，岗位描述里只要出现「数据分析」「产品运营」都没事，一出现中文偶尔就报Incorrect string value。建库时显式指定 utf8mb4：
CREATE DATABASE internship_db DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_general_ci;然后建岗位表，对应上面 t_job 的设计：
CREATE TABLE t_job ( id INT PRIMARY KEY AUTO_INCREMENT COMMENT '岗位ID', company_id INT NOT NULL COMMENT '企业ID，关联t_company.id', job_title VARCHAR(100) NOT NULL COMMENT '岗位名称', job_type VARCHAR(50) DEFAULT NULL COMMENT '岗位类型，如后端开发/产品运营', salary_min DECIMAL(10,2) DEFAULT 0 COMMENT '最低月薪(千元)', salary_max DECIMAL(10,2) DEFAULT 0 COMMENT '最高月薪(千元)', need_num INT DEFAULT 1 COMMENT '招聘人数', apply_num INT DEFAULT 0 COMMENT '已投递人数，冗余统计字段', deadline DATE COMMENT '投递截止日期', detail TEXT COMMENT '岗位描述', status TINYINT DEFAULT 1 COMMENT '1招聘中 0已下架', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_company_id (company_id), KEY idx_status (status) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='实习岗位表';几个参数在答辩时会被重点问到。DEFAULT CHARSET=utf8mb4是因为学生自我评价和企业岗位详情都可能带 emoji 或生僻字，utf8mb4 是唯一能稳定存储四字节字符的默认选择，utf8mb4_general_ci排序规则对中文按拼音排序够用。apply_num是冗余统计字段，用「空间换性能」一句话就能解释，但要在后续代码里做到插入投递记录时同步加一。deadline用 DATE 而不用 DATETIME，因为截止日期没有时分秒的业务含义，类型选到业务精度即可。
投递表是主链路的另一根柱子，它记录「谁在什么时间投了哪个岗位、当前处理到哪一步」：
CREATE TABLE t_delivery ( id INT PRIMARY KEY AUTO_INCREMENT, student_id INT NOT NULL COMMENT '学生ID', job_id INT NOT NULL COMMENT '岗位ID', status TINYINT DEFAULT 0 COMMENT '0待处理 1已通过 2已拒绝', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_student_job (student_id, job_id), KEY idx_job_id (job_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='投递记录表';uk_student_job是这张表的设计亮点，它把「不允许重复投递」从应用层下沉到数据库约束。即使两个请求同时在 Service 层通过了判断，第二个插入也会被数据库拒绝。这种「先想约束、再写代码」的顺序，在论文的系统设计章节里是明确的加分项。
2.3 用 MyBatis 把表结构映射成 Java 实体
表建完，下一步是把行映射成 Java 对象。对应 t_delivery 的实体类，我建议写成这样：
public class Delivery { private Integer id; private Integer studentId; private Integer jobId; private Integer status; private LocalDateTime createTime; private LocalDateTime updateTime; // 非表字段：关联查询填充，查询投递列表时直接显示岗位和企业 private String jobTitle; private String companyName; // getter / setter 省略 }注意实体里用的是Integer而不是int。数据库字段如果是 NULL，映射到基本类型int会直接抛异常，这也是 Java 基础面试里的高频题目：包装类型才能表达「值不存在」的语义。论文里写实体类时，凡是外键、状态、排序字段都用 Integer，而自身必须有值的属性如姓名、标题等，可以用 String 保证非空。
查询投递列表时要带出岗位标题和企业名称，常见做法是写一个 VO 查询，用 LEFT JOIN 一次查出：
<select id="selectMyDeliveryList" resultType="com.example.internship.entity.Delivery"> SELECT d.id, d.job_id, d.status, d.create_time, j.job_title, c.company_name FROM t_delivery d LEFT JOIN t_job j ON d.job_id = j.id LEFT JOIN t_company c ON j.company_id = c.id WHERE d.student_id = #{studentId} ORDER BY d.create_time DESC </select>WHERE里的studentId是唯一入参，ORDER BY create_time DESC保证学生看到的是最新投递在前。两个 LEFT JOIN 都是通过主键关联，扫描行数可控，在演示数据几千条的量级下性能没有问题。将来数据量大，再按student_id + status建联合索引即可，这个优化点也可以写进论文的「进一步工作」。
提示：主键一律用自增 int，不要用学号或企业统一信用代码做业务主键。业务字段会有变更可能，而自增主键在写论文时更容易讲清关联关系。
3. Java 后端分层实现：投递简历这条主链路怎么跑通
3.1 Maven 依赖与工程结构：从 JDK 配置到可运行项目
开始写代码前，先确认本机已装 JDK 8 并配置好JAVA_HOME环境变量。国内多数学校的实验课和答辩机还在用 JDK 8，用新版本 JDK 跑旧项目会出现「源发行版 17 需要目标发行版 17」这类编译期报错，现场调环境非常被动。
配套的 pom.xml 用 Spring Boot 2.7.18 而不是 3.x，原因是 2.7 处于维护期尾声、资料最全，mybatis-spring-boot-starter2.3.x 与它完全兼容。如果换成 3.x，javax.servlet要批量替换为jakarta.servlet，这个迁移成本在答辩演示当天不值得冒：
<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> <relativePath/> </parent> <properties> <java.version>1.8</java.version> </properties> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.3.2</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.33</version> <scope>runtime</scope> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> </dependencies>这里有两处要额外说明。数据库驱动用 8.0.33 而连接的是 MySQL 5.7，驱动本身向下兼容 5.x，但 URL 里必须带useSSL=false&serverTimezone=Asia/Shanghai参数，否则启动就报时区相关 SQLException。Lombok 在部分新版本 JDK 的 IDE 下会失效，报java: You aren't using a compiler supported by lombok，出现这个问题时检查 IDE 是否开启了 Annotation Processing，而不是怀疑依赖写错。
工程分包建议按职责划分，Controller 只做参数接收、Service 只做业务、Mapper 只做数据访问：
com.example.internship ├── controller # 接口层 ├── service # 业务层，事务和状态迁移在这里 ├── mapper # MyBatis Mapper 接口 ├── entity # 与表结构对应的实体 ├── vo # 视图对象，关联查询结果 └── config # 拦截器、CORS、全局异常处理3.2 Service 层：投递状态机的业务规则
投递是整个系统最核心的一个动作，它包含三条业务规则：岗位必须存在且状态为「招聘中」；学生不能重复投递同一岗位；投递成功后，岗位的已投递人数加一。把这三条规则放在同一个方法里，并用事务包住：
@Service public class DeliveryService { @Autowired private DeliveryMapper deliveryMapper; @Autowired private JobMapper jobMapper; @Transactional(rollbackFor = Exception.class) public void deliver(Integer studentId, Integer jobId) { Job job = jobMapper.selectById(jobId); if (job == null || job.getStatus() != 1) { throw new BizException("岗位不存在或已停止招聘"); } if (deliveryMapper.countByStudentAndJob(studentId, jobId) > 0) { throw new BizException("请勿重复投递"); } Delivery delivery = new Delivery(); delivery.setStudentId(studentId); delivery.setJobId(jobId); delivery.setStatus(0); deliveryMapper.insert(delivery); jobMapper.increaseApplyNum(jobId); } }这段代码里的@Transactional(rollbackFor = Exception.class)不是随便加的。rollbackFor的默认行为是只对 RuntimeException 回滚，而BizException如果定义为 checked exception，不写这个参数事务就不会回滚，最终出现「投递记录插入成功、岗位人数没加」的数据不一致。这里明确指定对所有异常回滚，是业务代码里最常见的正确写法。
increaseApplyNum对应的 SQL 也值得单独看一眼：
@Update("UPDATE t_job SET apply_num = apply_num + 1 WHERE id = #{jobId}") int increaseApplyNum(Integer jobId);这里没有先查再改，而是用数据库自增表达式一次完成，避免并发下读到旧值覆盖新值。这种原子更新思路答辩时可以用一句话讲清楚：投递人数是计数型冗余字段，必须用数据库表达式做原子递增，不能在 Java 里先查出来再 set 回去，那样两个线程同时投递时会丢失一次计数。
3.3 Controller 层：接口设计与参数校验
Controller 只做三件事：取当前登录用户、校验入参、调用 Service。投递接口的设计：
@RestController @RequestMapping("/api/delivery") public class DeliveryController { @Autowired private DeliveryService deliveryService; @PostMapping("/submit") public Result submit(@RequestParam(required = false) Integer jobId, HttpSession session) { Integer studentId = (Integer) session.getAttribute("studentId"); if (studentId == null) { return Result.error("请先登录"); } if (jobId == null || jobId <= 0) { return Result.error("岗位参数不合法"); } deliveryService.deliver(studentId, jobId); return Result.success("投递成功"); } }这里的session.getAttribute("studentId")是关键：学生身份从服务端 Session 拿，而不是让前端传 studentId 过来。如果接口允许前端传入 studentId，就存在水平越权——改一个参数就能替别人投简历，这是答辩评委最常挑的安全问题。写进论文时可以说「所有接口的当前用户标识一律从会话上下文获取，业务方法只接收业务参数」，一句话就是一条设计原则。
3.4 登录拦截器与 java 动态代理的对照
登录和角色控制，常见做法是写一个HandlerInterceptor，按 URL 前缀区分权限。下面是完整实现：
public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String uri = request.getRequestURI(); HttpSession session = request.getSession(); if (uri.startsWith("/api/student") && session.getAttribute("studentId") == null) { response.setStatus(401); return false; } if (uri.startsWith("/api/company") && session.getAttribute("companyId") == null) { response.setStatus(401); return false; } if (uri.startsWith("/api/admin") && !"ADMIN".equals(session.getAttribute("role"))) { response.setStatus(403); return false; } return true; } }这段代码把三道访问规则写在一个类里，比配一整套 Spring Security 过滤链更适合课程设计篇幅。三个分支分别拦学生、企业、管理员，逻辑直白。拦截器在 Spring MVC 底层是通过反射回调实现，原理层面和 java 动态代理同源，论文的系统实现部分可以提一句「通过拦截器统一完成身份校验，避免在每个接口内重复编写鉴权代码」。
注意：拦截器只解决「有没有登录」和「角色对不对」，解决不了「这个学生能不能操作这条数据」。数据级权限要放在 Service 层校验，比如学生只能查看自己的投递记录，这类校验写在 Service 里。
4. 论文与设计文档：实习信息发布网站的写作顺序与素材
4.1 论文大纲：章节结构与字数分配
写论文的顺序，我不建议从绪论开始。先把系统功能全部做出来，边做边截图边记录测试数据，最后再回头补绪论和需求分析，效率和真实度都更高。这里给出一份经过验证的章节结构，对应用时可以按这个节奏推进：
| 论文章节 | 建议字数 | 写作要点 |
|---|---|---|
| 绪论 | 1500~2000 | 背景和意义，「信息不对称」「传统通知方式的效率问题」是关键词 |
| 需求分析 | 2000~2500 | 用例图 + 文字用例描述，三个角色各一张用例图 |
| 系统设计 | 3000~4000 | 总体架构、功能模块图、E-R 图、数据表设计 |
| 系统实现 | 3000~4000 | 分层代码 + 界面截图，与系统设计一一对应 |
| 系统测试 | 1500~2000 | 5 个核心用例的测试步骤和预期结果 |
| 总结与展望 | 500~800 | 不足与下一步方向 |
4.2 E-R 图画到什么程度：实体、主键、关系线
很多同学在画图上花的时间比写代码还多，没有必要。E-R 图画到「实体 + 主键 + 主要属性 + 关系」即可，关系线标清楚一对多。例如学生与投递是 1 对 N，企业与岗位是 1 对 N，岗位与投递是 1 对 N。三张图画完，数据库设计一节就有了核心素材。用例图按角色分三张，每个角色画 4~6 个用例，不要贪多。比如「学生」画注册登录、完善简历、搜索岗位、投递简历、查看投递状态，五个正好。流程图只需要两条业务主线：企业发布岗位的流程、学生投递简历的流程，用「开始 → 填写岗位信息 → 提交审核 → 审核通过 → 上架展示 → 结束」这样的文字描述即可，不强制用绘图工具。
4.3 核心代码摘录的标准：删什么、留什么
论文里的代码不是把源码复制粘贴进去，而是选「体现设计思路」的片段。合格的代码摘录有三个特征：能独立说明一个业务闭环、方法注释在 3 行以内、变量名能自解释。以投递方法为例，下面是论文中「系统实现」一节的标准摘录方式：
/** * 学生投递简历 * 1. 校验岗位是否可投递 * 2. 校验是否重复投递 * 3. 插入投递记录 * 4. 岗位申请数加一 */ @Transactional(rollbackFor = Exception.class) public void deliver(Integer studentId, Integer jobId) { Job job = jobMapper.selectById(jobId); if (job == null || job.getStatus() != 1) { throw new BizException("岗位不存在或已停止招聘"); } if (deliveryMapper.countByStudentAndJob(studentId, jobId) > 0) { throw new BizException("请勿重复投递"); } Delivery delivery = new Delivery(); delivery.setStudentId(studentId); delivery.setJobId(jobId); delivery.setStatus(0); deliveryMapper.insert(delivery); jobMapper.increaseApplyNum(jobId); }摘录时可以删掉依赖注入的注解细节、日志打印和无关空行，保留关键参数名和状态值。这样答辩被问到「为什么先查岗位再查投递」时，可以顺着代码直接回答：先校验岗位状态避免无效投递，再校验重复性避免脏数据，最后才是写库操作。不要贴整个 Controller 类，接口层的内容用一个 HTTP 响应截图代替更直观。
4.4 测试用例表与演示数据
系统测试章节不要写「测试结果全部通过」这种空话，用表格列出核心用例和预期结果：
| 用例名称 | 前置条件 | 操作步骤 | 预期结果 |
|---|---|---|---|
| 学生注册 | 数据库无重复用户名 | 填写注册表单并提交 | 跳转登录页，新账号可登录 |
| 企业审核 | 存在已注册待审核企业 | 管理员点击通过审核 | 企业账号状态变为已审核，可发布岗位 |
| 学生投递 | 岗位状态为招聘中 | 学生点击投递按钮 | 投递记录出现，岗位已投人数加一 |
| 重复投递 | 学生已投递该岗位 | 再次点击投递 | 提示「请勿重复投递」 |
| 超期岗位 | 岗位超过截止日期 | 学生尝试投递 | 投递按钮置灰，接口返回岗位已停止招聘 |
演示数据的准备也有讲究。真实感是第一位，全部用「张三」「测试岗位」这种命名会让答辩显得敷衍。建议准备 8 家企业、20 个岗位、10 个学生的数据，岗位名称用「Java 后端开发实习生」「新媒体运营实习生」这类真实标题，简历内容写 2~3 行即可。准备好之后导出一份 init.sql，答辩前重建库、执行 SQL、截图，整个演示也就五分钟。
5. 答辩前要验证的 3 个细节：事务、时区、演示数据
5.1 事务回滚怎么验证
投递接口写好了@Transactional，怎么在答辩前确认它真的生效？常见做法是在deliveryMapper.insert之后、increaseApplyNum之前临时加一行int i = 1 / 0;制造运行时异常，然后重新发起投递，查询 t_delivery 是否还有新增记录。没有记录，说明事务生效；有记录，说明注解没生效或类没有被 Spring 管理。验证完删除测试代码，执行重建脚本恢复数据。这一步花两分钟，能避免答辩现场演示时出现「投递成功但人数没变」这种最尴尬的情况。
5.2 时区与格式化配置
系统在本地正常、部署到服务器后时间差 8 小时，是 Java Web 项目里最常见的时间问题。原因是 JDBC 连接串没指定时区，MySQL 按系统时区解析。在 application.yml 里固定这套写法：
spring: datasource: url: jdbc:mysql://localhost:3306/internship_db?useSSL=false&serverTimezone=Asia/Shanghai jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/ShanghaiserverTimezone=Asia/Shanghai解决 JDBC 驱动读取时间的时区偏移，jackson.time-zone解决 JSON 序列化时前端看到的字符串与数据库不一致。两个参数成对出现，缺一个就会在某些机器上出现「本地时间正确、服务器时间差 8 小时」的诡异现象。答辩前可以故意把serverTimezone改成UTC演示一次时间错乱，再把配置改回来，这是一个很好的加分演示。
5.3 一键初始化演示数据
答辩时间有限，把数据初始化封装成一个 Spring Boot 启动任务，重建数据库后启动就有完整数据，不用手工往页面里一条条录：
@Component public class DataInitializer implements CommandLineRunner { @Override public void run(String... args) { if (userMapper.count() > 0) { return; } initUsers(); initCompanies(); initJobs(); initDeliveries(); } }userMapper.count() > 0这个判断保证只在空库时填充数据，不会覆盖已有记录。初始化数据用写死的 ID 互相关联，避免自增 ID 不确定导致投递记录关联错位。执行顺序必须是用户 → 企业 → 岗位 → 投递，因为投递记录依赖前面三张表的数据，这个依赖顺序保证了数据的完整性。
本文还有配套的精品资源，点击获取
