1. 项目缘起与整体设计思路收到过不少类似Spring Boot Vue做学生兼职系统的选题说实话这类项目在网上已经不算新鲜了但大多数repo代码质量堪忧要么只是把CRUD堆在一起要么前后端完全割裂看不出业务闭环。我这次梳理的是一个完整的、能真正跑起来的学生兼职管理系统覆盖了从学生端找兼职、投递简历到企业端发布岗位、审核简历再到管理员端做数据统计和用户审核的完整闭环。先说这个项目到底解决了什么问题。传统校园兼职信息基本靠QQ群、贴吧或者校园公告栏信息分散、真假难辨、结算纠纷时有发生。一个线上化、带审核机制、有流程记录的兼职管理系统至少能把信息发布—报名投递—企业筛选—录用反馈这条链路管理起来同时给学生、企业、校方三方一个相对清晰的角色划分。对于学生来说是找兼职的统一入口对于企业来说是低成本发布岗位的渠道对于管理员来说是把控信息质量和数据留痕的手段。这个系统的技术分层很明确前端用Vue我用的是Vue 3加Element Plus后面会解释为什么不用Vue 2后端用Spring Boot。前后端通过RESTful API交互JWT做身份认证MySQL存业务数据。整个架构不复杂但很适合教学、毕设、以及中小型校园信息化项目的扩展基线。你完全可以在这套骨架上加ES做全文检索加Redis扛并发或者把文件服务切到OSS扩展路径都是顺的。我当时选择这套技术栈的逻辑其实很朴素Spring Boot的生态太成熟了跟数据库打交道用MyBatis-Plus几乎不用写XMLVue 3的组合式API配Element Plus做后台管理界面的效率非常高。更重要的是这套栈学完之后你不是只会写这一个项目而是能顺着它理解前后端分离开发的通用套路这是它的隐性价值。1.1 核心需求拆解不管是做毕设还是接真实项目第一步一定是把需求拆干净。我当时把整个系统拆成了三个端学生端注册登录、浏览岗位、按分类/关键词筛选、投递简历、查看投递状态、收藏岗位、管理个人信息和简历。企业端注册登录、发布兼职岗位、维护岗位上下架、查看投递列表、筛选/通过/拒绝候选人、处理学生简历。管理员端用户管理审核企业资质、封禁异常账号、岗位审核控制劣质信息流入、数据统计岗位数量、用户增长、投递转化等基础指标。有些项目还会加结算管理模块让企业发布完工后对学生进行工资确认学校可以介入监管。如果时间够这确实是个很好的加分项。我这次的核心版本里保留了岗位管理、投递流程、用户体系和基础统计结算部分留了扩展口。需求拆到这里基本可以确认一件事这绝不是单纯的管理系统而是一个多角色、多状态流转的平台型业务。这也是它跟一般图书管理系统类项目的本质区别——状态多权限多业务逻辑重。1.2 角色权限模型的设计取舍角色权限是这类系统最容易翻车的地方。我建议不要一上来就上Spring Security OAuth2那种重型权限框架学生兼职系统的主流访问量撑不起那么复杂的权限设计反而会把自己绕晕。我选择的是JWT 拦截器 自定义注解的方式轻量且够用。具体设计是登录成功后后端签发JWTJWT中携带userId和role字段。前端拿到Token后存到localStorage每次请求在请求头里带上。后端写一个拦截器拦截所有需要登录的接口解析Token并校验角色。角色分三种STUDENT、COMPANY、ADMIN。在Controller的方法上用自定义注解标注允许访问的角色比如RequireRole(Role.STUDENT) GetMapping(/my/applications) public Result getMyApplications() { ... }拦截器里用反射判断当前handler方法上有哪些RequireRole注解如果当前用户的角色不在允许列表里直接返回403。这个方案的好处是权限逻辑集中但入口分散每写一个接口在方法上用一行注解就能声明谁能访问后期维护成本极低。注意不要把权限校验全放在前端。前端隐藏按钮只是用户体验层面的事真正的安全边界必须由后端兜底。实际项目中我遇到过只在前端做了管理员菜单隐藏、后端接口裸奔的案例被用户直接调接口删了数据千万不要重蹈覆辙。1.3 页面和交互流程的梳理这三个角色对应的前端页面差异比较大但可以抽象出几套通用页面模式列表搜索页岗位列表页—— 筛选器 表格 分页表单页发布岗位、编辑简历—— 表单 校验 提交详情页岗位详情、用户详情—— 信息展示 操作按钮学生端的核心路径是找兼职—看详情—投简历—查进度所以首页最重要的是搜索和分类入口岗位详情页要突出投递按钮和岗位关键信息薪资、时间、地点。企业端是发岗位—收简历—处理简历所以工作台要突出当前待处理的投递数量。这类交互上的差异化设计直接决定了系统的易用程度我在设计路由和页面结构时首先考虑的是这三条核心路径怎么最短到达。2. 数据库设计与核心表结构数据库设计决定了整个系统的天花板。我见过太多项目在表结构上偷懒导致后期写复杂查询时欲哭无泪。这个项目我设计了6张核心表用户表、企业信息表、兼职岗位表、投递记录表、收藏表、系统通知表。2.1 用户体系与角色设计的落地用户表不能只存登录账号和密码还要跟角色打通。我的做法是单表多角色一张用户表里加role字段区分身份而不分开建student表和company表。原因是学生后面可能注册企业账号企业人员也可能以个人身份使用平台分开建会在业务代码里反复做表关联徒增复杂度。CREATE TABLE user ( id bigint NOT NULL AUTO_INCREMENT, username varchar(50) NOT NULL COMMENT 登录用户名, password varchar(100) NOT NULL COMMENT 加密密码, role varchar(20) NOT NULL COMMENT STUDENT/COMPANY/ADMIN, phone varchar(20) DEFAULT NULL, email varchar(100) DEFAULT NULL, avatar varchar(200) DEFAULT NULL, status tinyint DEFAULT 1 COMMENT 1正常 0封禁, create_time datetime DEFAULT NULL, update_time datetime DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;密码加密用的是BCrypt不用MD5。MD5现在连加盐都救不了GPU算哈希太快了BCrypt自带盐并且单次计算慢暴力破解成本高到不可接受。用户表单人单角色那学生的简历信息、企业的资质信息怎么存简单做法是直接扩展一张student_profile和一张company_profile表跟user表外键关联用主表 扩展表的模式减少单表字段冗余。2.2 岗位与投递流程的状态机设计岗位表和投递记录表是整个业务的命脉。岗位表需要重点说明的是状态字段。岗位有一个审核状态和一个上下架状态二者合并后的状态流转是PENDING企业提交后等待管理员审核。APPROVED审核通过后默认上架学生可见。REJECTED审核未通过企业可以修改后重新提交。OFFLINE企业主动下架或者管理员强制下架。CLOSED报名截止或已招满。投递记录的状态流转是SUBMITTED学生投递简历成功。VIEWED企业已查看。INTERVIEWING企业觉得合适邀请沟通/面试。ACCEPTED录用。REJECTED拒绝。CANCELLED学生主动取消。这些状态在数据库里用varchar或tinyint存都可以我习惯用varchar存英文枚举值可读性好排查问题时一眼就能看懂当前记录处于什么阶段。这里有个容易被忽略的业务点岗位关闭后是否还允许投递不允许。但已经投递的记录不能因为岗位关闭就自动失效否则企业端就看不到候选人列表了。实现上投递接口里对这个状态做了校验如果是CLOSED或者OFFLINE直接抛业务异常当前岗位已停止招聘。2.3 报名表与岗位表的关键索引一个很常见的性能失误是岗位表和投递记录表建了外键但没有建有效索引。在数据量达到万级以后查询会明显变慢。我建了三个高频查询索引CREATE INDEX idx_job_status ON job(status, create_time); CREATE INDEX idx_apply_user ON application(user_id, create_time); CREATE INDEX idx_apply_job ON application(job_id, create_time);第一个索引支撑岗位列表按状态排序第二个支撑学生端我的投递列表第三个支撑企业端某岗位的投递列表。经验分享外键约束和索引不是一回事。早期项目里我也总习惯给所有关联字段加外键约束后来发现当业务里有状态机、有级联更新时外键反而会成为性能瓶颈和运维负担。建议保留外键关系应用层维护一致性数据库层面只建普通索引业务代码保证引用完整性。3. Spring Boot后端核心实现后端我用的版本是Spring Boot 2.7.xJDK 1.8兼容部署省心。核心依赖是Spring Web、MyBatis-Plus、MySQL驱动、JWT库用的是java-jwt轻量好用、Hutool工具类省了写大量工具方法的功夫。3.1 统一响应结构与全局异常处理后端接口设计的第一件事是定一个统一返回结构不然前后端联调时每个人的返回格式都不一样工作量直接翻倍。我的返回结构是{ code: 200, message: success, data: {} }对应的Java类是public class ResultT { private int code; private String message; private T data; // 静态工厂方法 success / error }配合全局异常处理器RestControllerAdvice把业务异常、参数校验异常、不明异常统一捕获返回同样的结构。写第三方接口时报错信息不能太裸要么不返回细节要么脱敏避免泄露SQL信息。全局异常处理还有一层作用把业务异常直接用抛异常打断流程变成可控的。比如投递时判断岗位不存在或者已关闭直接throw new BizException(当前岗位不存在或已停止招聘)异常处理器统一包装成Result返回代码里就不需要每层去写if else了。3.2 登录鉴权与JWT的工具封装JWT的核心逻辑其实不复杂登录成功后用用户的id和role生成Token设置7天过期时间返回给前端。前端每次请求带Token后端拦截器解析Token。生成Token的工具类我封装了这样几个方法public class JwtUtil { private static final String SECRET your-secret-key-change-in-production; private static final long EXPIRE_MS 7 * 24 * 3600 * 1000L; public static String createToken(Long userId, String role) { Algorithm alg Algorithm.HMAC256(SECRET); return JWT.create() .withClaim(userId, userId) .withClaim(role, role) .withExpiresAt(new Date(System.currentTimeMillis() EXPIRE_MS)) .sign(alg); } public static DecodedJWT verifyToken(String token) { return JWT.require(Algorithm.HMAC256(SECRET)).build().verify(token); } }JWT的最大缺点是签发后无法主动失效如果用户的账号被封禁了他手里的Token在过期前依然有效。所以我的拦截器里不止校验Token签名还会查数据库判断账号status是否为1如果被封禁就直接拦截。拦截器的实现是基于Spring的HandlerInterceptor注册进WebMvcConfigurer并且给登录、注册、首页岗位列表这几个公开接口配置白名单直接在注册拦截器时用excludePathPatterns排除掉。3.3 兼职岗位发布与投递的业务代码岗位发布接口的核心逻辑是校验企业信息完整性比如企业名称、联系人、联系电话是否已填组装岗位数据初始状态设为PENDING然后入库。投递接口的逻辑稍多一点先校验当前用户角色必须是学生这个由RequireRole注解兜住再校验岗位是否存在且状态为APPROVED然后查重如果这个学生对这个岗位已经投递过更新已有记录而不是插入新记录。这个查重逻辑非常关键否则用户狂点按钮就会产生大量重复投递。Override public Result applyJob(Long jobId, Long userId) { Job job jobMapper.selectById(jobId); if (job null || !APPROVED.equals(job.getStatus())) { throw new BizException(当前岗位不可投递); } Application existing applicationMapper.selectOne(new LambdaQueryWrapperApplication() .eq(Application::getJobId, jobId) .eq(Application::getUserId, userId)); if (existing ! null) { throw new BizException(你已投递过该岗位请勿重复操作); } Application app new Application(); app.setJobId(jobId); app.setUserId(userId); app.setStatus(SUBMITTED); applicationMapper.insert(app); // 异步通知企业用户有新投递 return Result.success(); }这里我故意没做事务因为投递逻辑本身只有一次插入不存在多表更新事务在这里意义不大。如果后续加投递后扣减岗位名额的逻辑那就要加Transactional保证两个操作同时成功或同时失败。3.4 文件上传处理简历/图片附件企业发布岗位时可以上传封面图学生投递时可以附件简历。最省事的方案是用Nginx直接代理静态目录后端把MultipartFile写到本地磁盘然后返回访问URL。生产环境建议上OSS但本地开发时用绝对路径写到项目外部的upload目录更稳妥不要写进项目目录否则打包部署文件会被覆盖。比较容易被忽略的是文件类型白名单校验、单文件大小限制和文件名重命名。我用UUID重命名保存避免中文文件名和路径注入问题String ext StringUtils.substringAfter(file.getOriginalFilename(), .); if (!allowedExtensions.contains(ext.toLowerCase())) { throw new BizException(不支持的文件类型); } String filename UUID.randomUUID().toString().replace(-, ) . ext; file.transferTo(new File(uploadDir filename));文件大小限制需要在application.yml里配spring: servlet: multipart: max-file-size: 10MB max-request-size: 10MB3.5 数据统计接口与SQL的取舍管理员端的数据统计我做了三个核心指标用户总数按角色分组统计、岗位总数按月统计趋势、投递总数。用MyBatis-Plus的聚合查询配合MySQL的日期函数来实现不用额外引入定时任务。比如统计近7天每天的岗位发布量ListMapString, Object list jobMapper.selectMaps(new QueryWrapperJob() .select(DATE(create_time) as date, count(*) as total) .ge(create_time, LocalDate.now().minusDays(7)) .groupBy(DATE(create_time)));这段SQL的结果直接用List返回给前端展示效率很高不额外建VO类。4. Vue 3前端实现与交互细节前端我选用的是Vue 3 TypeScript Element Plus Vite。Vite比Webpack快太多了开发期的热更新几乎是秒级这对调试联调阶段非常关键。Element Plus的组件库做后台管理界面效率也很高表单校验、表格分页、对话框这些基础能力开箱即用。4.1 前端工程结构与路由设计前端工程我按业务模块分目录而不是按组件类型分src/ api/ // axios请求封装按模块拆文件 assets/ components/ // 公共组件 router/ store/ // Pinia状态管理 views/ student/ // 学生端页面 company/ // 企业端页面 admin/ // 管理端页面 login/ // 登录注册页 common/ // 公共页面比如首页路由设计上用了动态路由的思路。核心思路是路由表先只注册白名单页面登录、注册、首页登录后根据用户的角色动态添加对应角色的路由。这样做有两个好处一是前端侧面对用户隐藏了无权限的页面二是配合后端的接口拦截形成双层防线。举个实际例子企业工作台的路径是/company/dashboard学生投递记录的路径是/student/applications。学生登录后前端路由表里根本没有/company/*这些记录他手动输入URL也只会被重定向到首页。4.2 封装Axios请求模块axios封装是整个前端代码里复用率最高的公共模块。我在src/api/request.ts里统一做了几件事带上JWT的请求头、拦截响应码、统一错误提示ElMessage、处理401跳转登录页、控制并发重复请求。const service axios.create({ baseURL: /api, timeout: 15000 }) service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] Bearer token } return config }) service.interceptors.response.use( response { const res response.data // 业务code非200说明后端处理失败 if (res.code ! 200) { ElMessage.error(res.message || 请求失败) return Promise.reject(new Error(res.message)) } return res }, error { if (error.response?.status 401) { // Token失效清除登录状态跳转登录页 localStorage.clear() router.push(/login) } ElMessage.error(error.message || 网络异常) return Promise.reject(error) } )这里有个小坑如果业务响应里的res本身就可能是二进制流或者非JSON格式比如导出Excel的接口统一处理时要做类型判断不能无脑走JSON解析。我遇到过一次导出报表接口返回的是文件流结果被axios的response拦截器强行解析成JSON直接抛错了。4.3 学生端页面岗位浏览与投递流程学生端核心页面是岗位列表页。左侧是岗位分类树兼职、实习、校园大使、家教等行业分类中间是关键筛选项薪资范围、工作地点、发布时间排序右侧是岗位卡片列表。这样学生三秒内就能完成按条件筛岗位—找到感兴趣—进入详情这条主路径。岗位详情页除了展示基本信息重点设计了投递简历按钮的交互点击前先判断用户是否登录登录后判断是否已投递。如果已投递按钮变成灰色不可点附文字已投递请等待企业回复。这个交互是前端读取接口返回的投递状态来判断的不是一个纯静态的状态所以简历列表和岗位详情页之间需要共享投递记录数据。我的做法是在Pinia里存一份当前用户的投递映射表投递成功后更新这个映射这样用户从岗位详情切到我的投递页面时数据时一致的不需要重新请求接口。4.4 企业端页面岗位管理和简历筛选企业端的核心工作量在岗位管理和简历筛选。岗位管理页是一张表格岗位标题、薪资、状态、发布时间、操作编辑/上下架/查看投递。状态字段在表格里用el-tag显示成不同颜色一眼就能看出哪些岗位在审核中、哪些正在招聘。查看投递背后对应的简历筛选页是重头戏一屏之内要展示候选人列表和简历详情。我用了Element Plus的抽屉组件el-drawer左侧是候选人姓名、投递时间、状态右侧是简历信息头像、学校、专业、联系方式、自我评价底部是操作区通过/拒绝/邀请面试。这个页面晚点儿说第二版再补充筛选候选人按钮第三版再加上在线沟通功能直接形成即时聊天跟学生沟通。这块也是一个能展示技术深度的扩展方向。4.5 前端权限控制与按钮级权限前面说动态路由已经完成页面级权限那按钮级权限怎么做简单场景下我在Pinia里存当前用户的角色常量然后写一个工具方法export function hasRole(role: string): boolean { const userStore useUserStore() return userStore.role role || userStore.role ADMIN }在模板里直接用v-ifhasRole(COMPANY)控制按钮显隐。这只解决展示层面的问题真正的权限判断还是要靠后端兜底。这里要提醒一下前端显示管理按钮只是因为他有超管权限后端如果接口没校验那按钮隐藏等于掩耳盗铃。所以前后端权限校验必须同时做但安全底线在后端。4.6 重要经验联调阶段的配置与调试前后端联调最大的坑就是跨域。开发环境下我在Vite的配置文件里配了代理server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true, rewrite: path path.replace(/^\/api/, ) } } }后端接口路径设计上我故意统一带/api前缀这样前端代理、Nginx转发都能一次性处理不用改代码。生产环境再让Nginx把/api开头的请求反向代理到Spring Boot的8080端口整个链路就通了。5. 数据安全与性能细节的工程实践这一部分内容看似琐碎但实际上决定了系统能不能稳定跑起来。很多项目demo里最明显的问题就是业务跑得通但接口随便调数据裸奔。5.1 接口参数校验怎么做Controller层参数校验不能偷懒。我用了Spring Boot内置的ValidatedNotBlank/Size注解做基础参数校验配合全局异常处理器里的MethodArgumentNotValidException分支把校验异常转成统一返回结构。实体类上示例public class JobDTO { NotBlank(message 岗位标题不能为空) Size(max 50, message 标题长度不能超过50个字符) private String title; NotNull(message 薪资不能为空) private Integer salary; NotBlank(message 岗位描述不能为空) private String description; }核心原则是前端校验只是提示后端校验才是防线。前端错误提示更友好后端校验兜底两个都做缺一不可。5.2 防止SQL注入和XSSMyBatis-Plus的LambdaQueryWrapper默认就是用预编译Statement参数不会被拼接进SQL字符串所以SQL注入风险天然低。但如果你习惯写原生Select注解或者XML一定要用#{}而不是${}拼接参数。这是我见过最多人踩的坑。XSS防护方面由于系统允许企业和学生填写自我介绍、岗位描述这类的富文本或普通文本字段不处理的话可以往里面注入script标签。我的处理方式是展示层统一转义Vue默认的Mustache语法就是转义输出不会执行如果用到v-html则必须对内容做白名单清洗。好在系统没有用富文本编辑器普通文本场景用v-text或插值表达式就够了不需要引入额外的XSS过滤库。5.3 关键查询的索引优化前期数据量小性能问题看不出来。到了几万条岗位、几十万条投递记录的时候没有索引的查询会让数据库CPU直接飙高。我建索引的逻辑在前面已经提过这里再补充一个更隐蔽的点apply_job查重和getMyApplications两个接口如果用户量很大投递记录的查询频率非常高所以索引覆盖的字段顺序很重要。idx_apply_user (user_id, create_time)的字段顺序不能反。先按user_id过滤出某个学生的所有投递记录再按create_time排序取分页这样B树可以一条索引全覆盖。如果顺序反了MySQL只能用user_id定位到一个范围内再文件排序性能差一倍以上。5.4 服务部署与应用配置部署架构走的是最简单可靠的Nginx Spring Boot Jar。前端Vue项目打包成静态文件交给Nginx托管后端打成可执行Jar包用systemd托管。Nginx同时承担静态资源服务和API反向代理两个职责server { listen 80; server_name your-domain; location /api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location / { root /opt/jobfrontend/dist; try_files $uri $uri/ /index.html; } }注意try_files $uri $uri/ /index.html这一行这行是Vue Router的history模式部署时必须要写的否则刷新某个子页面路由时会返回404。不写这行是毕设项目部署线上最常见的bug。5.5 服务器安全与账号权限服务器上不要用root直接跑Java进程。我之前在部署项目时习惯用root跑之后被安全通告提醒过MySQL端口裸奔的问题。建议创建一个专门的系统账号运行服务useradd -m -s /bin/bash appuser chown -R appuser:appuser /opt/jobbackend su - appuser -c java -jar /opt/jobbackend/job-system.jar同时配置安全组只开放80/443端口。MySQL的3306端口不要对外网开放需要本地连数据库时用SSH隧道。这些操作是线上服务的基本素养虽然在demo系统里不做也不会出大问题但一旦上线长期跑安全基线就很重要了。6. 常见问题排查与避坑实录这个项目开发过程中我踩了不少坑有些问题光看报错很难定位整理一份排查记录对后续维护很有价值。6.1 前端请求403Token失效还是角色权限不够403问题在联调阶段出现频率最高。先看Request Headers里的Authorization是否正确带上了Token。如果Token存在但还是403再看用户角色是否满足接口要求的角色。我遇到过这样一个情况企业用户在请求学生接口时报403排查了半天发现是企业账号在数据库中role字段是STUDENT登录态虽然正常但权限判断就出问题了。诊断技巧在后端拦截器里把解析到的userId和role用日志打印出来再跟请求的RequireRole注解比对基本能定位是Token解析问题还是角色不匹配问题。6.2 跨域问题加了CORS配置还是报错Spring Boot跨域配置有几种写法我推荐用WebMvcConfigurer统一配置而不是在每个类上加CrossOrigin注解Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); }两级问题上最坑的是preflight请求。前端POST请求带JSON和自定义头时浏览器会先发一个OPTIONS请求如果后端没处理后面所有请求都会卡在预检阶段。Spring MVC的CORS配置里默认加了OPTIONS处理但如果你在拦截器配置里把OPTIONS请求也拦了预检请求会死在拦截器里返回403这个优先级问题容易让人懵。最佳实践是拦截器注册时对OPTIONS方法直接放行同时把接口路径的统一前缀/api/**纳入CORS配置范围两边一致就不会互相干扰。6.3 本地环境正常线上环境页面白屏前端页面白屏基本可以断定是静态资源路径错误。如果Vite打包后访问页面完全空白大概率是base配置不对。默认的base是/如果你的站点是部署在域名根路径就没问题如果部署在子路径下就得改成相对路径或完整路径// vite.config.ts export default defineConfig({ base: /jobsystem/, // ... })还有种情况是后端接口能通但页面数据渲染不出来这个时候按F12看Network的API返回如果返回的是HTML而不是JSON多半是Nginx反代没生效把动态请求转发到了前端静态文件上。6.4 数据库连接池报Too many connections开发阶段用户很少但如果连接池没有配置上限某个循环代码或接口并发过大时就会打爆MySQL的默认连接数。我的解决方案是spring: datasource: hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 30000同时排查代码里有没有在for循环里执行数据库操作。比如批量导入岗位时如果for循环里一条条insert1000条岗位就是1000次数据库往返直接把连接池打满。正确做法是用MyBatis-Plus的saveBatch批量插入。6.5 表格分页数据异常前端页码从0开始还是1开始这是一个非常经典的联调翻车点。Element Plus的el-pagination组件页码默认从1开始但有的后端分页插件默认pageNum从0开始。两边对不上时第二页的数据跟第一页重复或者最后一页数据永远显示不出来。我的约定是后端分页参数page pageNum - 1MyBatis-Plus的Page默认从1开始前端直接传当前页给后端统一语义只要前端传给后端的page值从1开始、后端内部转换为offset计算就行。这个约定要在接口文档里写清楚避免联调时反复确认。6.6 一次生产环境的小事故忘改JWT密钥开发环境里我把SECRET写死在代码里上线第一周一切正常。后来在一次安全测试中发现如果有人拿到源码就能根据相同密钥伪造Token直接以管理员身份调用接口。这个不算是bug但暴露了一个问题JWT的密钥绝不能硬编码在代码里。把它放到环境变量或者配置中心示例代码如下private static final String SECRET System.getenv(JWT_SECRET);上线前要检查的站点配置清单包括JWT密钥、数据库密码、文件上传目录权限、部署用户权限。这几个点都是生产事故高发区上生产环境前要挨个确认。7. 项目扩展方向与个人心得前面讲了一大堆实现细节最后一个部分把视角放远一点聊聊这个项目的扩展空间。任何系统只要你思路清晰成长空间都很大。如果把单机MySQL扛不住了可以做分库分表如果岗位数据量大到需要全文检索可以接入Elasticsearch做岗位搜索如果需要支撑大规模学生和企业的沟通可以引入WebSocket做在线会话如果要把简历处理自动化可以对接大模型做简历初筛和岗位匹配评分。这些都是非常有业务价值并且技术含金量足够的扩展方向。一个相对容易落地的扩展是缓存。当前系统里面高频读的岗位列表完全可以用Redis做缓存。架构上只需要加一层CacheAside模式读操作先查缓存缓存没有查数据库再回填写操作先更新数据库再删除缓存。注意写出顺序不能先删缓存再更新数据库否则并发下可能出现缓存击穿导致脏数据。这个知识点面试必问项目中做了也确实是真实高价值需求。再一个角度是消息通知。学生在岗位投递、企业反馈时系统应该有消息提醒。第二版可以引入WebSocket推送实时通知或者用定时任务扫描数据库推送邮件提醒。我当前的版本里通知表已经建好了但推送逻辑还没有完全接入后续做增量迭代时这里是一项核心工作。最后说点我对这类项目本身的理解。做了这么多年的全栈开发我的一个很深的感触是一个项目能不能打动人比技术栈新不新重要得多。Spring Boot Vue这套组合拳也许不是最潮的技术但它是能稳定落地、人才供给充足、生态完善的选择。当初接手这类项目时低估了一些隐性成本比如角色权限体系的设计和前后端联调的复杂度但一路做下来收获确实很大。如果你也在做一个类似的全栈项目我的建议是先把业务状态机画清楚再定数据库表结构然后写后端接口最后做前端页面。按这个顺序走开发过程会顺畅很多。千万不要一上来就写前端代码不然后期接口一变半天时间就砸在返工上了。最后分享一个小技巧也是我平时一定会做的写完一个新模块后自己先拿Postman把接口全走一遍再打开前端页面手动操作一遍两边都通了再提交。这个习惯帮我挡掉了大量的低级bug。项目做完回头看最有价值的不是某个奇技淫巧而是那套完整走通了的流程和避坑经验。希望这篇整理能帮你少走一些弯路少熬几个晚上。
1. 项目缘起与整体设计思路收到过不少类似Spring Boot Vue做学生兼职系统的选题说实话这类项目在网上已经不算新鲜了但大多数repo代码质量堪忧要么只是把CRUD堆在一起要么前后端完全割裂看不出业务闭环。我这次梳理的是一个完整的、能真正跑起来的学生兼职管理系统覆盖了从学生端找兼职、投递简历到企业端发布岗位、审核简历再到管理员端做数据统计和用户审核的完整闭环。先说这个项目到底解决了什么问题。传统校园兼职信息基本靠QQ群、贴吧或者校园公告栏信息分散、真假难辨、结算纠纷时有发生。一个线上化、带审核机制、有流程记录的兼职管理系统至少能把信息发布—报名投递—企业筛选—录用反馈这条链路管理起来同时给学生、企业、校方三方一个相对清晰的角色划分。对于学生来说是找兼职的统一入口对于企业来说是低成本发布岗位的渠道对于管理员来说是把控信息质量和数据留痕的手段。这个系统的技术分层很明确前端用Vue我用的是Vue 3加Element Plus后面会解释为什么不用Vue 2后端用Spring Boot。前后端通过RESTful API交互JWT做身份认证MySQL存业务数据。整个架构不复杂但很适合教学、毕设、以及中小型校园信息化项目的扩展基线。你完全可以在这套骨架上加ES做全文检索加Redis扛并发或者把文件服务切到OSS扩展路径都是顺的。我当时选择这套技术栈的逻辑其实很朴素Spring Boot的生态太成熟了跟数据库打交道用MyBatis-Plus几乎不用写XMLVue 3的组合式API配Element Plus做后台管理界面的效率非常高。更重要的是这套栈学完之后你不是只会写这一个项目而是能顺着它理解前后端分离开发的通用套路这是它的隐性价值。1.1 核心需求拆解不管是做毕设还是接真实项目第一步一定是把需求拆干净。我当时把整个系统拆成了三个端学生端注册登录、浏览岗位、按分类/关键词筛选、投递简历、查看投递状态、收藏岗位、管理个人信息和简历。企业端注册登录、发布兼职岗位、维护岗位上下架、查看投递列表、筛选/通过/拒绝候选人、处理学生简历。管理员端用户管理审核企业资质、封禁异常账号、岗位审核控制劣质信息流入、数据统计岗位数量、用户增长、投递转化等基础指标。有些项目还会加结算管理模块让企业发布完工后对学生进行工资确认学校可以介入监管。如果时间够这确实是个很好的加分项。我这次的核心版本里保留了岗位管理、投递流程、用户体系和基础统计结算部分留了扩展口。需求拆到这里基本可以确认一件事这绝不是单纯的管理系统而是一个多角色、多状态流转的平台型业务。这也是它跟一般图书管理系统类项目的本质区别——状态多权限多业务逻辑重。1.2 角色权限模型的设计取舍角色权限是这类系统最容易翻车的地方。我建议不要一上来就上Spring Security OAuth2那种重型权限框架学生兼职系统的主流访问量撑不起那么复杂的权限设计反而会把自己绕晕。我选择的是JWT 拦截器 自定义注解的方式轻量且够用。具体设计是登录成功后后端签发JWTJWT中携带userId和role字段。前端拿到Token后存到localStorage每次请求在请求头里带上。后端写一个拦截器拦截所有需要登录的接口解析Token并校验角色。角色分三种STUDENT、COMPANY、ADMIN。在Controller的方法上用自定义注解标注允许访问的角色比如RequireRole(Role.STUDENT) GetMapping(/my/applications) public Result getMyApplications() { ... }拦截器里用反射判断当前handler方法上有哪些RequireRole注解如果当前用户的角色不在允许列表里直接返回403。这个方案的好处是权限逻辑集中但入口分散每写一个接口在方法上用一行注解就能声明谁能访问后期维护成本极低。注意不要把权限校验全放在前端。前端隐藏按钮只是用户体验层面的事真正的安全边界必须由后端兜底。实际项目中我遇到过只在前端做了管理员菜单隐藏、后端接口裸奔的案例被用户直接调接口删了数据千万不要重蹈覆辙。1.3 页面和交互流程的梳理这三个角色对应的前端页面差异比较大但可以抽象出几套通用页面模式列表搜索页岗位列表页—— 筛选器 表格 分页表单页发布岗位、编辑简历—— 表单 校验 提交详情页岗位详情、用户详情—— 信息展示 操作按钮学生端的核心路径是找兼职—看详情—投简历—查进度所以首页最重要的是搜索和分类入口岗位详情页要突出投递按钮和岗位关键信息薪资、时间、地点。企业端是发岗位—收简历—处理简历所以工作台要突出当前待处理的投递数量。这类交互上的差异化设计直接决定了系统的易用程度我在设计路由和页面结构时首先考虑的是这三条核心路径怎么最短到达。2. 数据库设计与核心表结构数据库设计决定了整个系统的天花板。我见过太多项目在表结构上偷懒导致后期写复杂查询时欲哭无泪。这个项目我设计了6张核心表用户表、企业信息表、兼职岗位表、投递记录表、收藏表、系统通知表。2.1 用户体系与角色设计的落地用户表不能只存登录账号和密码还要跟角色打通。我的做法是单表多角色一张用户表里加role字段区分身份而不分开建student表和company表。原因是学生后面可能注册企业账号企业人员也可能以个人身份使用平台分开建会在业务代码里反复做表关联徒增复杂度。CREATE TABLE user ( id bigint NOT NULL AUTO_INCREMENT, username varchar(50) NOT NULL COMMENT 登录用户名, password varchar(100) NOT NULL COMMENT 加密密码, role varchar(20) NOT NULL COMMENT STUDENT/COMPANY/ADMIN, phone varchar(20) DEFAULT NULL, email varchar(100) DEFAULT NULL, avatar varchar(200) DEFAULT NULL, status tinyint DEFAULT 1 COMMENT 1正常 0封禁, create_time datetime DEFAULT NULL, update_time datetime DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;密码加密用的是BCrypt不用MD5。MD5现在连加盐都救不了GPU算哈希太快了BCrypt自带盐并且单次计算慢暴力破解成本高到不可接受。用户表单人单角色那学生的简历信息、企业的资质信息怎么存简单做法是直接扩展一张student_profile和一张company_profile表跟user表外键关联用主表 扩展表的模式减少单表字段冗余。2.2 岗位与投递流程的状态机设计岗位表和投递记录表是整个业务的命脉。岗位表需要重点说明的是状态字段。岗位有一个审核状态和一个上下架状态二者合并后的状态流转是PENDING企业提交后等待管理员审核。APPROVED审核通过后默认上架学生可见。REJECTED审核未通过企业可以修改后重新提交。OFFLINE企业主动下架或者管理员强制下架。CLOSED报名截止或已招满。投递记录的状态流转是SUBMITTED学生投递简历成功。VIEWED企业已查看。INTERVIEWING企业觉得合适邀请沟通/面试。ACCEPTED录用。REJECTED拒绝。CANCELLED学生主动取消。这些状态在数据库里用varchar或tinyint存都可以我习惯用varchar存英文枚举值可读性好排查问题时一眼就能看懂当前记录处于什么阶段。这里有个容易被忽略的业务点岗位关闭后是否还允许投递不允许。但已经投递的记录不能因为岗位关闭就自动失效否则企业端就看不到候选人列表了。实现上投递接口里对这个状态做了校验如果是CLOSED或者OFFLINE直接抛业务异常当前岗位已停止招聘。2.3 报名表与岗位表的关键索引一个很常见的性能失误是岗位表和投递记录表建了外键但没有建有效索引。在数据量达到万级以后查询会明显变慢。我建了三个高频查询索引CREATE INDEX idx_job_status ON job(status, create_time); CREATE INDEX idx_apply_user ON application(user_id, create_time); CREATE INDEX idx_apply_job ON application(job_id, create_time);第一个索引支撑岗位列表按状态排序第二个支撑学生端我的投递列表第三个支撑企业端某岗位的投递列表。经验分享外键约束和索引不是一回事。早期项目里我也总习惯给所有关联字段加外键约束后来发现当业务里有状态机、有级联更新时外键反而会成为性能瓶颈和运维负担。建议保留外键关系应用层维护一致性数据库层面只建普通索引业务代码保证引用完整性。3. Spring Boot后端核心实现后端我用的版本是Spring Boot 2.7.xJDK 1.8兼容部署省心。核心依赖是Spring Web、MyBatis-Plus、MySQL驱动、JWT库用的是java-jwt轻量好用、Hutool工具类省了写大量工具方法的功夫。3.1 统一响应结构与全局异常处理后端接口设计的第一件事是定一个统一返回结构不然前后端联调时每个人的返回格式都不一样工作量直接翻倍。我的返回结构是{ code: 200, message: success, data: {} }对应的Java类是public class ResultT { private int code; private String message; private T data; // 静态工厂方法 success / error }配合全局异常处理器RestControllerAdvice把业务异常、参数校验异常、不明异常统一捕获返回同样的结构。写第三方接口时报错信息不能太裸要么不返回细节要么脱敏避免泄露SQL信息。全局异常处理还有一层作用把业务异常直接用抛异常打断流程变成可控的。比如投递时判断岗位不存在或者已关闭直接throw new BizException(当前岗位不存在或已停止招聘)异常处理器统一包装成Result返回代码里就不需要每层去写if else了。3.2 登录鉴权与JWT的工具封装JWT的核心逻辑其实不复杂登录成功后用用户的id和role生成Token设置7天过期时间返回给前端。前端每次请求带Token后端拦截器解析Token。生成Token的工具类我封装了这样几个方法public class JwtUtil { private static final String SECRET your-secret-key-change-in-production; private static final long EXPIRE_MS 7 * 24 * 3600 * 1000L; public static String createToken(Long userId, String role) { Algorithm alg Algorithm.HMAC256(SECRET); return JWT.create() .withClaim(userId, userId) .withClaim(role, role) .withExpiresAt(new Date(System.currentTimeMillis() EXPIRE_MS)) .sign(alg); } public static DecodedJWT verifyToken(String token) { return JWT.require(Algorithm.HMAC256(SECRET)).build().verify(token); } }JWT的最大缺点是签发后无法主动失效如果用户的账号被封禁了他手里的Token在过期前依然有效。所以我的拦截器里不止校验Token签名还会查数据库判断账号status是否为1如果被封禁就直接拦截。拦截器的实现是基于Spring的HandlerInterceptor注册进WebMvcConfigurer并且给登录、注册、首页岗位列表这几个公开接口配置白名单直接在注册拦截器时用excludePathPatterns排除掉。3.3 兼职岗位发布与投递的业务代码岗位发布接口的核心逻辑是校验企业信息完整性比如企业名称、联系人、联系电话是否已填组装岗位数据初始状态设为PENDING然后入库。投递接口的逻辑稍多一点先校验当前用户角色必须是学生这个由RequireRole注解兜住再校验岗位是否存在且状态为APPROVED然后查重如果这个学生对这个岗位已经投递过更新已有记录而不是插入新记录。这个查重逻辑非常关键否则用户狂点按钮就会产生大量重复投递。Override public Result applyJob(Long jobId, Long userId) { Job job jobMapper.selectById(jobId); if (job null || !APPROVED.equals(job.getStatus())) { throw new BizException(当前岗位不可投递); } Application existing applicationMapper.selectOne(new LambdaQueryWrapperApplication() .eq(Application::getJobId, jobId) .eq(Application::getUserId, userId)); if (existing ! null) { throw new BizException(你已投递过该岗位请勿重复操作); } Application app new Application(); app.setJobId(jobId); app.setUserId(userId); app.setStatus(SUBMITTED); applicationMapper.insert(app); // 异步通知企业用户有新投递 return Result.success(); }这里我故意没做事务因为投递逻辑本身只有一次插入不存在多表更新事务在这里意义不大。如果后续加投递后扣减岗位名额的逻辑那就要加Transactional保证两个操作同时成功或同时失败。3.4 文件上传处理简历/图片附件企业发布岗位时可以上传封面图学生投递时可以附件简历。最省事的方案是用Nginx直接代理静态目录后端把MultipartFile写到本地磁盘然后返回访问URL。生产环境建议上OSS但本地开发时用绝对路径写到项目外部的upload目录更稳妥不要写进项目目录否则打包部署文件会被覆盖。比较容易被忽略的是文件类型白名单校验、单文件大小限制和文件名重命名。我用UUID重命名保存避免中文文件名和路径注入问题String ext StringUtils.substringAfter(file.getOriginalFilename(), .); if (!allowedExtensions.contains(ext.toLowerCase())) { throw new BizException(不支持的文件类型); } String filename UUID.randomUUID().toString().replace(-, ) . ext; file.transferTo(new File(uploadDir filename));文件大小限制需要在application.yml里配spring: servlet: multipart: max-file-size: 10MB max-request-size: 10MB3.5 数据统计接口与SQL的取舍管理员端的数据统计我做了三个核心指标用户总数按角色分组统计、岗位总数按月统计趋势、投递总数。用MyBatis-Plus的聚合查询配合MySQL的日期函数来实现不用额外引入定时任务。比如统计近7天每天的岗位发布量ListMapString, Object list jobMapper.selectMaps(new QueryWrapperJob() .select(DATE(create_time) as date, count(*) as total) .ge(create_time, LocalDate.now().minusDays(7)) .groupBy(DATE(create_time)));这段SQL的结果直接用List返回给前端展示效率很高不额外建VO类。4. Vue 3前端实现与交互细节前端我选用的是Vue 3 TypeScript Element Plus Vite。Vite比Webpack快太多了开发期的热更新几乎是秒级这对调试联调阶段非常关键。Element Plus的组件库做后台管理界面效率也很高表单校验、表格分页、对话框这些基础能力开箱即用。4.1 前端工程结构与路由设计前端工程我按业务模块分目录而不是按组件类型分src/ api/ // axios请求封装按模块拆文件 assets/ components/ // 公共组件 router/ store/ // Pinia状态管理 views/ student/ // 学生端页面 company/ // 企业端页面 admin/ // 管理端页面 login/ // 登录注册页 common/ // 公共页面比如首页路由设计上用了动态路由的思路。核心思路是路由表先只注册白名单页面登录、注册、首页登录后根据用户的角色动态添加对应角色的路由。这样做有两个好处一是前端侧面对用户隐藏了无权限的页面二是配合后端的接口拦截形成双层防线。举个实际例子企业工作台的路径是/company/dashboard学生投递记录的路径是/student/applications。学生登录后前端路由表里根本没有/company/*这些记录他手动输入URL也只会被重定向到首页。4.2 封装Axios请求模块axios封装是整个前端代码里复用率最高的公共模块。我在src/api/request.ts里统一做了几件事带上JWT的请求头、拦截响应码、统一错误提示ElMessage、处理401跳转登录页、控制并发重复请求。const service axios.create({ baseURL: /api, timeout: 15000 }) service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] Bearer token } return config }) service.interceptors.response.use( response { const res response.data // 业务code非200说明后端处理失败 if (res.code ! 200) { ElMessage.error(res.message || 请求失败) return Promise.reject(new Error(res.message)) } return res }, error { if (error.response?.status 401) { // Token失效清除登录状态跳转登录页 localStorage.clear() router.push(/login) } ElMessage.error(error.message || 网络异常) return Promise.reject(error) } )这里有个小坑如果业务响应里的res本身就可能是二进制流或者非JSON格式比如导出Excel的接口统一处理时要做类型判断不能无脑走JSON解析。我遇到过一次导出报表接口返回的是文件流结果被axios的response拦截器强行解析成JSON直接抛错了。4.3 学生端页面岗位浏览与投递流程学生端核心页面是岗位列表页。左侧是岗位分类树兼职、实习、校园大使、家教等行业分类中间是关键筛选项薪资范围、工作地点、发布时间排序右侧是岗位卡片列表。这样学生三秒内就能完成按条件筛岗位—找到感兴趣—进入详情这条主路径。岗位详情页除了展示基本信息重点设计了投递简历按钮的交互点击前先判断用户是否登录登录后判断是否已投递。如果已投递按钮变成灰色不可点附文字已投递请等待企业回复。这个交互是前端读取接口返回的投递状态来判断的不是一个纯静态的状态所以简历列表和岗位详情页之间需要共享投递记录数据。我的做法是在Pinia里存一份当前用户的投递映射表投递成功后更新这个映射这样用户从岗位详情切到我的投递页面时数据时一致的不需要重新请求接口。4.4 企业端页面岗位管理和简历筛选企业端的核心工作量在岗位管理和简历筛选。岗位管理页是一张表格岗位标题、薪资、状态、发布时间、操作编辑/上下架/查看投递。状态字段在表格里用el-tag显示成不同颜色一眼就能看出哪些岗位在审核中、哪些正在招聘。查看投递背后对应的简历筛选页是重头戏一屏之内要展示候选人列表和简历详情。我用了Element Plus的抽屉组件el-drawer左侧是候选人姓名、投递时间、状态右侧是简历信息头像、学校、专业、联系方式、自我评价底部是操作区通过/拒绝/邀请面试。这个页面晚点儿说第二版再补充筛选候选人按钮第三版再加上在线沟通功能直接形成即时聊天跟学生沟通。这块也是一个能展示技术深度的扩展方向。4.5 前端权限控制与按钮级权限前面说动态路由已经完成页面级权限那按钮级权限怎么做简单场景下我在Pinia里存当前用户的角色常量然后写一个工具方法export function hasRole(role: string): boolean { const userStore useUserStore() return userStore.role role || userStore.role ADMIN }在模板里直接用v-ifhasRole(COMPANY)控制按钮显隐。这只解决展示层面的问题真正的权限判断还是要靠后端兜底。这里要提醒一下前端显示管理按钮只是因为他有超管权限后端如果接口没校验那按钮隐藏等于掩耳盗铃。所以前后端权限校验必须同时做但安全底线在后端。4.6 重要经验联调阶段的配置与调试前后端联调最大的坑就是跨域。开发环境下我在Vite的配置文件里配了代理server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true, rewrite: path path.replace(/^\/api/, ) } } }后端接口路径设计上我故意统一带/api前缀这样前端代理、Nginx转发都能一次性处理不用改代码。生产环境再让Nginx把/api开头的请求反向代理到Spring Boot的8080端口整个链路就通了。5. 数据安全与性能细节的工程实践这一部分内容看似琐碎但实际上决定了系统能不能稳定跑起来。很多项目demo里最明显的问题就是业务跑得通但接口随便调数据裸奔。5.1 接口参数校验怎么做Controller层参数校验不能偷懒。我用了Spring Boot内置的ValidatedNotBlank/Size注解做基础参数校验配合全局异常处理器里的MethodArgumentNotValidException分支把校验异常转成统一返回结构。实体类上示例public class JobDTO { NotBlank(message 岗位标题不能为空) Size(max 50, message 标题长度不能超过50个字符) private String title; NotNull(message 薪资不能为空) private Integer salary; NotBlank(message 岗位描述不能为空) private String description; }核心原则是前端校验只是提示后端校验才是防线。前端错误提示更友好后端校验兜底两个都做缺一不可。5.2 防止SQL注入和XSSMyBatis-Plus的LambdaQueryWrapper默认就是用预编译Statement参数不会被拼接进SQL字符串所以SQL注入风险天然低。但如果你习惯写原生Select注解或者XML一定要用#{}而不是${}拼接参数。这是我见过最多人踩的坑。XSS防护方面由于系统允许企业和学生填写自我介绍、岗位描述这类的富文本或普通文本字段不处理的话可以往里面注入script标签。我的处理方式是展示层统一转义Vue默认的Mustache语法就是转义输出不会执行如果用到v-html则必须对内容做白名单清洗。好在系统没有用富文本编辑器普通文本场景用v-text或插值表达式就够了不需要引入额外的XSS过滤库。5.3 关键查询的索引优化前期数据量小性能问题看不出来。到了几万条岗位、几十万条投递记录的时候没有索引的查询会让数据库CPU直接飙高。我建索引的逻辑在前面已经提过这里再补充一个更隐蔽的点apply_job查重和getMyApplications两个接口如果用户量很大投递记录的查询频率非常高所以索引覆盖的字段顺序很重要。idx_apply_user (user_id, create_time)的字段顺序不能反。先按user_id过滤出某个学生的所有投递记录再按create_time排序取分页这样B树可以一条索引全覆盖。如果顺序反了MySQL只能用user_id定位到一个范围内再文件排序性能差一倍以上。5.4 服务部署与应用配置部署架构走的是最简单可靠的Nginx Spring Boot Jar。前端Vue项目打包成静态文件交给Nginx托管后端打成可执行Jar包用systemd托管。Nginx同时承担静态资源服务和API反向代理两个职责server { listen 80; server_name your-domain; location /api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location / { root /opt/jobfrontend/dist; try_files $uri $uri/ /index.html; } }注意try_files $uri $uri/ /index.html这一行这行是Vue Router的history模式部署时必须要写的否则刷新某个子页面路由时会返回404。不写这行是毕设项目部署线上最常见的bug。5.5 服务器安全与账号权限服务器上不要用root直接跑Java进程。我之前在部署项目时习惯用root跑之后被安全通告提醒过MySQL端口裸奔的问题。建议创建一个专门的系统账号运行服务useradd -m -s /bin/bash appuser chown -R appuser:appuser /opt/jobbackend su - appuser -c java -jar /opt/jobbackend/job-system.jar同时配置安全组只开放80/443端口。MySQL的3306端口不要对外网开放需要本地连数据库时用SSH隧道。这些操作是线上服务的基本素养虽然在demo系统里不做也不会出大问题但一旦上线长期跑安全基线就很重要了。6. 常见问题排查与避坑实录这个项目开发过程中我踩了不少坑有些问题光看报错很难定位整理一份排查记录对后续维护很有价值。6.1 前端请求403Token失效还是角色权限不够403问题在联调阶段出现频率最高。先看Request Headers里的Authorization是否正确带上了Token。如果Token存在但还是403再看用户角色是否满足接口要求的角色。我遇到过这样一个情况企业用户在请求学生接口时报403排查了半天发现是企业账号在数据库中role字段是STUDENT登录态虽然正常但权限判断就出问题了。诊断技巧在后端拦截器里把解析到的userId和role用日志打印出来再跟请求的RequireRole注解比对基本能定位是Token解析问题还是角色不匹配问题。6.2 跨域问题加了CORS配置还是报错Spring Boot跨域配置有几种写法我推荐用WebMvcConfigurer统一配置而不是在每个类上加CrossOrigin注解Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); }两级问题上最坑的是preflight请求。前端POST请求带JSON和自定义头时浏览器会先发一个OPTIONS请求如果后端没处理后面所有请求都会卡在预检阶段。Spring MVC的CORS配置里默认加了OPTIONS处理但如果你在拦截器配置里把OPTIONS请求也拦了预检请求会死在拦截器里返回403这个优先级问题容易让人懵。最佳实践是拦截器注册时对OPTIONS方法直接放行同时把接口路径的统一前缀/api/**纳入CORS配置范围两边一致就不会互相干扰。6.3 本地环境正常线上环境页面白屏前端页面白屏基本可以断定是静态资源路径错误。如果Vite打包后访问页面完全空白大概率是base配置不对。默认的base是/如果你的站点是部署在域名根路径就没问题如果部署在子路径下就得改成相对路径或完整路径// vite.config.ts export default defineConfig({ base: /jobsystem/, // ... })还有种情况是后端接口能通但页面数据渲染不出来这个时候按F12看Network的API返回如果返回的是HTML而不是JSON多半是Nginx反代没生效把动态请求转发到了前端静态文件上。6.4 数据库连接池报Too many connections开发阶段用户很少但如果连接池没有配置上限某个循环代码或接口并发过大时就会打爆MySQL的默认连接数。我的解决方案是spring: datasource: hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 30000同时排查代码里有没有在for循环里执行数据库操作。比如批量导入岗位时如果for循环里一条条insert1000条岗位就是1000次数据库往返直接把连接池打满。正确做法是用MyBatis-Plus的saveBatch批量插入。6.5 表格分页数据异常前端页码从0开始还是1开始这是一个非常经典的联调翻车点。Element Plus的el-pagination组件页码默认从1开始但有的后端分页插件默认pageNum从0开始。两边对不上时第二页的数据跟第一页重复或者最后一页数据永远显示不出来。我的约定是后端分页参数page pageNum - 1MyBatis-Plus的Page默认从1开始前端直接传当前页给后端统一语义只要前端传给后端的page值从1开始、后端内部转换为offset计算就行。这个约定要在接口文档里写清楚避免联调时反复确认。6.6 一次生产环境的小事故忘改JWT密钥开发环境里我把SECRET写死在代码里上线第一周一切正常。后来在一次安全测试中发现如果有人拿到源码就能根据相同密钥伪造Token直接以管理员身份调用接口。这个不算是bug但暴露了一个问题JWT的密钥绝不能硬编码在代码里。把它放到环境变量或者配置中心示例代码如下private static final String SECRET System.getenv(JWT_SECRET);上线前要检查的站点配置清单包括JWT密钥、数据库密码、文件上传目录权限、部署用户权限。这几个点都是生产事故高发区上生产环境前要挨个确认。7. 项目扩展方向与个人心得前面讲了一大堆实现细节最后一个部分把视角放远一点聊聊这个项目的扩展空间。任何系统只要你思路清晰成长空间都很大。如果把单机MySQL扛不住了可以做分库分表如果岗位数据量大到需要全文检索可以接入Elasticsearch做岗位搜索如果需要支撑大规模学生和企业的沟通可以引入WebSocket做在线会话如果要把简历处理自动化可以对接大模型做简历初筛和岗位匹配评分。这些都是非常有业务价值并且技术含金量足够的扩展方向。一个相对容易落地的扩展是缓存。当前系统里面高频读的岗位列表完全可以用Redis做缓存。架构上只需要加一层CacheAside模式读操作先查缓存缓存没有查数据库再回填写操作先更新数据库再删除缓存。注意写出顺序不能先删缓存再更新数据库否则并发下可能出现缓存击穿导致脏数据。这个知识点面试必问项目中做了也确实是真实高价值需求。再一个角度是消息通知。学生在岗位投递、企业反馈时系统应该有消息提醒。第二版可以引入WebSocket推送实时通知或者用定时任务扫描数据库推送邮件提醒。我当前的版本里通知表已经建好了但推送逻辑还没有完全接入后续做增量迭代时这里是一项核心工作。最后说点我对这类项目本身的理解。做了这么多年的全栈开发我的一个很深的感触是一个项目能不能打动人比技术栈新不新重要得多。Spring Boot Vue这套组合拳也许不是最潮的技术但它是能稳定落地、人才供给充足、生态完善的选择。当初接手这类项目时低估了一些隐性成本比如角色权限体系的设计和前后端联调的复杂度但一路做下来收获确实很大。如果你也在做一个类似的全栈项目我的建议是先把业务状态机画清楚再定数据库表结构然后写后端接口最后做前端页面。按这个顺序走开发过程会顺畅很多。千万不要一上来就写前端代码不然后期接口一变半天时间就砸在返工上了。最后分享一个小技巧也是我平时一定会做的写完一个新模块后自己先拿Postman把接口全走一遍再打开前端页面手动操作一遍两边都通了再提交。这个习惯帮我挡掉了大量的低级bug。项目做完回头看最有价值的不是某个奇技淫巧而是那套完整走通了的流程和避坑经验。希望这篇整理能帮你少走一些弯路少熬几个晚上。
