企业官网建设流程全解析

1. 项目定位与核心需求拆解

1.1 这个毕设项目到底解决什么问题

每年临近毕业季，我总会遇到同学来问同一个问题：“学长，Java毕设做什么选题好？有没有那种工作量适中、原理清楚、答辩好讲的项目？”我通常会直接推荐——基于JSP和JAVA的大学生兼职雇佣系统。为什么？因为这个选题踩中了当下大学生群体的普遍痛点：找兼职的渠道不透明、信息真实性没保障、雇主和兼职学生之间缺少一个规范化的对接平台。

展开说，大学生想找一份家教、校内助理、发传单这类零工，通常靠QQ群、朋友圈、贴吧，信息零散且真假难辨；雇主想招兼职的学生，也缺少一个能筛选学生简历、确认身份、跟踪报名状态的工具。这个系统的价值就在于把“兼职信息发布、学生检索报名、雇主确认录用、个人中心管理”整条链路搬到Web平台上，三个角色各取所需，逻辑闭环完整。对毕设来说，既有真实的社会应用场景，又有足够的技术展示面——JSP页面、Servlet控制器、JavaBean业务封装、MySQL数据库、会话管理、分页查询、正则校验，核心技术点几乎全部覆盖，评审老师想问的东西一个不落。

这个项目适合三类人：一是计算机专业做毕设的学生，尤其是Java方向的；二是想快速上手Servlet/JSP传统Web开发、搞清楚MVC思想的初学者；三是准备在简历上写一个“完整业务系统”项目的求职者。它不是花哨的微服务架构，而是扎实的传统Java Web项目，学东西、过答辩、写简历都够用。

1.2 三种用户角色与功能边界划分

做系统设计的第一步，永远不是写代码，而是搞清楚谁在用、用哪些功能、权限边界在哪。这个系统我划分为三个角色，对应三种权限域。

学生（求职者）：注册登录、完善个人信息、浏览全部兼职信息、按关键词或类别检索、投递简历报名、收藏有意向的兼职、查看自己已投递的记录和录用状态、编辑个人资料和头像。

雇主（招聘方）：注册登录、发布兼职信息（岗位名、招聘人数、时薪/月薪、工作地点、工作日期、岗位要求）、管理自己发布的兼职列表、查看某一职位下收到的学生简历、确认录用或拒绝学生。

管理员（平台方）：登录后台、审核雇主发布的兼职信息是否合规（防止黑中介、虚假信息）、管理全部注册用户（禁用/启用账号）、查看系统运行数据、发布平台公告。

权限拆分的关键细节在于：学生和雇主虽然是同一个用户表，但必须通过role字段区分，所有Servlet在入口处做角色鉴权，否则会出现学生能访问雇主后台的低级漏洞。这个细节在毕业设计评审中经常被问到，做好了反而是加分项。

功能边界想清楚了，数据库设计和后端控制器的划分就顺理成章。千万不要跳过这一步直接建库建表，我见过太多同学表建到一半发现字段不够用，回头改数据库，连带Servlet、JSP全部跟着改，那叫一个痛苦。

2. 技术选型与系统架构设计

2.1 为什么坚持JSP + Servlet + JavaBean，而不是Spring Boot

这个问题我几乎在每次答辩模拟中都会被问到：“现在企业都用Spring Boot，你为什么不选它？”标准的回答逻辑是：毕业设计的核心目标是验证你是否掌握了Java Web开发的基本原理，而不是考察你是否会拼接注解。

JSP + Servlet + JavaBean是Java Web最底层的执行模型。JSP负责视图呈现，Servlet负责请求调度和控制逻辑，JavaBean封装数据和业务方法，三者各司其职，恰好就是MVC模式的经典映射。用这套技术栈做毕设，你能亲手写出来一个HTTP请求是怎么从浏览器出发、经过Servlet处理、调用DAO层访问数据库、再通过JSP把数据渲染回页面的完整过程。这是Spring Boot屏蔽掉的那部分知识，而这部分恰恰是答辩时最能证明你“动了脑子”的内容。

从工作量角度说，Spring Boot项目依赖大量注解配置和第三方库，导包、版本冲突、自动配置的坑一个接一个。对很多基础一般的学生来说，这套东西还没开始写业务代码就被环境问题打垮了。而传统JSP项目只要JDK + Tomcat + MySQL手搭好，引入一个mysql-connector-java.jar，项目就能滚起来了，每一步都看得见摸得着。

