企业官网建设流程全解析

这篇帖子我憋了很久想写。每年到这个时候，总能看到一堆人在群里问“计算机毕设做什么题目好”“SSM还流不流行”“毕设管理系统怎么下手”。其实很多人口中的“烂大街”题目，恰恰是最稳、最适合拿来练手和过答辩的。就拿今天要聊的这个“高校毕业实习管理系统”来说，技术上是经典的Spring + SpringMVC + MyBatis三件套，业务上是高校里真实存在、逻辑清晰、流程闭环的典型场景。你把它吃透了，不光能交出一份像样的毕设，顺带把Java后端开发的基本功也重新捋了一遍。这篇文章我就用自己做这类项目时的实际经验，把这个题目从需求到设计、从数据库到核心代码、从踩坑到答辩，完完整整拆给你看。

1. 项目全景拆解：高校毕业实习管理的业务主线和功能清单

1.1 先搞懂真实的业务场景，别急着写代码

很多同学做毕设最容易犯的毛病，就是一上来就建表、写接口，结果做到一半发现逻辑对不上。做管理系统这类题目，第一步一定是把业务场景吃透。

高校毕业实习这个事，真实的流程大概是这样的：大四学生临近毕业前，学校会安排或者学生自主联系实习单位。实习不是学生说了算，也不是老师拍脑袋就行的，中间牵扯到单位审核、指导老师确认、学院备案、实习过程中的材料提交，最后还有成绩评定。整个链条走下来，涉及的人员有学生、指导老师、学院管理员、系统管理员四类角色。

这个题目之所以叫“全流程管理系统”，就是因为要把实习前、实习中、实习后三个阶段全部管起来：

• 实习前：单位信息录入、岗位发布、学生申报、老师审核、实习分配
• 实习中：学生提交周报/月报、指导老师查看反馈、实习单位变更申请
• 实习后：学生提交实习总结、单位给出评价、老师评定成绩、学院统计汇总

你把这几个阶段列出来，功能模块基本就出来了。这个业务逻辑非常适合做成毕设，因为它不是那种只有CRUD的假大空系统，而是有一条完整的状态流转线，能把SSM框架每一层的作用都发挥出来。

1.2 四类角色和对应的权限边界

系统里最核心的设计依据，就是角色权限。这里我的建议是分成四类角色，不要贪多：

这四类角色就是系统的骨架，后面所有设计都要围着它们转。尤其是权限这块，SSM里面做权限控制最常用的就是拦截器加Session判断，后面我会专门讲代码实现。

1.3 功能模块清单：照着这张表做不会漏

我把这个系统的功能列成一个完整清单，你做需求分析和写论文的时候可以直接参考：

1. 登录与注册模块：用户登录、角色识别、验证码（可选）、退出登录
2. 基础信息管理：学院、专业、班级、用户的增删改查
3. 实习单位管理：单位信息维护、岗位发布、岗位下线、单位搜索
4. 实习申报模块：学生提交申请、选择意向岗位、教师审核、驳回并填写理由
5. 实习分配模块：管理员统筹分配、调整指导老师
6. 过程管理模块：周报提交、周报批阅、实习变更申请、考勤登记
7. 成绩评定模块：单位评分、教师评分、综合成绩计算、成绩导出
8. 统计报表模块：各学院实习率统计、岗位热门度排行、实习完成率

这八个模块，基本就是这个系统最完整的覆盖范围了。你要是时间紧，考勤登记和成绩导出可以做成简单版，但前六个模块尽量做完整，因为它们是系统的骨架，也是答辩时老师主要追问的地方。

2. 技术选型解析：为什么毕设题目还是绕不开SSM

2.1 SSM框架和Spring Boot到底怎么选

现在很多学校已经开始教Spring Boot了，但绝大部分课程设计和毕设题目里，SSM依然是出现频率最高的关键词。这里有个很现实的原因：SSM的代码量更大、配置更繁琐，反而更适合用来考察学生对框架底层原理的理解。Spring Boot把很多东西自动配置好了，学生反而说不清楚内部干了什么，答辩时一问就露馅。

