简介：一套基于微信小程序与SSM（可升级Spring Boot）架构的求职招聘系统完整设计源码，覆盖求职者、商户和管理员三类角色，适用于毕业设计、课程设计及Java全栈学习；小程序端支持微信授权登录、完善资料、兼职分类浏览与预约面试，商户端通过学校认证后即可发布岗位、接收面试请求，管理后台则负责信息审核与客服答疑。系统还包含双方互评与评分机制，帮助优秀商户和同学获得更多曝光。资源包共1207个文件，压缩后大小4.07MB，文件类型以HTML、JavaScript、CSS、JSP、Java为主，另有WXML/WXSS小程序页面、JSON配置、SQL数据库脚本及图片素材，目录结构清晰，便于直接导入开发工具运行调试。目前已有218人学习下载，适合需要快速搭建同类型项目的开发者参考。通过该项目可掌握前后端联调、多角色权限控制、数据库表设计等关键技能，附带的静态资源也有利于二次开发与界面定制。 做求职招聘类微信小程序后端，很多人一开始就在SSM和SpringBoot之间反复纠结。我早几年经手过一个真实的求职招聘系统项目，需求方明确要求用SSM交付，同时又提了个附加条件：架构上必须预留升级到SpringBoot的空间。当时这套基于SSM、可平滑升级SpringBoot的后端设计，后来帮我省掉了大量重构的成本。今天我就把完整的架构思路、数据模型、接口设计、升级路径和踩坑记录一次性讲清楚。这篇文章更适合两类人看：一类是在做求职招聘小程序毕业设计或中小型项目的同学，另一类是手里压着老SSM项目、想找一条平稳迁移到SpringBoot路线的后端开发。
1. 项目整体架构与技术选型思路
1.1 为什么先SSM而不是直接上SpringBoot
SSM是Spring MVC、Spring、MyBatis三件套的简称，也是过去十年Java后端最主流的组合。它稳定、资料多、面试常考，到现在还有大量企业项目、外包项目和高校课程在用。SpringBoot的核心优势则是自动配置、内嵌容器、约定大于配置，开发效率比传统SSM高不少。很多人就会有疑问：既然SpringBoot更好，为什么不直接一步到位？
这里要分清场景。如果这是一个完全没有历史包袱的新项目，我确实建议直接用SpringBoot，没必要绕路。但当时的实际情况是：团队里有人对SSM更熟悉，部署环境对独立Tomcat和war包有依赖，客户也明确要求课程方案建立在SSM上。更关键的是，SpringBoot底层并没有脱离Spring和SpringMVC，而是把它们包得更“傻瓜化”了。所以只要SSM项目代码分层清晰、依赖不混乱，升级到SpringBoot本质上是配置层的迁移，不需要推翻业务代码。
我自己的判断标准很简单：老项目改造成本高、团队技能栈固定、客户环境受限，先SSM后SpringBoot完全合理；反过来，新项目、小团队、想快速迭代，直接SpringBoot才是性价比最高的选择。两者不是对立关系，而是同一套Spring技术体系在不同阶段的产物。
1.2 后端分层与模块边界怎么划
求职招聘系统虽然看起来没那么复杂，但涉及候选人、企业、职位、简历、投递、消息多个业务域，不划清边界后期一定会乱。我沿用了经典的分层结构：
- Controller层：接收微信小程序发来的请求，做参数校验，调用Service，返回统一的Result结构。
- Service层：承载核心业务逻辑，比如职位发布、简历投递、简历匹配推荐。
- Mapper/DAO层：MyBatis的Mapper接口和XML，负责数据库操作。
- 工具层：JWT工具、AES加密工具、统一异常处理、枚举和常量定义。
模块划分上，我按业务域拆成了三块：用户端模块负责登录注册、简历管理、职位浏览、投递记录；企业端模块负责企业认证、职位发布、简历筛选、面试邀约；公共模块负责文件上传、消息通知、数据统计。单人开发或毕业设计用单模块Maven工程完全可行，但如果团队有3人以上，建议直接拆Maven多模块，例如common、system、job、resume、message，编译边界清晰，后续扩展也不容易互相污染。
这里还要提一个很容易被忽略的约定：所有接口返回结构必须统一。我习惯定义一个Result类，包含code、msg、data三个字段，成功code为200，业务失败code按模块细分，系统异常code为500。小程序端只需要封装一个请求函数，统一处理code，不需要每个页面都写重复的错误逻辑。这个习惯哪怕在SpringBoot升级后也没有改动过，属于长期受益的设计。
2. 核心数据模型与接口设计实操
2.1 求职招聘领域核心表结构规划
数据模型决定了系统能跑多远，我建议先想清楚实体关系和关键字段，再动手写Controller。求职招聘系统的核心表我设计了6张，主键都采用雪花ID或数据库自增ID，没有用外键约束，只靠索引和代码保证关联一致性，这样在高并发写入和后续分库分表时不会成为瓶颈。
| 表名 | 核心字段 | 关键说明 |
|---|---|---|
| user | id, openid, unionid, phone, nickname, avatar, user_type, status, create_time, update_time, deleted | user_type区分候选人和企业账号；openid必须唯一索引 |
| company | id, user_id, name, industry, scale, address, description, license_url, status | 企业认证信息，user_id关联user表 |
| position | id, company_id, title, category, salary_min, salary_max, city, experience_required, education_required, description, status | 职位状态字段方便上下架 |
| resume | id, user_id, name, gender, phone, email, education_list, work_experience, skill_tags, expected_position, expected_salary | 教育经历和工作经历用JSON字段存储，避免拆表过多 |
| delivery_record | id, user_id, position_id, company_id, status, create_time | 投递记录，status区分待处理、已查看、已邀约、不合适 |
| collection | id, user_id, position_id, create_time | 职位收藏，加唯一联合索引(user_id, position_id) |
几个关键设计点我展开说一下。第一，用户表和外部分平台打通时，openid和unionid尽量都保留，现在很多项目只存openid，后续接公众号或App时会发现数据对不上。第二，一定要用deleted逻辑删除字段，招聘系统里的投递记录、简历和职位都有强关联性，物理删除会把整条链路的数据链弄断，我见过有人直接删除简历导致企业端历史投递列表报空指针的案例。第三，状态字段用tinyint或int，不要用varchar存“已处理”这种中文值，后边改需求时你会发现枚举和数字才是最灵活的。
简历模块有个特殊点：教育经历、工作经历、项目经历都是可变长度数组。如果按传统关系型表设计，要拆成简历主表、教育经历表、工作经历表三张表，查询起来麻烦，写入也麻烦。我当时直接把这类内容设计成JSON字段存到resume表里，配合MyBatis的TypeHandler自动序列化和反序列化，既保证了展示速度，又减少了多表事务复杂度。这个方案在数据量几千到几万级完全够用，如果以后量级上来，再考虑拆专用子表。
2.2 微信小程序登录鉴权全流程
微信小程序的登录不能直接拿用户名密码，它有一套自己的鉴权机制，这也是后端最容易写乱的地方。标准流程是这样的：小程序端调用wx.login拿到一个临时code，后端拿code去微信接口服务换取openid和session_key，再用openid去查user表。如果查不到，就自动注册一个新用户；查得到，就正常登录。
拿到openid后，我推荐用JWT生成自定义登录态token返回给小程序端，而不是把openid直接暴露给前端。JWT可以简单理解成一张带签名和有效期的通行证，服务器签发后，后续请求只需在Header里携带token，后端拦截器验签即可确认用户身份。token有效期我一般设7天，长期用户可以在小程序启动时静默登录刷新。
具体接口路径我当时是这样设计的：
| 接口 | 方法 | 说明 |
|---|---|---|
| /api/user/login | POST | 入参code，换取openid并签发token |
| /api/user/info | GET | 获取个人资料 |
| /api/position/page | GET | 职位分页列表，按城市、薪资、经验筛选 |
| /api/position/detail | GET | 职位详情 |
| /api/delivery/apply | POST | 投递简历 |
| /api/delivery/record | GET | 候选人查看我的投递记录 |
| /api/company/position/save | POST | 企业端发布或编辑职位 |
| /api/resume/save | POST | 保存简历信息 |
这里有几个容易踩的坑。第一，code只能使用一次，且有效时间很短，前端连续调用会造成登录失败，后端要做好异常提示。第二，session_key不要存数据库，也不要想办法传给前端，它是微信侧解密手机号等敏感信息的密钥，只在后端使用即可。第三，JWT密钥不要写死在代码里，放到配置中心或环境变量里，泄漏等于任何人可以伪造登录身份。
2.3 跨域、加密和权限控制不能省
很多新手以为小程序不是浏览器，就没有跨域问题，这个说法只对了一半。小程序本身确实不受浏览器CORS限制，但求职招聘系统通常还配有一个企业管理后台，后台跑在Web浏览器里，这时候就一定得处理跨域。
在SSM阶段我写了一个CorsFilter，把所有接口加上了允许跨域的响应头；升级到SpringBoot后，这个逻辑可以直接用Spring自带的CorsRegistry替换，重写WebMvcConfigurer的addCorsMappings方法就行。有一点要注意，生产环境的allowedOrigins不要配成“*”，最好只允许你实际部署的域名，否则等于给所有外部站点开了访问权限。另外，跨域配置不要放在业务拦截器后面，否则预检请求OPTIONS会先被拦截器拦掉，导致浏览器误判。
权限控制方面，我建议至少做到两类角色隔离：候选人和企业管理员。用拦截器校验token，再根据user表中的user_type字段判断接口权限。比如投递简历接口只允许候选人访问，发布职位接口只允许企业账号访问，不符合就直接返回403。如果你担心敏感参数被抓包篡改，可以在登录后由后端下发一个AES加密用的盐或密钥，前端请求体用AES加密后再发送，后端统一解密。这个方案对订单、支付、简历隐私这类敏感操作很有价值，但要记得定期更新密钥，不能一个密钥用到系统下线。
3. SSM工程向SpringBoot平滑升级的落地方法
3.1 XML配置怎么变成YAML
SSM项目最常见的三份XML配置是applicationContext.xml、spring-mvc.xml、mybatis-config.xml。升级到SpringBoot时，不需要直接删掉它们，更推荐的做法是：新建一个SpringBoot工程，把XML里的配置逐条翻译到application.yml中，确认一切正常后再彻底移除XML文件，让老代码无感切换。
数据源部分的翻译最直观，原来是：
<bean id="dataSource" class="com.alibaba.druid.pool.DruidDataSource"> <property name="url" value="jdbc:mysql://localhost:3306/job?useSSL=false&serverTimezone=Asia/Shanghai"/> <property name="username" value="root"/> <property name="password" value="123456"/> </bean>到了SpringBoot就改成：
spring: datasource: url: jdbc:mysql://localhost:3306/job?useSSL=false&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver druid: initial-size: 5 max-active: 20MyBatis的配置对应关系是：mybatis-config.xml里的mapper扫描路径对应yml中的mybatis.mapper-locations，实体类包名对应mybatis.type-aliases-package。老项目里用注解配置的Spring扫描路径，在SpringBoot里基本不用管，启动类所在包下都会被自动扫描。需要注意的还有事务配置，老XML里常见的tx:annotation-driven在SpringBoot中默认生效，不用额外重复配置；如果自定义了事务管理器，才需要手动声明。
依赖部分也要跟着换。把spring-webmvc、mybatis、druid等依赖改成spring-boot-starter-web、mybatis-spring-boot-starter、druid-spring-boot-starter。这里容易出现版本兼容问题，建议稳妥组合：SpringBoot 2.7.x配Spring 5.3.x和JDK8，MyBatis Starter用2.2.x以上。SpringBoot 3.x虽然更好，但它最低要求JDK17，老项目的第三方组件和服务器不一定支持，没必要在第一次迁移时把JDK也一起升了。
3.2 升级实施步骤与回归验证
迁移过程不建议直接在跑着的SSM项目上动刀，一定先拉分支或者把整个工程复制一份。我按下面几个步骤走，整个过程基本可以控制在一天内完成：
- 新建SpringBoot工程，引入所需Starter依赖，确认JDK版本一致。
- 把老SSM项目的Java源码、resources目录、mapper XML完整拷贝到新工程对应位置。
- 在application.yml中补齐数据源、MyBatis、端口、文件上传大小、日志级别等配置。
- 处理需要单独注册的过滤器、拦截器，通过WebMvcConfigurer重写addInterceptors的方式接入。
- 启动项目，逐个调用核心接口，和旧环境返回结果做对比。
回归验证的优先级也有讲究，先验证登录鉴权，再验证职位分页查询和投递流程，最后验证简历保存、文件上传和企业后台数据统计。登录如果失败，后面所有接口都进不去；分页如果排序错乱，小程序端显示就会出问题。我在升级后遇到过两类高频问题：一是Mapper扫描遗漏导致启动报“Invalid bound statement (not found)”，解决办法是在启动类或配置类上加@MapperScan指定mapper包；二是Druid连接池参数翻译出错，导致启动时频繁报连接超时，最后对照旧XML一行行核对才解决。
升级期间把日志级别设成DEBUG模式会省很多事。SpringBoot默认用Logback，log4j的配置可以直接不管，在application.yml里加一句logging.level.com.yourproject.mapper=DEBUG，就能看到MyBatis实际执行的所有SQL，排查参数绑定和索引问题会清晰很多。
4. 常见问题与排查技巧实录
4.1 数据库连接、时区和慢SQL的那些坑
求职招聘系统最容易被环境坑到的环节就是数据库。最典型的是时间差8小时问题：MySQL连接串里没加serverTimezone=Asia/Shanghai，Java这边存的是北京时间，查出来显示的是UTC时间，简历投递时间、职位发布时间全部错位。这个不光是配置问题，还会影响职位列表的发布时间排序，用户看到最新职位排在第三页，体验极差。解决办法就是连接串统一带上useSSL=false&serverTimezone=Asia/Shanghai，服务端和数据库时区都检查一遍。
连接池参数是我另一个踩过坑的点。最开始图省事，把Druid的max-active直接配成200，结果上线没几天数据库连接被打满，应用反而变慢。原因很简单，数据库并发根本不需要那么多连接，连接数大会放大连接管理的开销。后来我按实际压测数据评估，初期配置initial-size=5、min-idle=5、max-active=20就能满足几千用户的招聘场景。如果后续活跃用户涨到几万，再结合Druid监控面板看activeCount等指标动态调整。
慢SQL在小数据量下很难暴露问题，但一旦职位表涨到几十万条，全表扫描就会让小程序端响应从200ms变成2秒以上。提前在position表和delivery_record表的关联字段上建好联合索引，这个成本极低，效果却非常明显。投递记录表必建索引(user_id, status)，职位表必建索引(company_id, status)，这是求职招聘系统的两条铁律。
4.2 微信小程序支付与接口联调的高频问题
如果一个招聘系统涉及简历付费下载、会员增值服务，就绕不开微信支付。微信支付目前推荐的是V3版协议，后端要做的事包括：组装预支付参数、调用下单接口、处理支付结果回调、解密回调报文、更新订单状态。V3版的证书和密钥机制比V2复杂，必须妥善保管商户私钥和APIv3密钥，绝不能写进小程序端代码，也不能传到Git仓库里。很多人联调失败，十有八九是回调验签没有做好，建议用官方SDK拦一遍后再自己写业务逻辑。
开发过程中，小程序经常碰到“支付功能暂时无法使用”或者调起支付失败。这类问题大多数不是代码问题，而是账号资质、类目审核或平台风控导致的。作为后端，我们只能保证接口和签名逻辑符合官方规范，真正的线上可用性由账号状态决定，所以务必用真实商户号完成联调，不要靠“先随便传个参数”的心态去测试。
小程序请求后端接口时还有个高频问题：开发工具打开“不校验合法域名”功能可以请求接口，但真机预览或上线后就会全部请求失败。这是因为微信要求线上环境必须使用已备案的HTTPS域名，并且要在小程序后台配置request合法域名。后端需要提前准备好备案域名和HTTPS证书，否则上线后所有接口都会挂在白名单上。
4.3 升级与部署阶段典型问题速查表
最后把SSM升级SpringBoot过程中我实际遇到的高频问题整理成一张速查表，方便你在迁移时直接对号入座。
| 现象 | 可能原因 | 解决思路 |
|---|---|---|
| 启动报Invalid bound statement | Mapper接口未扫描到 | 启动类加@MapperScan，或Mapper类上@Mapper |
| 端口冲突启动失败 | 内嵌Tomcat端口被占用 | 改server.port或排查占用进程 |
| 接口返回404 | 老工程有额外Servlet映射旧配置没迁移 | 检查Controller注解和拦截器路径，确认DispatcherServlet映射 |
| 上传图片提示文件过大 | 未设置上传大小 | spring.servlet.multipart.max-file-size和max-request-size |
| 查出来的时间差8小时 | 连接串无serverTimezone | 统一使用Asia/Shanghai |
| 跨域又被拦截 | 老CorsFilter没注册到Spring容器 | 用CorsRegistry配置或手写Filter并声明为Bean |
| 日志不输出 | log4j配置未随迁移切换 | SpringBoot改用logback，配置logging.level |
排查这类问题有一套通用的方法论：先看启动日志有没有异常堆栈，再看接口是否走到了Controller，再看SQL是否执行成功，最后看前端拿到的返回体是不是预期结构。推荐后端从第一天就写一个健康检查接口，返回数据库连接状态和系统运行时间，部署后先用这个接口确认基础环境正常，再开始功能联调，可以省掉很多无头绪的定位时间。
我个人在实际项目里最深的体会是：SSM和SpringBoot不是对立的派别，它们只是同一个技术体系里的不同阶段，代码分层和数据模型设计才是真正决定一个系统能走多远的东西。当年把SSM先跑稳、再平滑升级SpringBoot，整个过程只花了一个周末，后续团队招人、扩展模块都轻松很多。如果你也正卡在技术选型或老项目升级的路口，按照文章里的步骤一步步来，不贪快、不跳步，大概率能顺利趟过去。遇到具体的坑，也欢迎在评论区聊一聊你的迁移过程。
本文还有配套的精品资源，点击获取