2.2 标准分层架构与项目目录结构

项目严格遵循三层架构：表现层（JSP）、业务逻辑层（Servlet + Service）、数据访问层（DAO）。我在实际代码里把包结构设计成下面这样，你可以直接拿去建包：

com.partjob.entity // 实体类：User、PtJob、Application、Collect com.partjob.dao // 数据访问层：UserDao、PtJobDao、ApplicationDao com.partjob.service // 业务层：UserService、PtJobService、ApplicationService com.partjob.servlet // 控制器层：LoginServlet、RegisterServlet、JobListServlet... com.partjob.util // 工具类：DBUtil、StringUtil、Md5Util

WebContent目录下面建views存放所有JSP页面，再按角色分子目录：views/student、views/employer、views/admin、views/common。样式文件用BootStrap（直接用CDN或者下载本地都行），三套角色页面各复用一套布局，样式不用重头写。

分层带来的最大好处是改动隔离。比如数据库换了一台机器，只需要改DBUtil里的连接参数；比如分页逻辑想要调页大小，只需要改DAO层的SQL加一条LIMIT，完全不影响Servlet和JSP的代码。我在做这个项目时曾经一次性把数据库引擎从MyISAM改成InnoDB，DAO以外的地方连动都没动，这就是好架构体的直接回报。

2.3 开发工具与运行环境清单

工欲善其事，必先利其器。下面这份环境清单是经过实测的，混搭出的坑最少：

JDK和Tomcat是这套项目里最核心的运行组合，两个都要配环境变量。JDK需要配置JAVA_HOME指向安装目录、PATH追加%JAVA_HOME%\bin，Tomcat不需要配系统变量，直接在Eclipse里关联本地安装路径就行。这一步在常见问题里还会展开说。

3. 数据库设计与核心表结构

3.1 五张核心表的字段设计思路

数据库设计是毕设项目中最能体现“业务理解”的环节。整套系统我最终落成五张表：用户表t_user、兼职信息表t_job、报名/投递表t_application、收藏表t_collect、公告表t_notice。下面挑业务字段多的两张详细说。

用户表t_user的核心字段：id（主键自增）、username（登录名）、password（MD5后密文）、role（1学生/2雇主/3管理员）、real_name（真实姓名）、phone（联系方式）、email（邮箱）、intro（个人简介）、school（学校，学生专用）、avatar（头像路径）、status（0正常/1禁用）、create_time（注册时间）。

兼职信息表t_job的核心字段：id、employer_id（外键关联用户表的雇主ID）、title（兼职标题）、category（类别，如家教/服务员/普工）、pay_type（薪资类型，时薪/日薪/月薪）、pay_amount（薪资数值）、location（工作地点）、start_date（开始日期）、end_date（结束日期）、headcount（招聘人数）、description（岗位描述）、status（0待审核/1已发布/2已下架）、create_time。

在设计t_job表时，把employer_id单独拆成外键关联，而不是把雇主姓名直接存进表里。这样做的目的是后续如果要在职位卡片上展示招人单位的名字，只需要通过JOIN t_user拿一次，信息永远是最新的。如果直接冗余一个employer_name字段进去，一旦用户改了个性签名，职位列表就显示旧名字了，逻辑上说不通。

3.2 表关系与外键约束——为什么不能偷懒不建外键

t_application表承担学生和兼职之间的关联关系，字段包括：id、student_id（学生ID）、job_id（岗位ID）、resume_text（简单自我介绍）、status（0待处理/1已录用/2未录用）、apply_time。一张表就能回答两个问题：一个学生投了什么岗位、一个岗位收到了哪些学生。

这三张表之间的外键关系是：t_job.employer_id指向t_user.id，t_application.student_id指向t_user.id，同时t_application.job_id指向t_job.id。很多做毕设的同学因为偷懒不建物理外键，结果出现“报了岗位、但该岗位已被删除”的脏数据。我建议在数据库里显式加上FOREIGN KEY约束，好处是数据安全性更有保障——比如删除一份职位时，如果还有学生报名记录在引用它，数据库会自动拦截，避免产生孤儿数据。

外键还会倒逼你关注表之间的引用完整性。比如学生用户被管理员禁用时，并不会影响他已经发出的报名记录，因为这两者之间没有直接的外键。合理的设计，既要有关联，又要避免过度耦合。