我个人的建议是，如果题目明确要求SSM，就老老实实写SSM。如果题目没限定，你可以考虑用Spring Boot复刻这个系统，但核心业务代码可以照搬。SSM和Spring Boot在业务层的写法上几乎一样，主要区别在配置方式上。你如果用SSM做，答辩前一定把Spring IOC、AOP、SpringMVC的执行流程、MyBatis的映射原理都过一遍，这是被问到概率最高的四个点。

2.2 经典三层架构和包结构设计

SSM的典型架构就是Controller-Service-Mapper三层。Controller负责接收请求和返回视图，Service负责业务逻辑，Mapper负责数据库操作。实体类单独放一个包，工具类、拦截器、公共类也要单独分出来。

我推荐的项目包结构是这样：

com.xxx.internship ├── controller // 控制层 │ ├── StudentController.java │ ├── TeacherController.java │ └── AdminController.java ├── service // 业务层接口 ├── service.impl // 业务层实现 ├── mapper // MyBatis映射接口 ├── entity // 实体类 ├── interceptor // 登录拦截器、权限拦截器 ├── util // 工具类、统一返回结果 ├── vo // 视图对象，用于展示层封装 └── dto // 数据传输对象

为什么要分VO和DTO？很多新手不理解，觉得实体类一个类走天下就行。实际做项目时你会发现，页面要展示的数据往往不是单表实体能直接满足的，比如“实习进度列表”可能需要同时显示学生姓名、班级、单位名称、岗位名称、当前状态，这部分数据用一个VO对象封装最合适。这样做的好处是Controller层不用手动拼map，代码可读性也强。

2.3 核心依赖配置和Maven引入

SSM项目的pom.xml是整个工程的基础，我这里给一个最小可跑通的依赖集合。注意版本不是越新越好，我用的是经过大量项目验证的稳定组合：Spring 5.2.x、MyBatis 3.5.x、MyBatis-Spring 2.0.x。

<dependencies> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>5.2.22.RELEASE</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-webmvc</artifactId> <version>5.2.22.RELEASE</version> </dependency> <dependency> <groupId>org.mybatis</groupId> <artifactId>mybatis</artifactId> <version>3.5.6</version> </dependency> <dependency> <groupId>org.mybatis</groupId> <artifactId>mybatis-spring</artifactId> <version>2.0.6</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.28</version> </dependency> <dependency> <groupId>com.github.pagehelper</groupId> <artifactId>pagehelper</artifactId> <version>5.2.0</version> </dependency> <dependency> <groupId>jstl</groupId> <artifactId>jstl</artifactId> <version>1.2</version> </dependency> </dependencies>

这里特别留意，MySQL的驱动版本一定要跟本地数据库版本匹配。如果你用的是MySQL 5.7以下，就改用5.1.49版本的驱动，否则会报通讯链路异常。数据库连接串也别忘加时区和编码参数，这点我在后面踩坑章节还会细说。

3. 数据库设计实战：从业务实体到表结构的完整梳理

3.1 核心表清单和它们的关系

数据库设计是这类管理系统最重要的一步，表关系理不清，后面写SQL就是灾难。我建议至少要设计下面这几张表：

这里要注意一个关键设计，我把用户基础信息放在tb_user，把学生和教师的具体信息拆到扩展表。这样做的好处很明显，一个账号以后如果需要同时具备多种角色，不用改表结构。虽然毕设系统的用户角色通常固定，但答辩时如果老师问“用户表和角色扩展表为什么分开”，你也能说出个子丑寅卯，显得你有设计意识。

3.2 状态字段用什么类型、怎么定状态值

这类系统里最容易被忽视的就是状态字段。我的建议是，所有状态都用int类型存储，不要用varchar存中文，也不要存英文单词。因为int类型在页面判断时写起来最方便，SQL查起来也最省事。定义一个统一的状态字典，写在代码里或者写成常量类都可以。

实习申请单的状态流转，我建议这样定义：

