1. 这个系统到底做什么：先想明白业务再写代码
1.1 兼职平台的核心业务闭环
最近我把一个学生项目的“蜗牛兼职网”从零到一完整实现了一遍，用的技术栈是 Java SpringBoot + Vue3 + MyBatis，数据库是 MySQL，前后端完全分离。这套东西做完之后我有一个很直观的感受：它名义上是个“毕业设计/课程设计”级别的项目，但涉及的技术面和业务完整度，已经足够帮你理清一整条企业级开发的套路了。
先把这个项目的业务边界说清楚。所谓“兼职网”，本质是一个信息撮合平台，连接两端：一端是有兼职需求的企业/雇主，另一端是想找兼职的学生或社会人员。平台上最核心的动作是：雇主发布职位信息，兼职者浏览、检索、投递简历，雇主筛选后录取，被录取的人完成兼职任务，最后平台结算报酬。再加上用户注册登录、个人信息维护、职位收藏、浏览历史、后台管理这些外围功能，一套“蜗牛兼职网”就形成了一个可闭环的微型业务生态。
很多同学拿到这个题目后第一反应是“不就是个 CRUD 吗”，真动手才发现完全不是那么回事。光是一个“发布职位”的流程，就牵扯到表单校验、富文本内容存储、薪资字段格式化、城市区域级联选择、上下架状态管理；再往后做投递，又牵扯到同一用户不能重复投递同一个职位、状态流转只能单向推进（待处理→已查看→已录用→已结算）等约束。说到底，复杂的东西不在某个单独功能，而在各个模块之间的交互规则。
1.2 技术选型背后的理由
这个项目选 SpringBoot + Vue3 + MyBatis + MySQL，绝不是一个随意的组合，它恰好覆盖了当前国内中小型项目最主流、也最容易被面试官追问的一套技术栈。
SpringBoot 解决的是后端基础设施问题。用 SpringBoot 2.x 起步，内置 Tomcat，starter 依赖一拉，一个可独立运行的 jar 包就能把整个后端跑起来。相比传统 SSM（Spring + SpringMVC + MyBatis）的 XML 配置地狱，SpringBoot 用自动配置把大量样板工作消掉了，这对课程设计和快速上手都是最友好的选择。
Vue3 则是目前前端框架里的绝对主流。Vue3 比 Vue2 最大的变化在于 Composition API 和响应式系统的重构。在蜗牛兼职网这种中后台+展示混合场景里，Vue3 配合 Vite 构建工具，开发体验明显比 Vue2 + Webpack 轻快很多。而且 Vue3 生态已经非常成熟，像 Element Plus 这类组件库对快速搭建后台管理界面极其顺手。
MyBatis 是另一个有意思的选择。很多人纠结“为什么不用 MyBatis-Plus，为什么不用 JPA”，我的答案是：MyBatis 的 SQL 可控性在课程设计答辩时反而是加分项。你可以拿着 xml 里的 SQL 当场讲清楚“这条语句为什么用 LEFT JOIN”“这个子查询能不能优化”，这是 JPA 自动生成 SQL 很难做到的。如果项目里需要的恰好是几张表的关联查询和统计报表，MyBatis 会让你在写 SQL 时对性能有更强的掌控力。
MySQL 作为存储层没有悬念，5.7 或 8.0 都行，8.0 注意驱动和时区问题就好了。整个技术栈组合起来，覆盖面广却不花哨，做出来的东西既能看到完整效果，又有充足的技术点可以做面试表达。
2. 数据库设计与关键表结构：地基不牢，后面全是坑
2.1 六张核心表怎么划分
蜗牛兼职网的第一版数据库我设计成六张核心业务表加两张辅助表。核心业务表分别是：用户表（t_user）、职位表（t_job）、投递记录表（t_delivery）、职位收藏表（t_favorite）、简历表（t_resume）、订单结算表（t_order）。辅助表是职位类别表（t_category）和管理员表（t_admin）。
用户表是所有业务的入口，字段别贪多，够用就行。我用的几个关键字段是：id、username（用户名）、password（BCrypt 加密后的密文）、phone（手机号）、role（角色标识：0-普通用户，1-雇主，2-管理员）、status（状态：0禁用，1启用）、create_time、update_time。这里有个容易踩的坑：很多同学喜欢用自增 id，但分页和相关联插入时 MyBatis 需要回填主键，所以 service 层一定要开启 useGeneratedKeys，否则插入完拿不到 id 后续逻辑全断。
职位表字段略多，它是整个项目信息密度最高的一张表，我列一下：
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| title | varchar(100) | 职位名称 |
| category_id | int | 分类外键 |
| salary_min | decimal(10,2) | 最低薪资 |
| salary_max | decimal(10,2) | 最高薪资 |
| city | varchar(50) | 工作城市 |
| address | varchar(255) | 详细地址 |
| job_type | tinyint | 兼职类型（日结/周结/月结） |
| detail | text | 职位描述 |
| publisher_id | bigint | 发布者用户ID |
| status | tinyint | 1-招聘中，0-已下架 |
| view_count | int | 浏览次数 |
| create_time | datetime | 发布时间 |
薪资字段必须用 decimal(10,2)，千万别用 float/double，面试时如果被问到精度问题会非常难看。日结/周结/月结这种枚举语义的字段用 tinyint 存，比用 varchar 省空间，而且查询条件写起来干净。
投递表是连接职位和用户的桥梁，核心设计是一个唯一约束。组合唯一索引就建在 user_id + job_id 上，这样可以在数据库层面直接挡住重复投递，不用在应用层先查一遍再加锁。表的字段包括：id、user_id、job_id、resume_id（投递时用的简历）、status（0-待处理，1-已查看，2-已录用，3-已拒绝，4-已取消）、apply_time、update_time。状态流转是后面业务代码里的重头戏，数据库层面用 status 字段配合一个简单的校验方法就可以管住非法流转。
简历表主要是展示型数据，采用和用户表 1:1 设计，字段包括自我介绍、教育经历、工作经历、技能标签、期望薪资范围等。这里我用了非常大的 text 字段去存教育经历和工作经历，其实在规范化设计里应该拆表，但考虑课程设计的数据量级别，单表单存反而让前后端联调简单很多，这也是实际开发里常见的取舍。
订单结算表是为了把“兼职完成后怎么给钱”这个闭环落地。字段包括 id、job_id、user_id、amount（结算金额）、status（0-待确认，1-已确认，2-已完成）、pay_time、备注。这张表同时记录了订单归属和金额状态，后续做简单的数据统计（比如平台累计发放兼职报酬）就靠它。
2.2 防坑细节：字段类型、外键、时间字段
数据库设计里有几个细节，直接影响后面代码的写法，我单独拎出来说一下。
第一，时间字段统一用 datetime，Java 端使用 LocalDateTime 对应。不要用 timestamp 存到 2038 年就溢出了，虽然对课程设计没影响，但这是个专业性的体现。MySQL 8.0 连接时还要在 JDBC URL 上加上 serverTimezone=Asia/Shanghai，我这次用 8.0.33 的驱动，没加这个参数直接报异常，后面会详说。
第二，外键到底建不建？我的方案是所有表只建普通索引，不建物理外键约束。理由很简单：物理外键在删除和更新时的连锁反应很难控制，而且在分库分表、迁移数据时是累赘。业务关联的完整性在 service 层把好关就行。但索引一定要建，尤其是 user_id、job_id、publisher_id 这类高频查询条件的字段。加索引的成本极低，收益在数据量上来之后天差地别。
第三，varchar 长度不要一刀切。用户名定 32、手机号定 11、城市定 50，职位标题定 100 就够了。很多同学喜欢所有字符串都 varchar(255)，结果索引长度超标不说，纯属偷懒。
第四，注意删除策略。用户表和职位表不建议物理删除，用 status 或一个 is_deleted 字段做逻辑删除。兼职市场里经常有用户投递记录被撤销的诉求，逻辑删除保留数据还能给后续做“浏览历史”和“行为分析”留余地。我在实现中用 MyBatis 的 update 代替 delete，凡是 mapper 里的“删除”都是 UPDATE 语句把状态改成 1，效果完全不一样。
3. 后端关键模块实现：从登录鉴权到业务逻辑
3.1 JWT 认证怎么落地
蜗牛兼职网的用户认证我用的 JWT（JSON Web Token）方案。选它而不是传统的 Session 是因为前后端分离的项目天然适合无状态认证：后端不存会话，前端拿到 token 后在请求头里携带即可，跨域也好处理，部署时也不需要考虑 Session 同步。
JWT 的落地代码不复杂，核心是引入 jjwt 依赖，写一个 TokenService 负责生成和解析 token，再写一个拦截器把需要登录的接口保护起来。token 里我放了三个信息：用户 id、用户名、角色。过期时间定为 24 小时，不要为了省事传“永久有效”，后面你会后悔。
// TokenService 核心逻辑 public String generateToken(Long userId, String username, Integer role) { return Jwts.builder() .setSubject(username) .claim("userId", userId) .claim("role", role) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + 86400000L)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); }拦截器方面，我用的是 Spring MVC 的 HandlerInterceptor，在 preHandle 方法里解析 Authorization 头。这里有两个实操心得：一是解析失败要区分“token 过期”和“token 非法”，两者返回的 HTTP 状态码不一样，前端才好决定是弹提示还是跳登录页；二是凡是公开接口（如登录、注册、职位列表）必须在 WebConfig 里放行，后台管理接口还要单独校验管理员角色，不支持简单的“非空即通过”。
关于 password 存储，务必用 BCrypt。Spring Security Crypto 模块里的 BCryptPasswordEncoder 可以直接引进来用，每次加密结果都不一样，数据库里存的是带盐的哈希。千万别用 MD5，面试官看到 MD5 基本都会追问，而且现实里 MD5 的确已经不安全了。
3.2 职位发布与检索的 SQL 细节
职位的发布相对简单，就是往 t_job 插入一条记录，但有一个小细节需要注意——插入时要把 detail 这个 text 字段做 XSS 过滤。前端很可能会给职位详情用一个富文本编辑器，用户输入的内容如果直接入库再回显，等于给自己留了一个存储型 XSS 漏洞。我后端的处理方式是封装了一个 HtmlUtil，对