3.3 建库建表SQL脚本的完整参考

我用的字符集是utf8mb4，它为的就是万能兼容中文和特殊符号，排序规则选utf8mb4_general_ci就够用。数据库名我用db_partjob，下面是精简后的可运行版本：

CREATE DATABASE IF NOT EXISTS db_partjob DEFAULT CHARACTER SET utf8mb4; USE db_partjob; CREATE TABLE t_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(64) NOT NULL, role TINYINT NOT NULL DEFAULT 1, real_name VARCHAR(50) DEFAULT NULL, phone VARCHAR(20) DEFAULT NULL, email VARCHAR(100) DEFAULT NULL, intro VARCHAR(500) DEFAULT NULL, school VARCHAR(100) DEFAULT NULL, avatar VARCHAR(200) DEFAULT NULL, status TINYINT DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE t_job ( id INT PRIMARY KEY AUTO_INCREMENT, employer_id INT NOT NULL, title VARCHAR(100) NOT NULL, category VARCHAR(50) DEFAULT NULL, pay_type VARCHAR(20) DEFAULT NULL, pay_amount DECIMAL(10, 2) DEFAULT NULL, location VARCHAR(200) DEFAULT NULL, start_date DATE DEFAULT NULL, end_date DATE DEFAULT NULL, headcount INT DEFAULT 1, description TEXT, status TINYINT DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (employer_id) REFERENCES t_user(id) ); CREATE TABLE t_application ( id INT PRIMARY KEY AUTO_INCREMENT, student_id INT NOT NULL, job_id INT NOT NULL, resume_text VARCHAR(500), status TINYINT DEFAULT 0, apply_time DATETIME DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (student_id) REFERENCES t_user(id), FOREIGN KEY (job_id) REFERENCES t_job(id) ); CREATE TABLE t_collect ( id INT PRIMARY KEY AUTO_INCREMENT, student_id INT NOT NULL, job_id INT NOT NULL, collect_time DATETIME DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (student_id) REFERENCES t_user(id), FOREIGN KEY (job_id) REFERENCES t_job(id) ); CREATE TABLE t_notice ( id INT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(200) NOT NULL, content TEXT, create_time DATETIME DEFAULT CURRENT_TIMESTAMP );

这里有一个体验细节：密码字段我设置的是VARCHAR(64)，用MD5加密后正好32个字符，之所以留了64的余量，是以后想升级成SHA-256或加盐加密不需要改表结构。数据库设计一定要给变量留扩展空间，别把长度卡得太死。

4. 核心功能实现与关键代码解析

4.1 注册登录模块——校验规则与MD5加密的落地写法

登录注册是每个系统都有的模块，但多数毕设写得很敷衍。这个系统的注册逻辑里，我做了两个容易被忽略但也容易被问到的点：一是用户名合法性校验，二是密码加密存储。

用户名校验要求只能由字母、数字、下划线组成，同时长度6到18位。这里java里面判断字符串是否包含字母和数字外的非法字符，最好用正则而不是逐个字符遍历。我顺手写了个工具方法：

public class StringUtil { public static boolean isValidUsername(String username) { if (username == null) return false; String regex = "^[a-zA-Z0-9_]{6,18}$"; return username.matches(regex); } public static boolean isNotEmpty(String str) { return str != null && !str.trim().isEmpty(); } }

在RegisterServlet里，前端表单提交过来的参数不能直接信。先做非空判断，再做合法性判断，最后查重——查重这一步必须走数据库查username字段，不能只在前端做。任何用户输入都是不可信的，这句话是Web开发的铁律。

密码加密我用的工具类是Md5Util，核心代码就是把字符串做一次标准MD5摘要：

public class Md5Util { public static String md5(String input) { try { MessageDigest md = MessageDigest.getInstance("MD5"); byte[] bytes = md.digest(input.getBytes("UTF-8")); StringBuilder sb = new StringBuilder(); for (byte b : bytes) { String hex = Integer.toHexString(0xff & b); if (hex.length() == 1) sb.append('0'); sb.append(hex); } return sb.toString(); } catch (Exception e) { throw new RuntimeException("MD5加密失败", e); } } }