之所以要把草稿和待审核分开，是因为真实业务里学生很可能会先把申请填一半，或者发现填错要改。如果没这个状态，系统就没法支持“撤回后修改再提交”这个操作，流程上就少一环。

3.3 建表时的几个实用细节

建表时我有几个习惯，做这个系统时也用上了：

第一，所有表都要有create_time和update_time两个字段。虽然毕设系统可能用不上复杂的时间追踪，但有这两个字段，后面写论文画E-R图、做日志记录都会方便很多。

第二，业务唯一约束要想清楚。比如同一名学生同一时间段只能有一条有效的实习申请记录，这个逻辑在表层面最好加上唯一索引，否则并发情况下会出问题。MyBatis写update语句时先select再insert也不是不行，但表层面有约束，心里踏实。

第三，外键我建议逻辑上保留，物理上不要加。也就是说你在关系上明确学生表关联用户表，但建表语句中不写FOREIGN KEY。原因也很简单，物理外键在删除和批量导入数据时会拖累性能，而且毕设系统里大部分删除操作都是逻辑删除（加一个deleted字段），物理外键意义不大。这部分如果答辩老师追问，你可以回答“用应用层保证数据一致性，用逻辑外键降低耦合度”，这就体现了你的思考深度。

4. 核心业务模块的SSM落地实现

4.1 登录认证与角色权限拦截器

SSM里做登录和权限控制，最经典也最直接的方式就是拦截器。配置好拦截器之后，核心思路是：用户登录成功后把用户对象放进Session，拦截器在每个请求进来时检查Session里有没有这个人，没有就跳转到登录页，有就再判断一下角色能不能访问这个路径。

