企业官网建设流程全解析

做Java毕设选题的时候，很多人第一反应是"管理系统"，但普通的管理系统（比如图书馆管理、学生信息管理）导师看过太多，答辩时很难拿出亮点。如果你正在找一个既贴近真实业务场景、又能覆盖足够多JavaWeb核心技术点的题目，"大学生创新项目申报系统"这个方向是真的值得认真考虑的。这类系统本质上是把高校里"大学生创新创业训练计划项目"的申报、评审、立项、中期检查、结题验收全流程搬到线上，业务链路长、角色多、状态流转复杂，天然就比单表的增删改查有内容可写。而且这套流程几乎每所高校都有，需求完全真实，不是那种为了毕设硬造出来的虚假场景。

这篇东西就是围绕这个题目写的全套实操复盘，从为什么选这个题、功能权限怎么拆、数据库怎么设计，到SSM框架整合配置、核心流程代码实现、常见报错排查，再到答辩时导师常问的问题，都会聊到。不管你是正准备开题、还是已经写到一半卡住了，都可以直接当参考手册用。

1. 项目定位与整体思路拆解

1.1 这个选题为什么值得做

先说核心思路。大学生创新项目申报系统，表面看就是一个管理后台，但真正动手拆解之后你会发现，它的业务复杂程度远高于普通的CRUD系统。

高校里每年都会有创新创业训练计划项目申报，流程大概是：学校发通知→学生组队申报→指导老师审核→学院初审→专家评审→立项公示→项目执行（中期检查）→结题验收。这个过程涉及学生、指导老师、学院管理员、学校管理员、评审专家五类身份，每个身份看到的界面不同、能做的操作不同、关注的数据也不同。如果做成线下纸质流程，光是评审阶段收集专家意见、汇总打分就是一场灾难。

从毕设考核的角度看，这个题目能很自然地覆盖以下技术点：

• 用户登录认证与角色权限控制（拦截器、Session、RBAC）
• 多条件组合查询与分页展示（项目列表、待办事项）
• 文件上传与下载（申报书、中期报告、结题报告都是Word/PDF）
• 业务流程状态机流转（审核状态、评审状态、项目状态）
• 复杂SQL编写与多表联查（申报表、用户表、评审记录表、附件表）
• 数据统计与可视化（立项率、学院分布、申报趋势）

一套流程走下来，涉及的技术面足够广，又不会像"跨境电商平台"那种题目一样大到毕设周期根本做不完，是典型的"撑得起、收得住"的题目。

1.2 全流程管理到底在管什么

很多同学做管理系统有个通病：把每个功能模块做成孤立的增删改查页面，表和表之间没有业务关联，整体的流程感出不来。但创新项目申报系统不一样，它的核心价值恰恰在于"流程"二字。

举一个具体的场景。学生提交申报书之后，这个项目数据应该自动出现在指导老师的"待审核列表"里；指导老师审核通过后，数据流转到学院管理员的初审列表；学院初审通过，进入专家评审池，由管理员分配给若干专家打分；评审完成后系统自动汇总每位专家的评分和意见，按加权平均分排序，管理员参考排序结果生成拟立项名单；立项之后项目进入执行阶段，到了中期检查时间点需要学生提交中期报告，管理员做进度审核；最后是结题验收和成果归档。

这里的每一条流转，在数据库层面其实都是"状态字段+操作记录"的演进过程。我见过太多同学用一堆flag字段（is_submit、is_teacher_ok、is_college_ok）来表达流程，结果写到后面逻辑越来越乱，改一个节点的审核规则要连带改好几处代码。后面我会专门讲用状态机的方式设计流转，这是这个项目最值得沉淀的地方。

1.3 技术选型：怎么选才既稳又得分

关于框架选择，先给个明确结论：如果导师没有硬性要求Spring Boot，SSM（Spring+SpringMVC+MyBatis）反而是这个题目更"划算"的选择。

