企业官网建设流程全解析

简介：这份毕业设计资源面向计算机相关专业学生，实现基于SSM框架与MySQL数据库的知识产权管理系统，以JavaWeb技术结合JSP页面进行开发，具备前台展示和后台管理双重结构。前台支持用户注册登录、公告查看、知识产权检索、免费资料下载以及付费下载与租借，后台则区分管理员、员工、普通用户三类角色，覆盖员工管理、注册用户管理、公告信息维护、资料下载管理、知识产权申报审核、申报结果公布、失败反馈和付费下载期限设置等完整流程。压缩包内共1071个文件，以JSP页面、Java源代码、编译后的class文件、jar依赖包为主，附带SQL数据库脚本、XML配置、png/gif图片和mp4演示视频，资源包大小约56MB，目录结构按模块划分清晰。目前已有139人学习，内容包含完整源码、数据库文件和操作演示视频，便于直接部署运行、二次开发及毕业设计论文撰写，也可为理解SSM分层开发与知识产权业务逻辑提供有效参考。

1. 知识产权管理系统用 SSM 做，到底解决什么问题

如果毕设选题落在“知识产权管理系统”上，你基本选了一个业务边界清楚、功能模块多但不杂的方向：专利、商标、著作权三类客体的申请、审查、归档、年费和期限提醒，每一块都能对应到 SSM 里的一个层次去实现。SSM 指的是 Spring + SpringMVC + MyBatis 这套组合，它在高校毕设和企业内部老项目里仍有大量存量，顺着它走一遍，等于把 Java Web 的主干路径完整过了一遍。这个系统解决的具体问题是：把线下纸质申请流程搬到线上，让申请人能提交材料、审查员能分配和审核、管理员能维护分类与统计，三种角色共用一套权限体系。适合的人群很明确——正在选毕设题目、想用成熟技术栈完成从数据库设计到前后台联调的开发者，以及想快速接手 SSM 老项目的初级工程师。

2. 技术选型与数据建模：SSM 三层架构和知识产权核心表怎么设计

2.1 三层架构拆解：表现层、业务层、持久层各自管什么

SSM 里三个框架的分工经常被一句话带过，但真正落到代码上必须分清楚。SpringMVC 管表现层，负责接收 HTTP 请求、把参数绑定到对象、返回视图或 JSON；Spring 管业务层，负责对象创建、依赖注入、事务边界；MyBatis 管持久层，负责把 Java 对象映射成 SQL 参数、把查询结果集映射回对象。这条链路里最容易出问题的地方不在框架本身，而在三层之间的数据流：页面表单提交来的字段，经过 Controller 封装成 VO，再转成 Entity 传给 Service，最后被 Mapper 写进数据库。任何一个环节的字段名对不上，问题就会延迟到运行期才暴露。

我在做这类系统时习惯再加一个约定：Controller 里不写业务逻辑，只做参数校验和视图跳转；Service 里不写 SQL，只做状态判断和事务编排；Mapper 里不写 if else，只做数据读写。这样分层之后，答辩时被问到“为什么把某个判断放在 Service 而不是 Controller”，就能从职责边界和可测试性两个角度讲清楚。还有一点容易被忽略：事务注解加在 Service 实现类上，而不是接口上或 Controller 上，因为 Spring 的声明式事务默认基于 JDK 动态代理，代理对象拦截的是实现类的方法调用。

2.2 知识产权业务建模：核心数据表怎么设计

知识产权管理系统的表结构，我一般按“用户、申请、审查、费用、提醒”五个域来设计。用户表存储三类角色，用 role 字段区分 admin、reviewer、applicant；申请主表是业务核心，记录申请号、知识产权类型、名称、申请人、当前状态、提交时间；审查表保存每一次审核的意见和结果，因为一条申请会被多次审核；费用表记录年费缴纳历史；提醒表用于生成期限通知。这五张表的关系不复杂：用户对申请是一对多，申请对审查是一对多，申请对费用是一对多。