登录拦截器实现起来不难，关键在配置路径时要细心。如果拦截范围配置成“/*”，静态资源和登录接口也会被拦截，新手经常在这里卡半天。我给的配置如下：

<mvc:interceptors> <mvc:interceptor> <mvc:mapping path="/**"/> <mvc:exclude-mapping path="/login"/> <mvc:exclude-mapping path="/captcha"/> <mvc:exclude-mapping path="/css/**"/> <mvc:exclude-mapping path="/js/**"/> <mvc:exclude-mapping path="/images/**"/> <bean class="com.xxx.internship.interceptor.LoginInterceptor"/> </mvc:interceptor> </mvc:interceptors>

拦截器对应的Java代码是核心，我一般写成这样：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); User user = (User) session.getAttribute("loginUser"); String uri = request.getRequestURI(); if (user == null) { // 判断是否为Ajax请求，分别处理 String requestedWith = request.getHeader("X-Requested-With"); if ("XMLHttpRequest".equals(requestedWith)) { response.setStatus(401); } else { response.sendRedirect(request.getContextPath() + "/login"); } return false; } // 按角色控制路径前缀，如 /student/** 只能学生访问 if (uri.startsWith("/student") && user.getRole() != 0) { response.sendRedirect(request.getContextPath() + "/403"); return false; } if (uri.startsWith("/teacher") && user.getRole() != 1) { response.sendRedirect(request.getContextPath() + "/403"); return false; } return true; } }

这里有两个心得。一个是Ajax请求要注意区分，如果页面用了jQuery的$.ajax，登录失效时后端如果直接sendRedirect，前端那边收不到有效的跳转，用户体验会很差。返回401状态码，让前端统一处理跳转，是最稳的做法。另一个是权限前缀规则要统一，学生端的请求都带/student前缀，老师端的都带/teacher前缀，角色判断就非常清晰，也不容易漏掉接口。

4.2 实习申报与审核的状态流转实现

整个系统里最核心的业务逻辑，就是学生提交实习申请，然后指导老师审核。这个模块状态多，逻辑嵌套深，写的时候尤其要清醒。

我处理这类状态流转，习惯在Service层先定义一个状态校验的方法，再把业务操作和状态变更放在同一个事务里。举个具体的例子，学生提交申请的代码大致思路是这样：

@Service public class ApplyServiceImpl implements ApplyService { @Override @Transactional(rollbackFor = Exception.class) public int submitApply(Integer studentId, Integer positionId) { // 1. 参数校验 if (studentId == null || positionId == null) { throw new ServiceException("参数缺失"); } // 2. 查最近一条申请记录 Apply lastApply = applyMapper.selectLatestByStudent(studentId); if (lastApply != null) { // 存在 0草稿、1待审核、2通过等状态都需要分别处理 if (lastApply.getStatus() == 1) { throw new ServiceException("存在待审核的申请，不能重复提交"); } if (lastApply.getStatus() == 2) { throw new ServiceException("您已有审核通过的实习申请"); } } // 3. 判断岗位是否还在招人 Position position = positionMapper.selectByPrimaryKey(positionId); if (position == null || position.getStatus() != 1) { throw new ServiceException("该岗位已下线"); } // 4. 插入一条新申请 Apply apply = new Apply(); apply.setStudentId(studentId); apply.setPositionId(positionId); apply.setStatus(1); // 待审核 apply.setCreateTime(new Date()); return applyMapper.insertSelective(apply); } }

这个模块我特别想强调一件事：每个状态变更都要想清楚“谁能做、什么时候能做、做了之后变成什么状态”，这三点想清楚，代码写起来就顺了。老师审核的操作同理，要判断这条申请是不是自己名下的学生，否则一个老师把另一个老师学生的申请给批了，这在真实业务里就是事故。这个判断我当时是加在SQL里的，where条件直接带上teacher_id，效果很好。

4.3 实习材料上传：周报和总结的落地做法

实习过程管理里，周报上传是避不开的功能点。SSM里做文件上传，用的是CommonsMultipartResolver，在spring-mvc.xml里注册一个bean即可。配置里有一个关键项是maxUploadSize，如果不设置或者设置太小，学生传一个带照片的Word文档就会报错，而且这个报错还比较隐蔽，容易让人误以为是代码逻辑问题。

上传的核心代码其实不复杂：

@Controller @RequestMapping("/student/weekly") public class WeeklyController { @RequestMapping(value = "/upload", method = RequestMethod.POST) public String upload(@RequestParam("file") MultipartFile file, HttpServletRequest request, HttpSession session) { if (file.isEmpty()) { return "redirect:/student/weekly/list?error=1"; } // 1. 获取文件原始名和后缀 String originalFilename = file.getOriginalFilename(); String suffix = originalFilename.substring(originalFilename.lastIndexOf(".")); // 2. 限制类型 List<String> allowed = Arrays.asList(".doc", ".docx", ".pdf", ".jpg", ".png"); if (!allowed.contains(suffix.toLowerCase())) { return "redirect:/student/weekly/list?error=2"; } // 3. 重新命名，防止重名和中文乱码 String newFileName = UUID.randomUUID().toString().replace("-", "") + suffix; // 4. 按 实习编号/周报目录 存储 String realPath = request.getServletContext().getRealPath("/uploads/weekly/"); File dir = new File(realPath); if (!dir.exists()) { dir.mkdirs(); } try { file.transferTo(new File(dir, newFileName)); } catch (IOException e) { e.printStackTrace(); return "redirect:/student/weekly/list?error=3"; } // 5. 文件路径存数据库 Weekly weekly = new Weekly(); weekly.setInternshipId(...); weekly.setFilePath("/uploads/weekly/" + newFileName); weeklyService.insert(weekly); return "redirect:/student/weekly/list?success=1"; } }

上传这里我有个深刻的教训：文件名一定要重命名。学生提交的文件名千奇百怪，有的是“新建文档.docx”，有的是带空格的，如果直接存到服务器上，Windows和Linux的表现还不一样，容易出乱码或者路径解析错误。用UUID重命名一劳永逸，原文件名可以单独存一个字段，下载的时候再还原显示。

4.4 学院实习率统计报表的思路

统计报表是另一个被老师高频问到的地方。最简单的报表就是“各学院实习完成率”，这个统计用一条SQL就能搞定。

SELECT s.college AS collegeName, COUNT(DISTINCT s.id) AS totalStudent, COUNT(DISTINCT CASE WHEN r.id IS NOT NULL AND r.status = 3 THEN s.id END) AS completedStudent FROM tb_student s LEFT JOIN tb_internship r ON s.id = r.student_id GROUP BY s.college ORDER BY totalStudent DESC

这里有一点需要注意，用LEFT JOIN而不是INNER JOIN，原因是为了把还没有实习记录的学生也统计进来，totalStudent才对得上。如果用了INNER JOIN，没实习的学生会被过滤掉，统计出来的总数就会变少，就是明显的逻辑错误。

统计出来的结果，我建议封装成一个VO对象，别直接返回Map。因为MyBatis返回Map的时候，字段名映射容易出问题，而且Controller层也不好取数据。VO的做法是每个统计项都有明确的属性字段，页面用EL表达式取值也方便。

5. 毕设高频Bug排查与答辩避坑记录

5.1 环境启动类问题：Tomcat部署和依赖冲突

做毕设的同学用的基本是IDEA加Tomcat。这里最容易出的问题，是Maven项目里的依赖没有打进部署包里，导致启动Tomcat后报ClassNotFoundException。排查方法很简单，看Artifacts的配置里有没有“lib”目录，或者看部署好的war包里WEB-INF/lib下有没有jar包。没有的话，在IDEA的Project Structure里把Jar包添加到对应Artifacts的lib目录下。

另一个高频坑是Spring版本和JDK版本不匹配。比如Spring 5.2最低要求JDK 8，如果你本地是JDK 6或者7，启动时直接报版本错误。这个一般在配置JDK的时候留意一下就行，但可以确认一点，如果本地JDK版本太新（比如JDK 17），部分老版本Spring可能不支持，建议统一用JDK 8，这是SSM项目最踏实的组合。

5.2 MyBatis映射和SQL层面的经典坑

MyBatis最常见的坑集中在三块：namespace写错、resultType和resultMap混用、#和$的区别没搞清楚。

namespace写错会导致启动时直接报“Invalid bound statement”这类错误。我的检查套路是：Mapper接口的全限定名必须和XML里的namespace完全一致，方法名要和XML里语句的id一致，返回类型要和接口方法签名一致。这三个一致是铁律，任何一个对不上，运行时就报错。

#和$的区别，我强烈建议用#{}传参，不要用${}拼接。因为#{}走的是预编译，既能防SQL注入，又不需要操心参数类型转换。${}唯一的合法使用场景是动态表名或者排序字段，比如ORDER BY ${sortColumn}，但这种场景也要提前做白名单校验，防止人为构造注入。

还有分页问题。PageHelper用的时候注意一点，它会在执行下一条SQL前自动拼上LIMIT，所以PageHelper.startPage()的位置必须在查询语句之前，而且不要在循环里调用。如果你在循环中分页查询，PageHelper会把循环内的每一条查询都加上LIMIT，结果就是完全失控。这个坑我见过太多次了。

5.3 前端JSP与后端交互的几个隐患

SSM项目的前端大多是JSP加JSTL。JSP页面踩坑大多在数据展示不出来。最常见的原因是EL表达式被禁用或者JSTL标签库没有引入。检查web.xml里有没有设置isELIgnored为false，检查JSP页面头部有没有引入JSTL的taglib指令。还有一个容易忽视的细节：如果数据在Controller和页面之间传递用的是Model而不是ModelAndView，页面里取值的key一定要和Controller里addAttribute的key完全一致，大小写字母都不能错。

另外，前端和后端的请求路径要时刻想着项目上下文路径的问题。很多新手直接在地址栏写“/login”，结果404，实际上是项目名没加上去。我在拦截器和跳转里统一用request.getContextPath()拼路径，就是为了避免这类问题。

5.4 答辩现场被问到的高频问题准备

答辩是你整个毕设的临门一脚，系统做得再好，讲不清楚也白搭。根据我带过的学生和评审老师的习惯，这题的重点问题基本绕不开下面这几类：

• SSM中Spring的作用是什么？答：管理对象，包括Service和Controller的创建、依赖注入、事务管理。
• SpringMVC的请求处理流程是什么？答：DispatcherServlet、HandlerMapping、Controller、ViewResolver、ModelAndView。
• MyBatis中实体类属性名和数据库字段名不一致怎么办？答：用resultMap做映射，或者开启驼峰自动映射。
• 为什么这个系统要设计四种角色？答：因为业务场景里数据权限天然不同，分离角色可以保证数据隔离。
• 如果学生重复提交申请怎么办？答：数据库加唯一索引，业务层也做状态校验，双重保障。

这几个问题，你在答辩前自己对着镜子说一遍，卡壳的地方就重点补。我当时就是忽视了状态字段的设计思路，结果被老师抓着问了好几分钟，好在那段时间我已经把整个状态流转逻辑理得很熟，才没出大问题。

6. 配套扩展方向和我的实操心得

6.1 让系统加分的扩展点：从毕设走向项目

如果核心功能都做完了，还想让系统看起来更丰满，有几个成本低、见效快的扩展方向可以考虑。

第一个是消息提醒。比如学生的申请审核通过后，给他发一条站内信或者系统通知。实现起来其实就是在审核操作里多写一条insert，但整个系统给人的感觉立马不一样，更像真实产品。

第二个是数据可视化。学院端的首页可以放几个图表，比如实习率环形图、岗位报名人数柱状图。用ECharts在前端画图，数据接口直接复用后端统计报表的接口，工作量不大，答辩演示时视觉效果好很多。

第三个是Excel导入导出。单位信息批量导入、学生名单导入、成绩导出，用Apache POI写工具类就能搞定。这个功能在企业里极其常见，写到简历上也是加分项。

6.2 时间安排、代码规范和论文素材的一并准备

给大家一个我踩过的节奏总结。做这种系统，真正写代码的时间其实两周左右就够了，但很多同学把时间大量耗在前期纠结和后期改bug上。我建议按下面这个节奏走：

第一周做需求分析和数据库设计，同时把SSM框架环境搭好。第二周做核心业务模块，优先完成登录、权限、申请审核这条主线。第三周做过程管理、成绩、统计，把界面调好看。最后一周专门做测试数据、异常处理、答辩PPT和论文里需要的截图。

代码规范这件事，不要在最后阶段才想起来。从一开始写就字字句句地注意命名规范、方法注释、统一返回结果。不然到了写论文的时候，你看着自己一个月前写的代码，会发现完全读不懂，到时候再回头改命名和结构，代价极大。

6.3 关于测试数据的准备

很多人做毕设系统，数据库里就放几条演示数据，页面打开空空荡荡，答辩演示时没法看。我强烈建议在系统交付前，手动造一批足量且真实感强的假数据。比如学生信息至少五十条，单位信息十条，每个单位两到三个岗位，随机分配一部分人走完整个流程。用SQL批量插入就行。

测试数据一定不能乱造。学生的专业、班级、指导老师、实习单位之间要能对得上逻辑，不然老师翻到某个学生的记录，发现指导老师和班级完全没有关系，就会意识到你的数据是随手编的。造数据的过程，本质上是对你系统的一次完整流程演练，也是提前发现bug的最好机会。

把这个题目做成你说的出口，靠的是一遍遍把细节走通

做完这个系统，我个人最大的体会就是：毕设题目在“烂大街”里其实藏着最扎实的训练价值。高校毕业实习管理系统这个题目，业务场景真实完整，SSM技术栈经典扎实，角色权限、状态流转、文件上传、统计报表这些全都碰得到，做完一遍之后你再去面试或者看别的Java项目，会有一种“万变不离其宗”的感觉。

最后分享一个小细节：接手这类题目之后，我第一次提交文件上传功能时，本地测试传了个几兆的Word文件，结果一直报连接被重置。排查了半天，发现是Tomcat的maxPostSize默认值太小，跟Spring的上传大小限制完全无关。这种底层的坑，只有真正做一遍才会记住。希望这篇长文能帮你少走点弯路，把自己这套毕业实习管理系统做得稳一点、完成度高一点。