登录成功后把用户对象放进Session，后续每个页面判断session.getAttribute("user")是否为空，为空就踢回登录页。这个拦截判断是写在所有需要登录才能访问的Servlet入口处的，写一遍就全项目复用，不做的话直接刷一个JSP地址就能绕过登录，那是重大安全漏洞。

4.2 兼职发布与学生报名——状态流转的逻辑闭环

雇主发布兼职的流程是：填写表单 → 写入数据库status=0→ 跳转“我的发布”页面 → 管理员在后台审核通过 →status改为1 → 学生可见；审核拒绝则直接标记为不通过。

写业务逻辑时，我把这条链路简化成两个方法：insertJob和auditJob。审核动作放在管理员Servlet中，配合一个简单的参数判断：

int jobId = Integer.parseInt(request.getParameter("jobId")); int status = Integer.parseInt(request.getParameter("status")); jobService.updateJobStatus(jobId, status);

学生报名兼职的逻辑类似但更关键，注意重复报名这个问题。一个学生不能对同一个岗位投两次简历，否则会出现数据重复，雇主那边会看到同一个学生报了两遍。解决方案是在写入t_application前做一次唯一性检查：

public boolean hasApplied(int studentId, int jobId) { String sql = "SELECT COUNT(*) FROM t_application WHERE student_id=? AND job_id=?"; // 执行查询，返回是否大于0 }

同时，在数据库层给t_application表加一个UNIQUE(student_id, job_id)联合唯一索引，双保险。这就是所谓“业务层校验 + 数据库约束”的双重防线，单靠一层总是有漏洞。

4.3 兼职列表与分页检索——数组越界异常的高发地段

列表页是毕设里最不能省功能，因为分页展示几乎是必考点。分页类PageBean承载页码、每页条数、总记录数、总页数、数据列表五个字段，核心查询就是LIMIT offset, pageSize。

offset = (currentPage - 1) * pageSize，这一步看着简单，实际出错率极高。很多同学在点击“下一页”时没有判断当前页码是不是已经是最后一页了，导致currentPage超过总页数，offset超出数据量，List拿到空集合还好，万一拼接数组时直接下标越界，IndexOutOfBoundsException一抛，整个页面就500了。

我习惯在分页查询入口处强制做一次边界钳制：

public PageBean<PtJob> findJobsByPage(int currentPage, int pageSize) { int totalCount = jobDao.countJobs(); int totalPages = (totalCount + pageSize - 1) / pageSize; if (currentPage < 1) currentPage = 1; if (currentPage > totalPages) currentPage = totalPages; // 计算offset并查询 }

还有一个多数教程不会说的点：JSP列表页用EL表达式 + JSTL的<c:forEach>输出数据时，空集合也要判断。${empty jobList}先判断，为空就给用户展示“暂无兼职信息”，而不是打印一片空白，这种细节直接影响答辩现场的系统演示效果。

4.4 个人信息展示页面与防重复提交

找兼职的体验里，个人信息展示页是雇主查看学生简历时必看的地方。这个页面要展示头像、姓名、学校、联系方式、个人简介，同时提供编辑入口。头像上传我用的方案是把图片保存到WebContent/uploads/目录，数据库只存相对路径，显示时用<img src="${user.avatar}">输出。

“JSP页面加载完自动刷新一次”这个需求在很多场景下会用到——比如报名成功后需要拉取最新数据。但要注意，刷新操作可能造成表单重复提交。经典的处理方案是PRG模式（Post/Redirect/Get）。

// 在Servlet中，处理完业务后不直接转发JSP，而是重定向 response.sendRedirect(request.getContextPath() + "/jobDetail?jobId=" + jobId);

这样浏览器上的地址会变成GET请求的URL，用户再怎么按F5都只是拉取数据，不会重新提交表单。如果用的是request.getRequestDispatcher().forward(...)转发，刷一下页面就二次投递了，这是毕设里极常见的坑。

5. 从零搭建环境的实操步骤

5.1 JDK、Tomcat、MySQL的安装与配置细节

很多同学项目代码写得没问题，一换电脑换环境就崩了几个小时。问题的根源百分之八十是Java环境变量配置不细心。JDK安装完整流程是：从官网或镜像站下载安装包 → 安装到指定目录 → 配置JAVA_HOME→ 把%JAVA_HOME%\bin加入PATH。

装完后在命令行验证：

java -version javac -version

两条命令都有输出版本号才说明JDK正常。java能跑不代表javac能编译，后者依赖的正是JAVA_HOME这个环境变量，很多人只配了PATH没配JAVA_HOME，Eclipse还能跑，命令行编译就废了。

Tomcat安装更简单——解压版直接解压，8.5版本以上不需要安装程序。关键是把Tomcat和Eclipse关联：在Eclipse里选“Window → Preferences → Server → Runtime Environments → Add”，选择Tomcat版本，指向解压目录。之后创建Dynamic Web Project时Target runtime选这个Tomcat，就能直接发布运行。

MySQL的坑主要出在8.0版本的驱动上。用MySQL 8.0必须配mysql-connector-java-8.0.33.jar，连接的URL要加时区参数：

String url = "jdbc:mysql://localhost:3306/db_partjob?useSSL=false&serverTimezone=Asia/Shanghai&characterEncoding=utf8"; Class.forName("com.mysql.cj.jdbc.Driver");

5.7版本可以用com.mysql.jdbc.Driver和旧URL，Maven或手动导包时看清楚版本对应关系，能少踩一半的坑。

5.2 在Eclipse中创建项目并连接数据库的完整流程

打开Eclipse，选择File → New → Dynamic Web Project，项目名填PartTimeJobSystem，Target runtime选你刚配好的Tomcat，Configuration选Default Configuration for Apache Tomcat，一路Next到Finish。这时项目结构里会自动生成WebContent目录，但web.xml不会自动创建，需要在WebContent/WEB-INF下手动新建一个web.xml。

web.xml里重点配置两件事：欢迎页和过滤器。欢迎页指定index.jsp；如果全站要统一处理编码，我推荐配一个CharacterEncodingFilter，在项目里写一个类实现Filter接口，里面直接：

request.setCharacterEncoding("UTF-8"); response.setCharacterEncoding("UTF-8"); chain.doFilter(request, response);

如果你的页面中文乱码、GET参数乱码、POST参数乱码，三个地方查：一是JSP页面顶部的pageEncoding="UTF-8"，二是数据库连接URL的characterEncoding=utf8，三是Servlet里是否执行了上面这个Filter。三处统一后基本不会再有编码烦恼。

数据库连接工具类DBUtil用静态块加载驱动，获取连接时避免每次新实例化。一个小优化是使用ThreadLocal<Connection>保存当前线程的连接，确保事务环境下多个DAO用的都是同一个Connection。毕设里一般不用做到事务级别，但连接工具类写得规范了，后续想加功能也顺畅。

5.3 部署到Tomcat并访问全流程自测

项目写完后，右键选中项目 →Run As → Run on Server，Eclipse会自动把项目发布到Tomcat的webapps目录。浏览器访问http://localhost:8080/PartTimeJobSystem/，先看到的是欢迎页，我建议欢迎页不要做成直接登录，可以放一个系统首页，左边简介、右边快速登录入口，这样演示时观感更好。

自测清单建议按这个顺序测：注册学生账号 → 注册雇主账号 → 管理员账号登录后台审核 → 雇主发布兼职 → 审核通过 → 学生看到兼职并报名 → 雇主查看报名学生 → 雇主录用 → 学生个人中心看到录用状态。整套流程能串下来，系统主体功能就算闭环了。

6. 常见问题排查与避坑指南

6.1 部署期高发的五个“环境病”

我总结一下自己辅导毕设时遇到的最高频问题，每条都给出排查思路和解决方案。

数据库连接失败：错误信息通常是Communications link failure或Unknown database。排查顺序是：MySQL服务是否启动 → 用户名密码是否正确 → 库名是否一致 → 驱动版本与MySQL版本是否匹配 → URL里有没有写错端口。不要上来就怀疑代码，先命令行试一次mysql -u root -p能登录环境就没问题。

404错误：访问项目返回404，多数情况下是项目没有被Tomcat加载。打开Tomcat的webapps目录，看看有没有发布成功的项目文件夹；也有可能是访问路径和web.xml或Servlet注解里配置的URL不一致。JSP页面用<%@ page %>指令里如果没引入pageEncoding，中文文件名或者路径也可能出问题。

500错误：这是最需要看控制台的。找到Eclipse底部的Console窗口，刷新页面看红色的异常栈。最常见的是NullPointerException（某个对象没取到、参数名写错、session里没有数据）、ClassNotFoundException（驱动包没放到WEB-INF/lib下）、SQLException（SQL语句和表结构不一致）。看到500别慌，异常信息已经告诉你怎么修了。

端口被占用：启动Tomcat时报Port 8080 required by Tomcat v9.0 Server at localhost is already in use，说明之前Tomcat没正常关闭。要么找到进程taskkill /F /PID 进程号，要么换成8081端口。改端口在Eclipse的Server选项卡中双击服务器，在Ports一栏调整HTTP/1.1数值。

连接不上MySQL驱动：控制台报No suitable driver found，最直接的原因是mysql-connector-java.jar没有放到WebContent/WEB-INF/lib目录下。只加到Build Path是不够的，运行时的Web容器只认WEB-INF下的包。

6.2 开发期业务逻辑的四个隐蔽雷区

环境问题之外，更隐蔽的是业务逻辑本身的雷区。

分页越界在前面已经说过，核心是进入方法时就钳制currentPage范围。

重复报名就是“先查再插入”顺序写反了，或者查了但没用同一个数据库连接，导致查的时候没有、插入的时候别人已经插过一条了。解决方法是数据库加唯一索引兜底。

文件上传乱码或路径失效：如果头像上传后图片加载不出，检查上传保存路径写的是绝对路径还是相对路径。项目发布后WebContent/uploads/对应的实际磁盘路径是webapps/项目名/uploads/，千万别用System.getProperty("user.dir")这种临时目录。建议用request.getServletContext().getRealPath("/uploads")获取真实路径，再拼接文件名保存。

日期处理格式不匹配：JSP表单提交的日期是字符串2025-05-20，数据库字段是DATE类型，直接PreparedStatement.setDate需要把字符串转成java.sql.Date，注意SimpleDateFormat的格式模板必须和前端input type="date"的格式一致，否则就报ParseException。常见的处理方法：

String dateStr = request.getParameter("startDate"); SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd"); java.util.Date parsed = sdf.parse(dateStr); java.sql.Date sqlDate = new java.sql.Date(parsed.getTime());

6.3 答辩演示时最容易翻车的三个瞬间

最后分享几个答辩现场的“翻车点”。

第一，演示前一定要重启一遍项目。很多同学在开发模式下改了代码但没重启Tomcat，页面显示的是旧数据，答辩导师一操作发现“怎么我点的和你讲的不一样”。重启后全流程走一遍再开始演示。

第二，先演示学生视角再切换管理员。答辩时操作路径要设计好：先用学生登录看兼职，用雇主登录看发布和录用，最后用管理员登录看审核，这样能把三种角色全部展示一遍。如果一开始就用管理员登录，学生和雇主的交互逻辑很难再穿插展示，讲述节奏会乱。

第三，账号密码要提前准备好。我建议准备三个固定测试账号：学生student01、雇主employer01、管理员admin，密码统一123456。现场敲键盘输账号容易输错，直接复制粘贴虽然快，但要注意别把密码暴露得太刻意。测试数据要造得真实一些：收录十几个兼职，分不同类别和薪资，投递记录至少留个七八条，这样列表页、个人中心、数据统计才有内容可看，演示效果至少提升一个档。

我的实际开发体会

这个项目我前后完整带完过四五个学生，每一次做完都有同一个感受：传统JSP + Servlet的项目看着“老旧”，但恰恰因为它不帮你做任何封装，你才会真正理解HTTP请求从浏览器到数据库再回到浏览器的全过程。遇到NullPointerException能一眼定位是哪个对象，而不是把Spring的IoC容器换一遍；看到500错误知道去Console看栈，而不是删了重写。这些基本功往深了说，它就是你后面学Spring Boot、学微服务时的底层地基。

最后再分享一个实用小技巧：给兼职列表添加“排序”功能。只需要在DAO层增加一个按create_time倒序的排序参数，JSP页面在上方做一个<select>下拉框，给jobListServlet传一个orderBy参数。这个功能代码量不大，但答辩时导师问“你的系统有没有搜索和排序功能”时，你就有得说了，而且它是学生用户实际使用中需求最真实的功能。

整份代码写下来不过几千行，工程量不算大，但每一层的逻辑都是完完整整的Web开发流程。照着这个思路做下来，你会发现，毕设最大的收获不是那张优秀论文证书，而是你终于能独立把一个需求从“想法”推进到“可运行系统”了。