原因有三点。第一，很多学校JavaWeb课程教的就是SSM，课程设计也基于SSM，选它意味着你不需要花大量额外时间从零学Spring Boot的自动配置机制，学习成本更低。第二，SSM是配置文件驱动的框架，你自己手工配置过Spring容器、SpringMVC处理器mapper扫描、MyBatis的SqlSessionFactory，对框架原理的掌握会明显更深，答辩问到底层原理时回答更扎实。第三，从考核角度讲，Spring Boot自动封装了大量细节，如果导师让你讲"SpringMVC的工作流程""MyBatis分页原理"这类问题时，你在Boot场景下往往答不清楚，但用SSM你每一个配置都是手写的，思路会清晰得多。

三个框架的职责我用一个生活化的类比说清楚：Spring是整个应用的大管家，所有对象的创建、依赖关系的组装都由它管（就像公司的行政后勤）；SpringMVC负责接收请求和响应页面，用户的每个操作都先到它这里报到再分发给对应的处理人（就像公司的前台接待）；MyBatis负责跟数据库打交道，把Java对象映射成SQL语句、再把查询结果映射回Java对象（就像仓库管理员，只负责进出货和台账）。

2. 系统功能架构与权限模型设计

2.1 角色画像与功能边界

创新项目申报系统的角色划分，我建议最多做四类，太多会把自己累死，太少撑不起流程。

• 学生（申报者）：在线填写申报书、上传附件、查看审核进度、立项后提交中期报告和结题材料
• 指导教师：查看名下学生的申报项目，填写审核意见，通过/驳回
• 学院/校级管理员（可合并为一个角色）：发布项目申报通知、审核分配、分派评审专家、导入导出统计、进行立项和结题确认
• 评审专家：在评审任务列表中查看被分配的项目材料，填写评分和评审意见

角色必须做清晰的功能边界，不能让管理员去操作学生的申报，也不能让学生看到全局数据。这个边界不仅在界面上控制，更要在后端的拦截器里控制。

我把功能模块画成一张结构化的清单，做开发和写文档都能参照：

2.2 权限控制方案：拦截器+权限码的轻量RBAC

权限这块不用上Shiro或者Spring Security，毕设阶段用"登录拦截器+角色判断"就足够，重点是思路清晰、实现可靠。