下面是一个可以直接参考的建表 SQL，主表字段按常见需求精简过，字符集统一用 utf8mb4，避免中文和生僻字写入报错：

CREATE TABLE ipr_application ( id INT PRIMARY KEY AUTO_INCREMENT, apply_no VARCHAR(32) NOT NULL UNIQUE COMMENT '申请号', apply_name VARCHAR(128) NOT NULL COMMENT '知识产权名称', type_id INT NOT NULL COMMENT '类型：1专利 2商标 3著作权', applicant_id INT NOT NULL COMMENT '申请人用户ID', status TINYINT NOT NULL DEFAULT 0 COMMENT '状态：0草稿 1已提交 2审查中 3已通过 4已驳回 5已归档', description TEXT COMMENT '技术说明或作品描述', create_time DATETIME NOT NULL, update_time DATETIME NOT NULL, INDEX idx_applicant (applicant_id), INDEX idx_status (status) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='知识产权申请表';

这里几个字段值得单独说明。apply_no 设置唯一约束是因为申请号在真实业务里是法律凭证编号，后端生成时要带上时间戳和随机位，避免并发重复。status 用 TINYINT 而不是 VARCHAR，是为了后续状态流转时用 int 比较，比字符串快，也方便在前端用 switch 映射成中文标签。applicant_id 和 status 分别建索引，是因为列表页最常见的查询组合就是“按申请人看我的申请”和“按状态筛选待办”。如果你想把筛选做得更顺，可以再加一个联合索引 (status, type_id)，覆盖“某类型下待审查的申请”这种高频查询。

2.3 让项目跑起来：环境版本选择与最小启动配置

拿到源码后第一个坎不是读代码，而是把环境对齐。我见过的毕设项目里，MySQL 5.7 和 8.0、JDK 1.8 和 11、Tomcat 8 和 9 混用的情况非常多。最稳妥的组合是：JDK 1.8 + Tomcat 8.5 + MySQL 5.7，因为绝大多数 SSM 毕设项目都是按这个组合写的。如果你本机只装了 MySQL 8.0，问题也不大，但要把驱动换成 mysql-connector-java 8.x，并在连接 URL 上加时区和公钥参数。

核心的数据库连接配置写在 jdbc.properties 里，常见问题集中在驱动类名和 URL 参数上：

jdbc.driver=com.mysql.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/ipr_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true jdbc.username=root jdbc.password=123456

逻辑说明：driver 用 com.mysql.jdbc.Driver 兼容 MySQL 5.7，如果你用 MySQL 8.0 就改成 com.mysql.cj.jdbc.Driver。URL 里 useUnicode 和 characterEncoding 控制客户端与服务器之间的字符集，serverTimezone 解决 8.x 时区报错，allowPublicKeyRetrieval 解决 caching_sha2_password 加密插件导致的连接失败。这些参数缺一个，启动时都会报出让人摸不着头脑的异常，属于常年踩坑的集中区。

Spring 整合 MyBatis 时，核心配置在 applicationContext.xml 里，重点是扫描 Mapper 接口和指定 XML 位置：

<bean class="org.mybatis.spring.mapper.MapperScannerConfigurer"> <property name="basePackage" value="com.example.mapper"/> </bean> <bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean"> <property name="dataSource" ref="dataSource"/> <property name="mapperLocations" value="classpath:mapper/*.xml"/> <property name="typeAliasesPackage" value="com.example.entity"/> </bean>

参数说明：basePackage 是 Mapper 接口所在的包，扫描到接口后会自动生成代理实现，不需要写实现类；mapperLocations 指向 XML 映射文件目录，如果你的 XML 放在 src/main/resources/mapper 下，这就是标准写法；typeAliasesPackage 让 XML 里写 resultType 时可以省略全限定类名。这里有个隐藏要求：Mapper 接口的包路径、XML 的 namespace、XML 文件放置位置三者必须一致，否则 Spring 容器启动时不会立刻报错，但首次调用方法时会抛 Invalid bound statement 异常。这个坑在下一章的避坑部分会详细展开。

3. 登录鉴权到审查流转：三个核心功能模块的实现路径

3.1 登录与权限控制：拦截器 + Session 的用户状态管理

知识产权管理系统里，登录后的第一件事是区分角色，因为申请人、审查员、管理员看到的菜单和能执行的操作完全不同。我一般用 SpringMVC 拦截器做登录校验，用 Session 存当前用户对象，再用一个简单的 role 判断控制菜单显示。这种方案虽然不算精细，但胜在直观、好讲、好改，毕设答辩时也容易解释。

先写拦截器，核心逻辑放在 preHandle 里：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object user = request.getSession().getAttribute("loginUser"); if (user == null) { response.sendRedirect(request.getContextPath() + "/login"); return false; } return true; } }

逻辑说明：每次请求进入 Controller 之前，先检查 Session 里有没有 loginUser。没有就重定向到登录页，有就放行。这里用 getContextPath() 拼接重定向路径，是为了兼容项目部署在 Tomcat 下带 context path 的情况，直接写 "/login" 在部署后容易 404。

接着在 SpringMVC 配置里注册拦截器，并排除登录相关的请求和静态资源：

<mvc:interceptors> <mvc:interceptor> <mvc:mapping path="/**"/> <mvc:exclude-mapping path="/login"/> <mvc:exclude-mapping path="/logout"/> <mvc:exclude-mapping path="/static/**"/> <bean class="com.example.interceptor.LoginInterceptor"/> </mvc:interceptor> </mvc:interceptors>

参数说明：mapping 用/**拦截所有路径；exclude-mapping 逐个排除不需要登录就能访问的路径。static 目录必须排除，否则 CSS、JS、图片全被拦下来，页面打开就是裸 HTML。如果你用了 Bootstrap 或 Layui 这类前端资源，记得确认它们的路径前缀和 exclude 的一致，比如资源放在 /static/layui 下，那排除 /static/** 就够了。

角色权限方面，我建议在页面层用 JSP 的 c:if 判断 role 再渲染不同按钮，例如申请人看到“提交申请”，审查员看到“开始审查”。后端接口层面再根据 Session 里的角色做操作校验，防止有人绕过页面直接调 URL。两重校验都不复杂，但能撑起“权限控制”这个答辩考点。

3.2 申请登记全链路：页面表单到数据库的完整链路

知识产权申请登记是系统的核心业务入口，链路很长：页面收集表单数据、文件上传、组装申请号、写入主表、保存附件记录。最容易写乱的是表单数据和附件数据的关联，我习惯在 Service 层用事务把两步绑在一起。

Controller 层代码只负责接参数和调 Service：

@Controller @RequestMapping("/apply") public class ApplyController { @Autowired private ApplicationService applicationService; @PostMapping("/submit") public String submit(ApplicationVO vo, @RequestParam("file") MultipartFile file, HttpSession session) throws Exception { User user = (User) session.getAttribute("loginUser"); applicationService.submitApplication(vo, file, user.getId()); return "redirect:/apply/list"; } }

逻辑说明：页面表单里的字段直接绑定到 ApplicationVO，上传文件单独用 MultipartFile 接收，当前用户从 Session 拿而不是让页面传 userId，避免越权。返回的 redirect 是 Post/Redirect/Get 模式，防止表单重复提交。

Service 层实现里，我重点做三件事：生成申请号、保存申请记录、保存附件。事务加在方法上：

@Service public class ApplicationServiceImpl implements ApplicationService { @Autowired private ApplicationMapper applicationMapper; @Autowired private AttachmentMapper attachmentMapper; @Override @Transactional(rollbackFor = Exception.class) public void submitApplication(ApplicationVO vo, MultipartFile file, Integer userId) throws Exception { Application app = new Application(); app.setApplyNo(generateApplyNo()); app.setApplyName(vo.getApplyName()); app.setTypeId(vo.getTypeId()); app.setApplicantId(userId); app.setStatus(1); app.setDescription(vo.getDescription()); app.setCreateTime(new Date()); app.setUpdateTime(new Date()); applicationMapper.insert(app); if (file != null && !file.isEmpty()) { String filePath = saveFileToLocal(file); Attachment att = new Attachment(); att.setApplyId(app.getId()); att.setFilePath(filePath); att.setUploadTime(new Date()); attachmentMapper.insert(att); } } }

参数说明：@Transactional(rollbackFor = Exception.class) 表示只要方法抛出任何异常就回滚，这里不能只写 @Transactional，因为 Spring 默认只对 RuntimeException 回滚，而文件保存、IO 操作抛的通常是 Exception，不加 rollbackFor 会导致申请记录写进去了、附件保存失败却不回滚，数据就脏了。generateApplyNo 是私有方法，推荐格式是“类型前缀 + 年月日 + 四位随机数”，例如 PAT202506010012。saveFileToLocal 负责把 MultipartFile 写入服务器指定目录，路径用绝对路径拼 UUID 文件名，避免文件名冲突和中文乱码。

3.3 审查流程的状态流转：用字段驱动而不是写死流程

知识产权申请的审查流程有明确的阶段推进：草稿、已提交、审查中、已通过、已驳回、已归档。如果把这个流转逻辑写满 if else，后面加一个状态就头疼。更常见也更适合毕设的做法是：在 Service 里定义一个状态流转方法，谁能操作、能流转到什么状态，都用数据判断。

审查员操作的代码大致是这样：

public void reviewApplication(Integer applyId, Integer reviewerId, Integer targetStatus, String reviewComment) { Application app = applicationMapper.selectById(applyId); if (app == null) { throw new BusinessException("申请不存在"); } if (app.getStatus() != 2) { throw new BusinessException("当前状态不可审查"); } Review review = new Review(); review.setApplyId(applyId); review.setReviewerId(reviewerId); review.setComment(reviewComment); review.setReviewTime(new Date()); review.setTargetStatus(targetStatus); reviewMapper.insert(review); Application update = new Application(); update.setId(applyId); update.setStatus(targetStatus); update.setUpdateTime(new Date()); applicationMapper.updateStatus(update); }

逻辑说明：先查申请，校验当前状态是否在“审查中”，防止跳过流程直接改到归档；然后插入一条审查意见记录，最后更新主表状态。这里的关键点是审查意见单独存表而不是覆盖式更新主表字段，因为一条申请会被驳回后重新提交，再进入审查，每一次意见都要留痕。targetStatus 在调用时由 Controller 层根据“通过”或“驳回”按钮传进来，实际上只有 3（通过）和 4（驳回）两种合法值，如果有闲心，可以在 Service 里再加一个合法流转表校验，但毕设做到这一步已经够讲出状态机的味道了。

从页面角度看，审查员的待办列表就是查 status = 2 的申请列表，这个查询直接走 MyBatis 的动态 SQL 就能覆盖多条件筛选，下一章展开讲。

4. MyBatis 与 MySQL 落地细节：动态 SQL、分页和事务的参数设置

4.1 多条件检索：动态 SQL 的 where 与 if 组合

知识产权管理系统里的列表页通常带一组筛选条件：按申请号模糊查、按类型下拉查、按状态下拉查。如果为每个条件组合写一条 SQL，那将是排列组合灾难。MyBatis 的动态 SQL 就是为这个场景设计的，核心是<where>配合<if>自动拼 SQL，还能智能去掉多余的 AND。

一个完整的查询映射如下：

<select id="searchApplications" resultType="com.example.entity.Application"> SELECT id, apply_no, apply_name, type_id, status, create_time FROM ipr_application <where> <if test="keyword != null and keyword != ''"> AND (apply_no LIKE CONCAT('%', #{keyword}, '%') OR apply_name LIKE CONCAT('%', #{keyword}, '%')) </if> <if test="typeId != null"> AND type_id = #{typeId} </if> <if test="status != null"> AND status = #{status} </if> <if test="applicantId != null"> AND applicant_id = #{applicantId} </if> </where> ORDER BY create_time DESC </select>

参数说明：keyword 是前端搜索框传来的关键词，用 CONCAT 拼百分号而不是在 Java 层拼好传进来，是因为 MyBatis 的 #{} 自带预编译防注入，拼接后在 SQL 里容易变成字符串拼接，安全性打折。typeId 和 status 用!= null判断，意味着传 0 也会参与过滤，这正好符合状态从 0 开始的表设计。applicantId 是给“只看我的申请”准备的，申请人登录后列表页必须带这个条件，否则他就看到全公司所有人的申请了。这个 SQL 的 resultType 用了驼峰属性自动映射，前提是在 MyBatis 配置里开启了 mapUnderscoreToCamelCase，否则 apply_no 映射不到 applyNo，返回对象里全为 null。

4.2 分页查询：PageHelper 的参数设置与两个常见误区

列表页数据量一大就要分页。SSM 项目里最省事的方式是 PageHelper，一个静态方法调用就能在 SQL 执行前自动拼接 LIMIT。常见用法是：

public PageInfo<Application> getApplyPage(ApplicationQuery query, int pageNum, int pageSize) { PageHelper.startPage(pageNum, pageSize); List<Application> list = applicationMapper.searchApplications(query); return new PageInfo<>(list); }

逻辑说明：PageHelper.startPage 必须在 Mapper 方法调用之前执行，它通过 MyBatis 拦截器拦截下一条查询语句并自动追加 LIMIT。new PageInfo<>(list) 会计算出总条数、总页数、当前页等分页元数据，前端拿到这些字段渲染页码。

这里有两个经常踩的坑。第一个是 startPage 之后执行了两条查询，第二查询也会被分页，导致第二查询数据被截断或报错；解决方法是确保 startPage 后紧跟目标查询，中间不要插入其他数据库操作。第二个是 pageNum 传 0 或负数，PageHelper 默认会有边界处理，但如果你自己写了pageNum = (pageNum - 1) * pageSize这类逻辑，就反而把插件的行为搞坏了。正确做法是只传当前页和每页条数，偏移量由插件计算。还有一个容易被忽视的细节：排序字段不要由用户输入直接拼进 ORDER BY，否则存在拼接注入的风险，白名单校验后再拼是底线操作。

4.3 事务控制：声明式事务的三个必查点

提交申请时同时写主表和附件表、审查时同时写审查表和更新主表，这两个场景都必须有事务。SSM 里的标准做法是用 Spring 的声明式事务，在 applicationContext.xml 里配置事务管理器和切面：

<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <property name="dataSource" ref="dataSource"/> </bean> <tx:advice id="txAdvice" transaction-manager="transactionManager"> <tx:attributes> <tx:method name="submit*" propagation="REQUIRED"/> <tx:method name="review*" propagation="REQUIRED"/> <tx:method name="update*" propagation="REQUIRED"/> <tx:method name="*" read-only="true"/> </tx:attributes> </tx:advice> <aop:config> <aop:pointcut id="servicePointcut" expression="execution(* com.example.service.*.*(..))"/> <aop:advisor advice-ref="txAdvice" pointcut-ref="servicePointcut"/> </aop:config>

参数说明：tx:method 的 name 按方法名前缀匹配，所有以 submit、review、update 开头的方法走 REQUIRED 事务，其余方法只读。read-only 对查询方法能减少不必要的锁开销，但注意它只对 JDBC 连接设置只读提示，不是强约束。切点表达式 execution 的写法表示拦截 Service 包下所有类的所有方法，如果你的 Service 实现在 impl 子包里，要把包路径写全，例如 com.example.service.impl..(..)。

使用声明式事务时有三个必查点。第一，事务管理器必须使用和 SqlSessionFactory 同一个数据源，否则事务不生效且难以察觉。第二，方法必须是 public 的，Spring 的代理无法拦截 private 和 protected 方法。第三，同类内部方法调用不会走代理，比如 A 类的 submit 方法里直接调了 A 类里的另一个事务方法，第二个方法的事务注解不生效，这种情况要把被调方法拆到另一个 Service 里，或者用编程式事务兜底。我通常会在写完一个涉及多表写操作的功能后，故意在中间抛一个异常验证回滚是否生效，这比事后排查高效得多。

5. 从导入到答辩的避坑指南：5 个真实翻车现场与排查路径

5.1 翻车现场 1：Tomcat 启动就报 ClassNotFoundException

现象：项目导入 IDE 后运行，Tomcat 启动日志里连续抛出 ClassNotFoundException，指向 Spring 或 MyBatis 的核心类。原因：IDE 没有把 Maven 依赖的 jar 包部署到 WEB-INF/lib 目录，编译能通过但运行环境缺包。解决：检查项目部署配置，在 IDE 里找到 Deployment Assembly 或 equivalent 配置，把 Maven Dependencies 添加到运行环境。如果项目是用 Maven 构建，直接执行mvn clean package生成 war 包，再把 war 丢到 Tomcat 的 webapps 下启动，通常能绕过 IDE 的部署问题。这个坑在第一次启动 SSM 项目时出现概率非常高，优先检查部署配置而不是重新下载依赖。

5.2 翻车现场 2：数据库连接失败，一直 Communications link failure

现象：启动时报 Communications link failure，有时中间还穿插 SSL 连接告警。原因分两种：MySQL 8.0 的驱动类名配套问题，以及连接 URL 缺少时区参数。解决：确认 MySQL 版本和驱动版本配套，MySQL 5.7 用老驱动没问题，MySQL 8.0 必须换 mysql-connector-java 8.x，同时在 URL 里加 serverTimezone=Asia/Shanghai、useSSL=false、allowPublicKeyRetrieval=true。这三个参数缺一个，MySQL 8 环境下基本连不上。注意，MySQL 8 默认的 caching_sha2_password 插件对老驱动不友好，allowPublicKeyRetrieval=true 是为了允许客户端从服务器获取公钥完成认证，安全评测里会提示这是明文公钥传输，毕设环境可以接受，生产环境更推荐改用 sha256_password 插件和 SSL。

5.3 翻车现场 3：Mapper 接口注入失败，页面直接 500

现象：项目能启动，但访问列表页时抛出 Invalid bound statement (not found)，或者报 NullPointerException 指出 Mapper 为 null。原因：Mapper 接口的包路径与 XML 映射文件的 namespace 不一致，或者 XML 文件没被编译到 target/classes 里。解决：先看 target/classes 目录下有没有对应的 mapper XML，没有就是资源配置问题，在 pom.xml 里加资源过滤：

<build> <resources> <resource> <directory>src/main/resources</directory> <includes> <include>**/*.xml</include> <include>**/*.properties</include> </includes> </resource> </resources> </build>

然后核对 XML 里 namespace 是否等于 Mapper 接口的全限定名，每个<select>的 id 是否等于接口方法名。还有一种隐性情况：接口方法有重载，MyBatis 不支持重载 Mapper 方法，写两个同名方法必报错。排查顺序建议先看 XML 是否打进去了，再看 namespace，最后看方法名和参数类型，90% 的案例集中在这三处。

5.4 翻车现场 4：表单中文乱码，数据库里全是问号

现象：页面提交中文名称后，列表显示乱码或问号。原因通常是三层问题叠加：JSP 页面编码、SpringMVC 请求编码过滤器、MySQL 连接字符集。解决：三层逐一确认。JSP 页面头部加<%@ page contentType="text/html;charset=UTF-8" %>；web.xml 里加 Spring 提供的 CharacterEncodingFilter；jdbc.properties 的 URL 里确保有 characterEncoding=utf8，建表时统一用 utf8mb4 字符集。如果只改一处，问题必然复现。

<filter> <filter-name>encodingFilter</filter-name> <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class> <init-param> <param-name>encoding</param-name> <param-value>UTF-8</param-value> </init-param> <init-param> <param-name>forceEncoding</param-name> <param-value>true</param-value> </init-param> </filter> <filter-mapping> <filter-name>encodingFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>

重点说明 forceEncoding=true 的作用：它同时处理请求和响应编码，不设置时可能只对请求生效。这个过滤器要放在所有过滤器的最前面，否则它设置的编码会被后续逻辑覆盖。数据库已经是乱码的数据，不要想着靠改配置自动恢复，直接用 SQL 清掉重新录入，排查问题比修复脏数据省时间。

5.5 翻车现场 5：本地能跑，导出 War 包部署后页面样式丢失

现象：本地 IDE 运行一切正常，把项目导出成 war 包放进另一个 Tomcat 后，页面能打开但 CSS、JS 全部加载失败。原因：静态资源引用了绝对路径或缺少 context path。比如 JSP 里写/static/css/style.css，本地部署时 context path 为空所以能访问，放到/ipr-system/上下文后路径就变成了根路径下的 /static，自然 404。解决：JSP 里统一用${pageContext.request.contextPath}拼接静态资源路径，或者用<c:url>标签。这是一个非常典型的部署级翻车，答辩演示前如果换了机器，十有八九会碰到。顺带检查一下 Servlet 版本和 web.xml 头文件的版本是否一致，Tomcat 9 对 web.xml 4.0 支持有限的问题也遇到过。

6. 答辩前最该补强的两个细节：演示视频录制与初始化数据脚本

演示视频是这套资源的组成部分，但很多同学拿到后直接用，录得卡顿、鼠标乱飘、看不清字段。我建议拿到视频后先自己看一遍，如果效果差，按功能模块重录一遍，控制在 8 分钟以内。录制顺序按照业务流程走：登录页面展示三种角色账号切换、申请人提交一份专利和一份商标申请、审查员登录看到待办并审核通过、管理员查看统计列表和费用记录。每个模块停留时间不超过 20 秒，鼠标操作要有明确停顿，不要快速划过表单字段。视频里最重要的一步是把数据库里的数据变化同步展示出来——比如提交申请后打开 Navicat 刷新申请表，让评委看到刚才的页面操作真实写进了库，这一招比任何讲解都有说服力。

初始化数据脚本同样值得重做。很多项目的数据库脚本只给了表结构，业务数据全靠手动录入，评委打开系统看到空列表，体验很差。我会在 SQL 脚本里塞一组演示数据：三个角色各一个账号、每个类型至少两条申请，且状态覆盖草稿、审查中、已通过、已驳回四种，费用表里要有已缴纳和即将到期各一条。这样登录后每个页面都有内容可看，演示时不需要临时现造数据。数据库脚本文件的注释要说明每个账号的角色和用途，方便自己切换演示。

最后说一个我的血泪经验：演示前一定把数据库脚本重新跑一遍，用全新的数据状态，不要拿开发环境里试验过几轮的数据。数据太乱会让评审觉得系统逻辑不清晰，数据太少又显得没做完。初始化脚本是你给评委的第一印象，花一小时把数据编得干净规整，比临时在页面上操作填数据从容得多。答辩问到自己没做过的功能时也别慌，顺着表结构和状态流把设计思路讲出来，本身就是一种能力展示。希望这些细节能帮你在答辩时少一点紧张，多一点底气。

本文还有配套的精品资源，点击获取