1. 项目概述与核心价值
1.1 这个系统到底解决什么问题
大学生就业信息管理，听起来像是一个老生常谈的管理系统课题，但真把它做完做完，才发现这里面藏着的门道远比想象中多。这个项目表面上是一个典型的Java Web全栈应用，本质上却是一套围绕“岗位信息流转”与“学生求职行为”构建的双端业务平台。
我接手这个课题的时候，第一反应是：这不就是增删改查吗？学生表、企业表、岗位表，三个表来回查，配个登录注册，完事了。但真正进入需求梳理阶段，才发现问题没那么简单。就业信息管理不同于普通的图书管理或商品管理，它牵扯到的核心痛点有三个：第一，信息是双向流动的，学生要找工作，企业要招人，平台不能只做一个单向的公告板；第二，状态是动态变化的，一份简历投递出去，要经历投递、查看、邀约、录用、拒绝等多个状态节点；第三，数据是会产生实际业务后果的，学生投递了哪些岗位、企业发布了哪些职位，这些记录需要被可靠地保存和追溯。
如果只是做一个“课程设计水平”的系统，那确实三个表就够了。但如果你想把这个项目做出真正的竞争力，让它既能通过答辩，又能写进简历，甚至能在面试时讲出亮点，那就要按照“一个真实可用的招聘平台”标准去做。这也是我在这篇博文里要完整分享的核心思路。
1.2 适合哪些人参考
这个项目最适合三类人群：
第一类是正在准备Java Web课程设计或毕业设计的在校生。这个项目的技术栈非常经典——前端Vue、后端Spring Boot、数据库MySQL，是当前企业级Java开发的主流组合，用它做课设，既能覆盖教学大纲里的知识点，又能体现一定的工程化水平。
第二类是正在刷Java面试题、准备校招的应届生。原因很简单，就业信息管理系统这个业务场景覆盖面广，里面涉及的角色权限控制、分页查询、文件上传、状态流转这类功能，恰恰是面试官最爱问的“你项目里遇到过什么难点”的好素材。把这类项目吃透，远比背八股文更有说服力。
第三类是打算把毕设项目扩展成完整作品集的开发者。这个系统的数据模型天然适合扩展——你可以往上加企业端驾驶舱、学生端推荐算法、管理端数据可视化，每一个扩展点都能成为面试时的亮点。
2. 整体设计与技术选型思路
2.1 技术栈选型的底层逻辑
技术选型这件事，我在做项目之前反复权衡过。最终确定的是：后端Spring Boot 2.7 + MyBatis-Plus，前端Vue 3 + Element Plus + Axios，数据库MySQL 8.0，鉴权用JWT。这个组合在今天看来不算新颖，但胜在稳定、资料多、踩坑成本低。
为什么不用SSH或SSM传统架构？Spring Boot的优势在于自动配置和内置容器，能大幅减少繁琐的XML配置，让开发者把精力集中在业务逻辑上。对于课设项目来说，Spring Boot 2.x依旧是资料最丰富的版本，遇到问题几乎都能搜到解决方案。MyBatis-Plus则是在MyBatis基础上的增强工具，内置了通用的增删改查方法，开发效率比手写SQL高很多，而且它的分页插件做得非常成熟，适配这个系统的分页查询场景恰到好处。
前端选择Vue 3而不是Vue 2，考虑的是长远价值。Vue 3的Composition API在逻辑复用方面确实比Options API有优势，而且现在新项目基本都在用Vue 3，学会它对你的求职更有利。Element Plus作为Vue 3生态最成熟的中后台UI组件库，表格、表单、弹窗、分页这些组件开箱即用，能在最短时间内搭建出符合企业管理后台审美风格的界面。
鉴权方案选JWT而非Session，也是一个值得展开的决策点。传统的Session方案需要服务端存储会话状态，在前后端分离架构下，Session的跨域处理和集群共享都是麻烦事。JWT把用户信息加密后存在客户端，服务端无需维护会话状态，天然适合前后端分离场景。不过JWT也有它的坑——token无法在服务端主动失效，所以在设计退出登录功能时，需要配合前端清除token的方式处理。
2.2 角色权限模型的设计策略
角色权限是这个系统里最容易做砸的部分。很多课设项目的权限设计就两句话：管理员能进后台，普通用户能登录。但就业信息管理系统天然有三种核心角色：学生、企业、管理员，外加一个超级管理员兜底。
我的权限模型是这样设计的：数据库里用户表（user）通过role字段区分角色，取值包括STUDENT、COMPANY、ADMIN、SUPER_ADMIN。后端通过Spring MVC拦截器校验JWT中的角色信息，前端则通过路由守卫和动态菜单实现页面级权限控制。
这里有一个容易被忽视的细节：前端权限只能控制“看不看得到入口”，真正的安全必须落在后端。比如一个学生如果直接拿着接口地址去请求管理员接口，前端路由守卫拦不住他，后端拦截器必须根据token里的角色信息进行二次校验。我在实现时专门写了一个@RequireRole注解配合拦截器使用，在需要权限控制的接口上加上注解，代码看起来干净，权限控制逻辑也统一。
前端的动态菜单实现思路是：用户登录后，前端根据角色返回不同的菜单配置。学生端显示职位浏览、简历管理、投递记录、面试通知等菜单；企业端显示职位管理、简历筛选、面试安排等菜单；管理员端显示用户管理、职位审核、数据统计等菜单。每类菜单路由映射到独立的Vue组件，通过动态路由的方式注册，避免把所有页面都打进一个包里。
2.3 功能模块划分与业务流程梳理
这个系统的完整功能模块划分如下：
- 登录注册模块：学生、企业、管理员三类账号的统一认证入口，包含注册审核、密码加密存储、JWT签发与刷新
- 学生端模块：个人信息维护、简历创建与编辑、职位浏览与搜索、简历投递、投递状态跟踪、面试通知查看
- 企业端模块：企业信息维护、职位发布与管理、收到的简历列表、简历状态处理、面试邀约发送
- 管理端模块：用户管理（禁用/启用）、职位审核（通过/驳回）、企业认证审核、数据统计看板
- 系统公共模块：文件上传（头像、简历附件）、数据字典、分页查询、统一异常处理
业务流程中最核心的一条线是“职位发布→学生投递→企业筛选→面试邀约→录用结果”。这条流程的每个节点都对应着数据库中的一条或多条记录变更。比如学生投递职位时，除了要在投递记录表（delivery_record）插入一条新记录外，还要更新职位表（job）的投递数量统计字段，这个操作需要放在同一个事务里，避免数据不一致。
3. 数据库设计实战
3.1 核心数据表结构拆解
数据库设计是整个项目的地基，地基打不好，后面所有代码都在填坑。我按照“用户中心、业务主体、关联记录”三层模型来设计数据表。
用户中心层包含用户表（user）和角色表（role）。用户表的核心字段包括：id、username、password（BCrypt加密）、phone、email、avatar、role_id、status（启用/禁用）、create_time。这里有个设计细节：密码字段的长度至少要有60位，因为BCrypt加密后的字符串长度是60，很多新手把这个字段设计成varchar(32)，结果加密后的密码存不进去，报错半天找不到原因。
业务主体层包含学生表（student）、企业表（company）、职位表（job）、简历表（resume）。这里采用了用户表与业务表分离的设计：用户表只管登录认证，学生和企业是用户之后关联的业务扩展信息。这样的好处是后期如果要增加新的角色，不需要改动用户表结构，只需新增对应的业务表。
关联记录层包含投递记录表（delivery_record）、面试记录表（interview_record）、收藏表（favorite）、职位审核记录表（job_audit_log）。
以投递记录表为例，它的核心字段有：id、student_id、job_id、company_id、status（0投递成功/1企业已查看/2面试邀约/3已录用/4已拒绝）、delivery_time、update_time。这里冗余了company_id字段，虽然通过job_id可以关联查询出企业信息，但在投递列表页面高频使用企业信息展示的场景下，冗余字段能少一次关联查询，这个取舍是合理的。
3.2 关键外键关系与索引优化
表之间的关系非常明确：学生表与用户表一对一，企业表与用户表一对一，职位表与企业表一对多，简历表与学生表一对一，投递记录表与职位表、学生表多对一。
在索引设计上，我踩过不少坑。投递记录表的查询场景主要分两类：学生查看“我投递了哪些职位”（WHERE student_id = ?），企业查看“我的职位收到了哪些简历”（WHERE company_id = ? AND status = ?）。因此我在投递记录表上建立了联合索引（company_id, status）和单列索引（student_id）。
职位表的查询场景更复杂。学生端职位列表页通常需要按关键词搜索、按工作城市筛选、按薪资范围筛选、按发布时间排序。这时候多列索引的顺序就很有讲究。我的做法是建立联合索引（status, audit_status, create_time），把最常用于过滤的字段放在最前面。搜索关键词字段（job_name、job_description）则用LIKE模糊查询匹配，需要注意前缀通配符会让索引失效，但这个量级的数据下影响不大。
MySQL 8.0的utf8mb4字符集是必选项，它能完整支持emoji和生僻字。排序规则选择utf8mb4_general_ci即可，这在多数场景下性能优于utf8mb4_unicode_ci，而且对于中文排序没有明显的差异。所有的表都建议加上create_time和update_time两个字段，配合MyBatis-Plus的自动填充功能，能让数据审计变得非常轻松。
3.3 状态字段的枚举化管理
数据库状态字段的设计直接决定业务代码的复杂度。我的经验是：所有状态字段都使用int类型，用数字代表业务含义，并在Java代码中定义枚举类进行管理。
以投递状态为例，我在Java后端定义了DeliveryStatusEnum枚举：
public enum DeliveryStatusEnum { DELIVERED(0, "已投递"), VIEWED(1, "企业已查看"), INTERVIEW(2, "面试邀约"), OFFERED(3, "已录用"), REJECTED(4, "已拒绝"); private final Integer code; private final String desc; // 构造函数、getter方法省略 }这样做的好处非常明显：业务代码里不能出现魔法数字。比如判断一个投递记录是否处于“学生不可撤销”的状态，只需要调用枚举的静态方法进行判断，可读性远高于直接写if (status != 0 && status != 1)这种代码。
4. 后端核心功能实现要点
4.1 Spring Boot项目初始化与分层架构
后端项目我采用标准的四层架构：Controller层负责接收请求和返回响应，Service层负责业务逻辑编排，Mapper层负责数据库操作，entity层负责数据实体映射。
Controller层的设计有一个容易被忽略的规范：接口路径用复数形式，比如/api/students而不是/api/student，/api/jobs而不是/api/job。HTTP方法也要遵循RESTful语义：GET用于查询，POST用于新增，PUT用于更新，DELETE用于删除。虽然这不是强制要求，但遵循业界惯例写出来的接口，在面试时更容易获得认同。
Service层的核心原则是事务管理。一个完整的业务流程，比如企业审核通过一个职位，需要同时更新职位表的审核状态和公司表的发布职位数量，这两个操作必须放在同一个事务里。我用Spring的@Transactional注解进行声明式事务管理，并设置了rollbackFor = Exception.class，确保任何异常都会触发回滚。
统一返回结果的封装也是后端设计的重要一环。我定义了Result<T>泛型类，包含code、message、data三个字段。所有接口都返回这个包装类型，前端Axios拦截器只需要判断code是否为200即可。异常处理用@RestControllerAdvice全局异常处理器，业务异常和系统异常分类处理，业务异常返回具体的错误码，系统异常统一返回500并记录日志。
4.2 JWT鉴权与登录流程完整实现
登录流程是整个系统安全性的关键一环。密码加密我用的是BCrypt，这是Spring Security框架内置的加密算法，每次加密结果都带随机盐，即使两个用户的密码相同，加密后的密文也不一样，有效防止彩虹表攻击。
JWT工具类的核心逻辑分三步：生成token、解析token、校验token。生成token时需要指定过期时间，我设置的是24小时。Payload部分放入用户id、用户名和角色信息。签名算法是HS256，密钥配置在application.yml中。
这里要特别说明JWT和拦截器的配合方式。我自定义了一个JwtInterceptor拦截器，继承HandlerInterceptor接口，在preHandle方法中从请求头的Authorization字段获取token，解析后把用户信息放入ThreadLocal。这样后续的业务代码可以通过UserContext工具类直接获取当前登录用户信息，避免了在接口参数中反复传递用户id的麻烦。
Token的前端存储位置选择，也有学问。我最初把token存在localStorage，但仔细排查后发现这样有XSS攻击风险，于是改为存内存配合Vuex状态管理。每次页面刷新后从后端重新获取用户信息，安全性和用户体验可以兼得。
4.3 文件上传与静态资源处理
这个系统的文件上传功能涉及两个场景：用户头像上传和简历附件（PDF）上传。Spring Boot处理文件上传，核心是MultipartFile接口。需要注意的配置项是spring.servlet.multipart.max-file-size和max-request-size，默认值只有1MB和10MB，简历附件通常需要调大到10MB和30MB。
文件存储方案有本地存储和云存储两条路。本地存储的优点是简单、零成本、适合课程设计；云存储的优点是可靠、访问快、体现工程意识。为了项目能在答辩现场离线演示，我选择了本地存储方案。实现思路是：文件保存到服务器指定目录，文件名用UUID重命名避免冲突，文件访问路径映射到静态资源目录。
一个值得分享的细节：上传文件的保存路径不要用相对路径，尽量用绝对路径。我遇到过在idea中运行时文件保存正常、打成jar包后用java -jar运行却找不到文件路径的情况，原因就是相对路径依赖启动时的当前工作目录，而部署环境的工作目录不可控。用System.getProperty("user.dir")拼接绝对路径前缀，可以避免这个问题。
4.4 分页查询与条件动态拼接
职位列表页是系统最核心、也是请求量最大的接口。学生端职位列表要支持按关键词、城市、薪资范围、工作性质等多条件组合查询，还要分页展示。MyBatis-Plus的分页插件配置非常简单，只需要一个@Configuration类注册MybatisPlusInterceptor，添加PaginationInnerInterceptor即可。
条件查询可以借助MyBatis-Plus的LambdaQueryWrapper实现。比如根据关键词搜索职位名称和职位描述时：
LambdaQueryWrapper<Job> wrapper = new LambdaQueryWrapper<>(); if (StringUtils.hasText(keyword)) { wrapper.and(w -> w.like(Job::getJobName, keyword) .or().like(Job::getJobDescription, keyword)); } if (StringUtils.hasText(city)) { wrapper.eq(Job::getCity, city); } if (minSalary != null) { wrapper.ge(Job::getSalaryMin, minSalary); } if (maxSalary != null) { wrapper.le(Job::getSalaryMax, maxSalary); } wrapper.eq(Job::getStatus, 1).eq(Job::getAuditStatus, 1); wrapper.orderByDesc(Job::getCreateTime);注意StringUtils.hasText的判断可能还不够完善，我建议封装一个条件工具类，对空字符串、null、全空白字符串统一判定。这样代码会显得整洁很多，也避免了很多边界问题。
5. 前端核心页面与交互实现
5.1 Vue项目搭建与Axios二次封装
前端项目我基于Vite脚手架创建，相比Webpack，Vite的开发服务器启动速度有质的飞跃，改代码后的热更新几乎是瞬间生效，这对调试效率的提升非常明显。
Axios的二次封装是前端工程化的第一步。我封装了一个request工具类，做了三件重要的事：第一，请求拦截器统一添加Authorization请求头，从Vuex中获取token；第二，响应拦截器统一处理业务错误码，code不为200时弹出错误提示；第三，response里业务数据统一解包，让业务代码拿到的直接就是data字段。
Axios还有几个值得关注的细节：请求超时时间我设置为15秒，太短会导致慢网络环境下的大查询被误判超时，太长又会影响用户体验。跨域问题通过Vite的proxy配置解决，开发环境所有/api开头的请求代理到本机8080端口，避免了CORS的各种麻烦。
5.2 登录页与角色路由分发
登录页的设计看起来简单，实际上有一个容易被忽视的业务坑：不同角色登录后要跳转到不同的首页。学生登录后进入职位浏览页，企业登录后进入职位管理页，管理员登录后进入系统数据总览页。这个跳转逻辑需要在登录接口返回数据后，根据用户角色字段进行路由分发。
前端路由守卫的实现是保障页面权限的第二道防线。我在router.beforeEach守卫中做了三个判断：是否已登录、目标路由是否需要鉴权、当前用户的角色是否有权限访问该路由。没有权限时直接重定向到403页面，并给出提示信息。
路由懒加载也是一个值得养成的习惯。Vue Router支持动态import的方式加载组件，这样首屏只加载必要的JS，后续访问到对应页面才动态加载，能显著减少首屏加载时间。对于一个功能较多的后台管理系统，这个优化非常有用。
5.3 核心页面功能实操拆解
职位浏览页是最复杂的页面。顶部放置搜索表单，表单包含关键词、城市、薪资范围三个字段；中间是职位卡片列表或表格列表；底部是分页组件。职位卡片点击后弹出职位详情抽屉，展示职位描述、任职要求、薪资福利等信息，底部有“立即投递”按钮。
投递操作有一个必须处理的业务状态逻辑：同一个学生同一职位不能重复投递。前端在点击投递按钮之前，要先调用后端接口查询投递记录是否存在，存在的话按钮直接禁用并显示“已投递”。这个判断也可以放在后端做，但前端先做了体验更流畅。
简历管理页我采用了分段表单的设计：基本信息、教育经历、工作经历、项目经历、技能标签、自我评价，分段展示，每段一个表单卡片。简历的完整度通过进度条展现，字段填得越多进度条越满，这是很多招聘平台都有的功能，实现起来也很有成就感。简历的核心字段存储在设计好的resume表中，支持编辑后保存到草稿和提交审核两种状态。
企业端的核心是职位管理页。企业用户发布职位时，表单包含职位名称、职位类别、工作城市、薪资范围、学历要求、工作性质、职位描述、任职要求等字段。发布后职位进入待审核状态，管理员审核通过后才会在职位列表页公开展示。这个审核流程的设计在日常开发中很常见，理解了它，以后做内容审核类的功能就通了。
5.4 前端状态管理与接口联调
Vuex在项目中的使用需要控制好边界。用户信息、token这类全局状态适合放Vuex，但一些组件内部的状态宿命就该放在组件里。我把store模块分为user和app两个模块，user存用户信息、token、角色信息，app存菜单折叠状态等通用状态。
接口联调阶段是我建议你多花时间的环节。要确保前后端联调顺畅，最有效的方式是定义一份清晰的接口文档。我习惯用接口约定的方式，先和后端同学或者自己先把接口路径、请求方式、参数结构、返回结构定好，再各自开发，这样联调时能省去大量返工时间。我在这项目里总结了几个接口联调的高频问题：参数类型不一致（前端传字符串，后端需要数字）、日期格式不一致、文件上传的Content-Type设置错误。这些问题通过统一的接口文档和联调自测就能规避大半。
6. 常见问题与排错实录
6.1 数据库连接与编码问题
这个项目开发过程中，我遇到并解决了不少棘手问题，选几个有代表性的分享。
第一个是MySQL 8.0的时区问题。报错内容大概是The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized。原因是MySQL 8.0的时区设置默认是系统时区，而系统的中文时区在MySQL驱动中不认识。解决办法是在JDBC连接串后面加serverTimezone=Asia/Shanghai，或者在MySQL中设置set global time_zone = '+8:00'。
第二个是数据库乱码问题。解决方案很直接，建表时指定字符集utf8mb4，连接串加characterEncoding=utf8，页面和Java文件统一UTF-8编码，三层都查一遍就能定位问题所在。这个问题多出现在Windows平台，因为Windows默认编码是GBK。
6.2 前后端联调高频报错
跨域问题是前后端分离项目最常见的问题之一。开发环境通过Vite代理解决，但生产环境如果前后端部署在不同域名下，就需要在后端配置CORS。我用@CrossOrigin注解加在Controller类上，或者定义全局CORS配置类，二者选其一即可。
接口返回401或403的错误，通常是因为token过期或角色权限不足。前端遇到401应该跳转登录页并清除本地用户信息，遇到403应该跳转403页面。这里有一个细节：Axios拦截器里的401处理要避免进入死循环。如果登录接口本身返回401，而拦截器再跳转登录页，就会造成URL跳转的循环刷新。我的处理方式是记录请求路径，只在非登录接口返回401时才跳转登录页。
404错误通常来自接口路径或请求方式不匹配。前后端注释的路径只要有一个字母大小写不一致，就会404。用Postman或Apifox单独测一下后端接口，能快速定位是前端问题还是后端问题。
6.3 MyBatis-Plus与SQL相关的常见坑
MyBatis-Plus有一个让人又爱又恨的特性：逻辑删除。我给用户表和职位表都配置了逻辑删除字段deleted，这样删除操作实际上执行的是UPDATE语句。逻辑删除的好处是数据可恢复，坏处是如果不注意全局配置，很容易查询出已经被删除的数据。MyBatis-Plus的逻辑删除方案是在配置文件的全局配置里指定logic-delete-field，这样查询时会自动追加deleted = 0条件。
另一个坑是关于分页插件失效的问题。新版的MyBatis-Plus中，分页插件需要显式注册PaginationInnerInterceptor，如果只引入了依赖而忘了添加拦截器配置，分页查询会查出所有数据，甚至可能报total字段始终为0的错误。这个问题排查起来有一定难度，建议先检查配置类是否生效。
6.4 调试经验与开发效率建议
最后一个体会是开发效率问题。这个系统功能点不少，如果按部就班地写，很容易陷入重复劳动的泥潭。我的建议是：优先完成公共模块，再开发业务模块。公共模块包括统一返回结果、全局异常处理、JWT工具类、文件上传工具类、分页配置。这些模块一旦就绪，后续每个业务功能的开发都是“套模板”的过程，效率会提升很多。
7. 项目部署与演示准备
7.1 本地环境快速启动指南
项目写完之后，能在别人的电脑上快速跑起来，也是一项很重要的能力。我把启动步骤整理成清晰的清单，这样不管是答辩评委还是面试官，都能快速评估你的项目。
环境要求：JDK 1.8及以上、Maven 3.6及以上、Node.js 14及以上、MySQL 8.0。后端启动前需要用项目附带的数据脚本初始化数据库，然后用mvn spring-boot:run命令启动后端服务。前端在项目根目录执行npm install安装依赖，再执行npm run dev启动开发服务器。
注意：
npm install在国内网络环境下可能会因为镜像源问题失败，建议提前配置淘宝镜像源。命令是npm config set registry https://registry.npmmirror.com。
7.2 演示数据准备与答辩技巧
答辩演示时，最怕的情况是数据太少，页面显得空洞。我建议提前准备几套完整的数据：3个学生账号、2个企业账号、每个企业3到5个职位、若干条投递记录、几条面试邀约记录。这样演示时点开任何一个页面，都有真实的数据支撑。
答辩时讲解这个项目，我建议按照“业务背景→技术难点→业务亮点→扩展规划”的节奏。技术难点优先讲JWT鉴权与全局异常处理，业务亮点优先讲职位的审核流与投递的状态机设计。这些都是面试官或评委比较感兴趣的点。
还有一个容易被忽视的细节：演示前务必测试一下部署环境里前端能否正常访问后端接口。最稳妥的方式是把前后端都部署在同一台机器上，端口不一致不要紧，关键是网络要通、接口路径要匹配。
8. 项目扩展与面试价值提升
8.1 低成本高收益的扩展方向
课程设计做完只是起点，真正拉开差距的是后续的扩展。我总结过几个低成本高收益的扩展方向，每个方向的工作量都控制在2到3天以内。
第一个是在线聊天功能。学生收到面试邀约后，希望能和企业沟通详情。引入WebSocket实现简单的在线会话功能，能极大提升系统的完整度。WebSocket加上Spring的拦截器和JWT鉴权，实现一个简单的会话祝福，工作量比想象中小很多。这里的技术点——WebSocket握手时的鉴权、消息的持久化——在面试中都很能打。
第二个是基于标签的职位推荐。给简历和职位都打上技能标签（Java、Vue、MySQL、Python等），匹配度计算采用标签集合的交集数量排序。推荐逻辑不需要复杂的机器学习，一个简单的评分算法就能实现。面试时讲清楚思路比实现本身更重要。
第三个是管理员端的数据看板。用ECharts可视化展示各专业就业率、各城市岗位数量排名、薪资分布等指标。这个扩展不仅让系统看起来更完整，还能体现你对数据可视化工具的了解程度。
前三个扩展方向基本覆盖了WebSocket、推荐算法、数据可视化这三个面试高频话题。每个方向都是独立加分项，且彼此之间可以互相组合。
8.2 面试时如何把项目讲出亮点
我遇到过很多简历上写着“大学生就业信息管理系统”的候选人，一开口就是堆砌技术名词，然后被追问就露馅。真正好的项目讲述逻辑是：讲清楚业务矛盾在哪里，说明你用什么方案解决，对比同类方案的优劣。
比如提到JWT鉴权，不要说“我用了JWT”，要说“我对比了Session和JWT两种方案，Session在集群环境下需要额外的会话共享机制，而JWT无状态、适合前后端分离，所以我选择了JWT。但JWT无法主动失效，我通过前端清除token和短期过期策略来弥补”。这种对比式的表述才显得有思考深度。
再比如提到高并发场景，不要吹嘘“我的系统能支撑多少并发”，而是说“我用的技术方案是成熟的，如果要上线，还需要引入Redis缓存热点职位数据、RabbitMQ削峰投递请求”。面对高并发的问题，诚实展现你的方案演进思路，比吹牛要好得多。
8.3 从课设到真实项目的差距在哪里
最后说一点我这几年带项目的真实感受。课程设计和真实项目之间，差的从来不是技术栈，而是工程化思维。真实项目需要考虑日志规范、配置拆分、异常粒度、代码评审、回归测试、灰度发布，这些在课程设计里通常不会严格要求。但如果你想让自己在技术上更进一步，就应该主动往这个方向靠。
比如日志规范，我建议在关键业务节点打上INFO级别日志，操作成功后输出操作人和操作结果，异常时输出堆栈，方便追溯问题。再比如配置管理，把数据源配置、JWT密钥、文件上传路径等差异化配置从application.yml中拆分出来，用环境变量或配置中心管理，这会让项目结构更接近企业级标准。
每次做完一个项目，我都习惯写一份简单的项目复盘文档，记录技术选型的原因、踩过哪些坑、最优方案是什么、做的时候是怎么想的。面试前翻一翻，比临阵磨枪背面试题有用得多。
9. 一些在实践中的补充提醒
这个项目做到最后，我最大的感受是：写代码其实不难，难的是在每个环节都做出合理的选择。数据库字段长度留多少、状态码定义成什么、接口返回什么格式、权限怎么做、异常怎么处理，这些决策交织在一起，才真正决定了项目的质量。
如果你正在做类似项目，我建议你重点投入时间的环节是数据库设计和接口设计，因为这决定了你的代码是否能写得顺畅。前端和后端的联调阶段，也建议前置到开发的中期，不要等全部写完了才联调，那样问题会集中爆发，排错成本会成倍上升。
最后再分享一个小技巧：如果你打算把这个项目用在面试里，请一定花时间把数据库的设计文档和接口文档写清楚。这两份文档会让面试官一眼看出你对项目的掌控程度，比简历里多写十行技能清单都管用。我见过太多候选人简历写得天花乱坠，一问数据库表结构却支支吾吾，这其实是很可惜的。