我推荐的方案是：所有需要登录的请求路径统一走一个登录拦截器，控制器方法上用自定义注解或者直接通过Session里的角色字段做二次校验。具体一点，在HandlerInterceptor的preHandle里做三件事：检查Session里是否存在登录用户，不存在就重定向到登录页；存在就检查当前请求的URL前缀是否在当前角色的允许列表里；都不拦截的放行。

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); User loginUser = (User) session.getAttribute("loginUser"); if (loginUser == null) { // 未登录，跳转到登录页 response.sendRedirect(request.getContextPath() + "/login"); return false; } // 权限校验：根据请求路径前缀判断角色是否可访问 String uri = request.getRequestURI(); if (uri.startsWith("/admin/") && loginUser.getRoleId() != 1) { response.setContentType("text/html;charset=utf-8"); response.getWriter().write("<script>alert('无权限访问');history.back();</script>"); return false; } if (uri.startsWith("/expert/") && loginUser.getRoleId() != 3) { response.setContentType("text/html;charset=utf-8"); response.getWriter().write("<script>alert('无权限访问');history.back();</script>"); return false; } return true; } }

拦截器在spring-mvc.xml里注册，需要配置拦截路径和不拦截路径。登录页、静态资源、验证码接口这些都要放进excludeList，不然会出现重定向循环。

这里有个实操经验：界面菜单渲染也要按角色控制。否则拦截器拦了请求，但页面上左侧菜单把所有的入口都渲染出来了，学生点一下管理员的菜单，虽然会被拦截器拦下来，但观感很差，答辩老师可不会觉得这是"安全设计"，反而会问你怎么不做菜单控制。我的做法很简单，在JSP页面用c:if标签或者ModelAndView里传一个roleId标志，根据角色动态渲染菜单项。

2.3 数据库核心表设计

表设计是这类系统最关键的部分，直接决定后续代码怎么写。以我的实践经验，核心表至少要有这几张：

user表（用户表）

project表（项目申报表）

review_record表（评审记录表）

audit_log表（审核日志表，强烈建议加）

这里要重点说一下为什么需要audit_log表。流程类系统的核心需求是"可追溯"：某条申报数据当前到哪一步了、中间经历了哪些人的哪些操作、每个审核节点有没有意见记录，这些在真实业务里都要留痕。很多同学只用一个status字段记住当前状态，审核意见直接覆盖写，答辩老师一追问"你怎么追溯历史审核记录"就答不上来。加一张日志表，每个节点插入一条记录，不仅逻辑更严谨，列表页还能展示时间线式的流程历史，这本身就是一个很好的答辩亮点。

另外，文件不要用数据库BLOB字段存，而是把文件存到服务器磁盘，数据库里只存文件名、存储路径和上传时间。用BLOB存会导致数据库体积膨胀、备份变慢、查询性能下降，真实项目里绝对不会这么干。

3. 环境搭建与工程骨架配置

3.1 开发环境与其版本搭配

先给一份经过大量验证的环境清单，避免在版本上翻车。我当年因为JDK和Tomcat版本不匹配卡了一整天，纯属浪费时间。

3.2 Maven依赖配置

SSM项目的依赖版本搭配是个经典问题。网上很多教程里的依赖版本太老，和JDK 8以及新版本Spring不兼容，启动就成了大型事故现场。我这里给一份可以稳定运行的pom.xml核心依赖：

<properties> <spring.version>5.3.20</spring.version> <mybatis.version>3.5.10</mybatis.version> <mybatis-spring.version>2.0.7</mybatis-spring.version> </properties> <dependencies> <!-- Spring核心 --> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>${spring.version}</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-webmvc</artifactId> <version>${spring.version}</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-jdbc</artifactId> <version>${spring.version}</version> </dependency> <!-- MyBatis --> <dependency> <groupId>org.mybatis</groupId> <artifactId>mybatis</artifactId> <version>${mybatis.version}</version> </dependency> <dependency> <groupId>org.mybatis</groupId> <artifactId>mybatis-spring</artifactId> <version>${mybatis-spring.version}</version> </dependency> <!-- MySQL驱动 --> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>5.1.49</version> </dependency> <!-- 数据库连接池 --> <dependency> <groupId>com.alibaba</groupId> <artifactId>druid</artifactId> <version>1.2.8</version> </dependency> <!-- Servlet/JSP基础 --> <dependency> <groupId>javax.servlet</groupId> <artifactId>javax.servlet-api</artifactId> <version>3.1.0</version> <scope>provided</scope> </dependency> <dependency> <groupId>javax.servlet</groupId> <artifactId>jstl</artifactId> <version>1.2</version> </dependency> <!-- 文件上传 --> <dependency> <groupId>commons-fileupload</groupId> <artifactId>commons-fileupload</artifactId> <version>1.4</version> </dependency> <!-- JSON处理 --> <dependency> <groupId>com.fasterxml.jackson.core</groupId> <artifactId>jackson-databind</artifactId> <version>2.13.3</version> </dependency> <!-- 分页插件 --> <dependency> <groupId>com.github.pagehelper</groupId> <artifactId>pagehelper</artifactId> <version>5.3.0</version> </dependency> <!-- MD5加密 --> <dependency> <groupId>commons-codec</groupId> <artifactId>commons-codec</artifactId> <version>1.15</version> </dependency> </dependencies>

提醒一点：MySQL 8.0的驱动类名是com.mysql.cj.jdbc.Driver，连接串要加serverTimezone参数；MySQL 5.7用com.mysql.jdbc.Driver，不需要时区参数。如果你用的MySQL版本跟教程不一致，这地方是最容易报错的。

3.3 SSM三个配置文件怎么分工

SSM整合的难点在于三个配置文件的职责划分相当容易搞混。很多同学把数据库连接、组件扫描、拦截器、视图解析器全都塞到一个applicationContext.xml里，结果启动报一堆重复扫描错误，改来改去更乱。

我的习惯是分三个文件：

• applicationContext.xml：Spring主容器。配置数据源、SqlSessionFactory、Mapper接口扫描、Service层组件扫描（只扫service包）、事务管理器。

• spring-mvc.xml：SpringMVC子容器。配置Controller组件扫描（只扫controller包）、视图解析器、文件上传解析器、静态资源映射、拦截器注册。RequestMappingHandlerMapping这类MVC必须的组件在这一层。

• mybatis-config.xml：MyBatis自身配置。配置别名、下划线转驼峰（mapUnderscoreToCamelCase）、日志实现、以及PageHelper分页插件。

三个文件的关系用一句话讲：applicationContext是根容器，spring-mvc是子容器，子容器能用父容器的Bean，但父容器不能反过来用子容器的Bean。所以Service放在父容器、Controller放在子容器，分工清楚，循环依赖和扫描冲突都会少很多。

applicationContext.xml里的关键配置：

<context:property-placeholder location="classpath:db.properties"/> <bean id="dataSource" class="com.alibaba.druid.pool.DruidDataSource"> <property name="driverClassName" value="${jdbc.driver}"/> <property name="url" value="${jdbc.url}"/> <property name="username" value="${jdbc.username}"/> <property name="password" value="${jdbc.password}"/> </bean> <bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean"> <property name="dataSource" ref="dataSource"/> <property name="configLocation" value="classpath:mybatis-config.xml"/> <!-- mapper.xml文件位置 --> <property name="mapperLocations" value="classpath:mapper/*.xml"/> </bean> <bean class="org.mybatis.spring.mapper.MapperScannerConfigurer"> <property name="basePackage" value="com.xxx.dao"/> </bean> <context:component-scan base-package="com.xxx.service"/> <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <property name="dataSource" ref="dataSource"/> </bean> <tx:annotation-driven transaction-manager="transactionManager"/>

spring-mvc.xml里的关键配置：

<context:component-scan base-package="com.xxx.controller"/> <bean class="org.springframework.web.servlet.view.InternalResourceViewResolver"> <property name="prefix" value="/WEB-INF/views/"/> <property name="suffix" value=".jsp"/> </bean> <bean id="multipartResolver" class="org.springframework.web.multipart.commons.CommonsMultipartResolver"> <property name="maxUploadSize" value="52428800"/> <property name="defaultEncoding" value="UTF-8"/> </bean> <mvc:resources mapping="/static/**" location="/static/"/> <mvc:interceptors> <mvc:interceptor> <mvc:mapping path="/**"/> <mvc:exclude-mapping path="/login"/> <mvc:exclude-mapping path="/static/**"/> <mvc:exclude-mapping path="/captcha"/> <bean class="com.xxx.interceptor.LoginInterceptor"/> </mvc:interceptor> </mvc:interceptors>

配置层的坑很多，我后面第5节会专门从排查的角度再讲。现在先把工程骨架搭起来，项目写的时候才不心慌。

4. 核心业务流程与关键代码实现

4.1 申报模块：表单数据+附件上传的一次完整链路

创建申报书是最有代表性的一个功能，因为它把"表单数据绑定+文件上传+事务操作"揉在了一起。

前端表单提交的数据分成两部分：普通表单字段和MultipartFile文件。Controller里用@RequestParam("file") MultipartFile来接收文件，普通的字段直接绑定到Project对象。

@Controller @RequestMapping("/project") public class ProjectController { @Autowired private ProjectService projectService; @RequestMapping("/submit") @ResponseBody public Result submit(Project project, @RequestParam(value = "file", required = false) MultipartFile file) { if (file != null && !file.isEmpty()) { String originalName = file.getOriginalFilename(); // 提取扩展名 int index = originalName.lastIndexOf("."); String ext = index > -1 ? originalName.substring(index) : ""; // UUID重命名，防止文件名冲突 String newName = UUID.randomUUID().toString().replace("-", "") + ext; String uploadDir = RealPathUtil.getUploadDir(); File dest = new File(uploadDir, newName); try { file.transferTo(dest); project.setFilePath(newName); project.setFileName(originalName); } catch (IOException e) { return Result.error("文件上传失败：" + e.getMessage()); } } // 设置初始状态：待教师审核 project.setStatus(0); project.setStudentId(CurrentUserUtil.getUserId()); projectService.submit(project); return Result.success("申报已提交"); } }

这里有一个特别实用的建议：文件路径一定不要硬编码。我见过不少同学直接把保存路径写在代码里，今天在Windows上开发调试时用D:/upload，部署到Linux服务器就是一把心酸泪。正确做法是把上传根目录配置到properties文件里，或者用getRealPath相对路径。项目里我习惯自定义一个工具类，读取配置文件里的upload.dir，没有配置就给默认值，同时目录不存在时自动创建。

文件改名用UUID是我强烈推荐的做法。中文文件名保存到服务器上会遇到各种编码问题，而且如果两个学生传了同名文件（比如都叫"项目申报书.docx"），后上传的文件会覆盖先上传的。用UUID重命名后同时保留原始文件名到数据库，展示给用户时显示原始名，下载时再把原始名带回去，这套逻辑是最稳的。

4.2 状态机式的业务流转设计

这个项目能和普通CRUD拉开差距的核心就在于业务状态流转。我见过最糟糕的写法是：审核通过就在某张表里设置一个字段为1，驳回就设置另一个字段为0，等流程走到第四五个节点的时候，代码已经分不清"这个项目到底该谁审了"。

正确姿势是设计一个状态字段status，集中定义所有状态常量，并且把每个状态允许的"下一个状态"画出来，写在代码注释里。我的项目里定义状态如下：

• 0：草稿（学生保存未提交）
• 1：待指导教师审核（学生已提交）
• 2：待学院管理员初审（指导教师通过）
• 3：专家评审中（学院初审通过、管理员已分配专家）
• 4：拟立项（多数专家评分通过）
• 5：已立项（管理员最终确认）
• 6：中期检查中
• 7：已结题
• 8：已驳回（任何审核节点不通过）

每个状态流转的触发动作要集中放在Service层。核心代码如下：

public void auditProject(Integer projectId, Integer auditResult, String opinion, Integer userId) { Project project = projectMapper.selectByPrimaryKey(projectId); if (project == null) { throw new BusinessException("项目不存在"); } // 根据当前状态判断下一步 switch (project.getStatus()) { case 1: // 待指导教师审核 if (auditResult == 1) { project.setStatus(2); // 转入学院初审 } else { project.setStatus(8); // 驳回 } break; case 2: // 待学院管理员初审 if (auditResult == 1) { project.setStatus(3); // 进入专家评审 } else { project.setStatus(8); } break; default: throw new BusinessException("当前状态不可执行该操作"); } project.setAuditOpinion(opinion); projectMapper.updateByPrimaryKeySelective(project); // 写审核日志 AuditLog log = new AuditLog(); log.setProjectId(projectId); log.setUserId(userId); log.setAction("审核"); log.setOpinion(opinion); auditLogMapper.insert(log); }

把这个流程整理成表格，写进毕设文档里会非常加分：

这种设计的直接好处是：代码里不会出现各种散落的if字段判断，所有流转逻辑集中在audit方法里，出问题只需要看一个地方。而且后期想加一个"学院管理员驳回后学生修改重新提交"的流程，只要在状态图上加一条分支，改动是可控的。

4.3 评审模块：专家打分与结果汇总

评审是创新项目申报系统的第二个核心模块。需求规格是：管理员看到状态为"评审中"的项目，为每个项目选择2到3位专家进行评审；专家登录后看到分配给自己的评审任务，对项目进行打分并填写意见；评审结束后系统根据所有专家的评分计算平均分，决定是否进入拟立项名单。

专家分配的数据库设计用review_record表来处理。管理员每次给一个项目分配一个专家，就插入一条评审记录，评审专家未评审时review_status为0，提交后置为1，同时填上score和opinion。

等一个项目的所有评审记录都提交后，需要自动汇总评分。SQL可以写在Mapper里，用一个聚合查询：

<select id="calcAverageScore" resultType="java.util.Map"> SELECT project_id AS projectId, AVG(score) AS avgScore, COUNT(*) AS expertCount FROM review_record WHERE review_status = 1 GROUP BY project_id </select>

然后在Service里拿到平均分，跟设定的阈值（比如75分）比较，决定项目是否可以进入拟立项列表。注意，这里有个业务细节容易被忽略：一个项目分配了3个专家，如果只有1个专家提交了评分，直接算平均值失去意义，必须先判断已提交的专家数量是否达到分配数量。我一般用"评审记录总数"和"已提交数量"比较，全部提交了才汇总。

在评审页面上，专家看到的是项目基本信息、申报书附件的下载链接、评分输入框和意见文本框。这里有一个体验优化：因为每个专家正好只会收到分配给自己的评审任务，列表查询就直接用review_record表的expert_id过滤，相当于是"我的待办"。

4.4 立项名单与统计看板的联动

评审结束后，管理员在"立项管理"页面看到一份按平均分从高到低排列的通过名单，可以手动勾选哪些项目正式立项。这里我推荐一个实用做法：立项操作不是直接改project表的状态，而是先进入"拟立项"中间状态，等管理员确认后才改为"已立项"。这样可以避免评审一结束所有项目自动立项，给管理员留一个人工复核的空间，真实业务里也更合理。

统计看板是很多同学忽略但真的很加分的模块。系统的核心数据源就是project表：按学院分组可以统计各学院申报数量；按type字段可以统计创新类和创业类项目的比例；按status字段可以算出申报→立项的漏斗转化率。数据用ECharts的饼图和柱状图呈现，后端提供JSON接口，前端用Ajax拉数据渲染。

@RequestMapping("/statistics/college") @ResponseBody public List<Map<String, Object>> statByCollege() { return projectService.statByCollege(); }

SQL一侧就是最基础的GROUP BY：

<select id="statByCollege" resultType="java.util.Map"> SELECT college AS name, COUNT(*) AS value FROM project WHERE project.status &lt;&gt; 8 GROUP BY college </select>

统计看板的好处是它把系统的"管理者价值"显性化了。做毕设答辩的时候，你可以直接对着看板说："管理员第一眼就能看到今年有多少项目在申报、分布在哪些学院、立项率是多少"，比零散的管理列表有说服力得多。

5. 常见问题与排查技巧实录

5.1 启动阶段的连环报错

SSM项目第一次启动，几乎没有人能一次过。最常见的几个报错和排查思路我列一下。

第一个：Tomcat一启动，控制台报"Error creating bean with name 'projectController'"之类的异常。这个大概率是Controller依赖的Service或Mapper没有实例化成功。检查顺序永远是：先看Spring有没有扫描到Service（@Service注解加没加、组件扫描的basePackage写没写对）、再看SqlSessionFactoryBean有没有正确注入dataSource、最后看MapperScannerConfigurer的basePackage是不是Mapper接口所在包。

第二个：访问页面时候报"Invalid bound statement (not found)"。这个错误的意思是MyBatis在Mapper接口里找不到对应的SQL语句。排查三步走：Mapper接口的方法名和Mapper.xml里id是否完全一致；返回类型和parameterType有没有写对；mapper.xml有没有被Maven打包到target目录（经常因为xml放在src/main/java下而没被MyBatis扫描到）。后面这个问题需要检查pom.xml里resource插件配置。

第三个：接口访问全部404。先确认是不是拦截器把所有请求重定向到登录页了，在浏览器看Network面板里的响应状态码。如果是302跳转，就是拦截器路径配置的问题，把登录接口和静态资源加进exclude-mapping就能解决。

5.2 中文乱码与文件上传的坑

中文乱码在SSM项目里面是顽疾，实际上分三个地方解决，缺一不可：

Tomcat的server.xml里给Connector加上URIEncoding="UTF-8"，解决URL参数里的中文乱码；web.xml里配置Spring的CharacterEncodingFilter（forceEncoding设为true），解决请求体的编码；响应乱码则要确保JSP页面声明contentType="text/html;charset=UTF-8"，并且数据库连接串上加characterEncoding=utf8。

文件上传常见的坑是multipartResolver没配置，导致MultipartFile参数直接null，报"Required request part 'file' is not present"。这个问题的根源是SpringMVC的DispatcherServlet不知道用什么解析器处理multipart请求，你没有在spring-mvc.xml里定义CommonsMultipartResolver，它就把请求当普通POST处理。还有就是把CommonsMultipartResolver的id写错，Spring要求这个bean必须叫multipartResolver，写成别的名字一样不生效。

数据库保存文件路径的时候，还有一个隐性坑：如果用getRealPath返回的路径，在Tomcat里可能会带上一个带有时间戳的临时目录前缀，重新部署项目之后这个路径会变，导致旧文件找不到。所以存路径时一定要存相对路径，下载时再拼上绝对根路径。

5.3 答辩现场导师最爱问的几个问题

带着这个项目去答辩，导师大概率会从以下几个角度发问，我先替你把答案捋一遍。

第一个问题："你的权限是怎么控制的？"主答拦截器，说明preHandle里做了登录校验和角色校验，未登录跳登录页，无权限提示无权访问。如果导师追问"如果用户伪造请求怎么办"，可以补充说前端菜单是按角色渲染的，后端接口有二次校验，双重保障。

第二个问题："你的项目流程状态是怎么设计的？"把状态机那张表直接搬出来说，强调所有流转逻辑集中在Service层的一个方法里，通过状态常量控制，每个操作都写日志，可以追溯整个审核链路的完整历史。

第三个问题："MyBatis里#{}和${}有什么区别，你用哪个？"这是高频送分题。#{}是预编译占位符，会生成PreparedStatement参数，能防SQL注入；${}是字符串拼接，有注入风险。项目里查询条件全部用的#{}绑定参数。线上问题排查的帖子里经常见到反例，不设防的拼接就是漏洞。

第四个问题："这个系统有哪些地方可以进一步优化？"不要慌着说不知道，先点几个实在的方向：用Spring Boot替换SSM简化配置；给登录和接口加Redis缓存提升并发能力；用RabbitMQ做异步消息通知（比如项目审核通过后短信提示学生）；引入Spring Security做更细粒度的权限管理。这几个方向每个都答两三句，导师会觉得你对技术边界有清晰的认知。

6. 一些实操过程中的个人体会

做到这里，整套系统的骨架和核心链路已经完整了，剩下的就是按照这个底子把每个模块的细节填满。我前前后后带过不少用这个题目的学生，最大的感受是：进度的大敌不是代码难写，而是刚开始没想清楚业务流转就开始建表和写Mapper，后面每一步都在为前面的混乱买单。如果你正准备动手，花一到两天把状态流转、角色边界、表关系彻底想清楚再写代码，后面省的时间远不止这两天。

最后说一个实用的小技巧：项目开发到中期，可以顺手写一个data.sql初始化脚本，把几个测试账号、几个处于不同状态的项目数据提前塞进去。这不光是为了你自己联调方便，更是为了答辩现场演示不尴尬。我见过有人答辩时现场点击"提交申报"，结果界面转圈了十几秒最后报错，那种场面太伤了。预置好数据，点击之前把状态讲清楚，点完以后把流转效果指给老师看，这套演示流程才是加分的关键。

如果后面还有余力，这个系统可以从两个方向再扩展：一是把"专家评审"升级成匿名评审，抹掉学生和导师姓名再送审，业务上更严谨；二是加一个消息中心，审核结果、评审提醒通过站内信推送给学生。这两个扩展投入不大，但都会让你的毕设从"完成了"变成"有思考了"，值得试试。