简介面向求职招聘领域的微信小程序全栈开发资源以小程序客户端Java后端SSM可升级SpringBootMySQL为核心覆盖求职者、商户、管理员三类角色。求职端包含微信授权登录、个人资料完善、兼职分类浏览、预约面试与评价互评商户端支持学校认证、店铺信息维护、岗位发布及面试请求处理管理后台配置客服与评分系统。资源包共1207个文件包含jsp、java等后端源码html、css、js用于Web管理端页面wxml、wxss、json支撑小程序结构逻辑png、gif等作为界面展示素材同时附有数据库SQL脚本整体压缩包约4.07MB目录划分清晰便于快速部署与二次开发。已有218人学习下载适合具备Java Web基础、准备毕业设计或求职招聘类项目的开发者可据此理解SSM到SpringBoot的改造思路、小程序与后端交互流程以及多角色权限管理的实现细节。 做了几年企业级管理系统最近帮一个团队落地了一套“微信小程序求职招聘系统”。项目本身不算复杂但有个需求很有意思——后端先用SSM把业务跑起来又要求在架构上预留升级SpringBoot的路径。这个“既要又要”的要求恰恰踩中了很多从SSM时代过来的人的真实痛点。这篇文章就把整个设计和迁移过程完整拆开讲清楚从数据库设计、接口契约、SSM分层到SpringBoot落地改造和踩坑记录一次性说透。1. 为什么选“微信小程序求职招聘”需求定位与业务场景拆解1.1 求职招聘场景下小程序比App和H5更合适的原因先说选型逻辑。招聘系统的核心用户是两类人求职者要频繁刷新岗位、快速投递简历企业HR要发布职位、筛选候选人。这两类人对“便捷性”的要求极高——求职者不会为了看一个岗位专门下载AppHR更不会在电脑前24小时盯着后台。微信小程序恰好卡在这个平衡点上对求职者来说随手打开微信就能刷职位、投简历不需要额外安装对H5来说小程序的缓存能力和微信生态的登录体系能提供更顺滑的体验。我们做的这套系统小程序端面向“求职者”和“企业HR”两个角色后端统一通过HTTP接口提供数据服务前端只负责交互展示和数据提交。1.2 核心业务流程与角色权限模型整个系统的业务流程可以归纳为四条主线求职者微信授权登录 → 完善简历 → 浏览/搜索职位 → 投递简历 → 查看投递反馈企业HR注册并认证企业 → 发布职位 → 查看收到的简历 → 更新投递状态后台管理员审核企业资质 → 管理职位信息 → 处理异常数据比如违规职位下架这里要特别提一下用户在系统中的角色区分。我们用的方案是user表中加一个role字段取值是0/1/2对应管理员、求职者、招聘者。做权限拦截时后端统一在拦截器中校验而不是在小程序端做控制——小程序端的代码是能被绕过的真正的安全边界一定在后端。1.3 “可升级SpringBoot”到底升的是什么说到“SSM可升级SpringBoot”很多人理解为“项目写完之后把框架换掉”这是不对的。真正可升级的设计是写代码的时候就让业务逻辑与框架解耦Service层不出现Servlet API、不出现Spring特有的注解依赖数据访问层只依赖MyBatis的Mapper接口。这样从一个框架切到另一个框架时改的是装配方式配置文件、启动类而不是业务代码。我当时给团队的约定很简单Controller层只做参数接收和结果封装Service层不许写与HTTP相关的代码DAO层只通过接口暴露方法。这个约定在后来的迁移中节省了大量时间——真正改动的文件集中在config包、pom.xml和部署脚本上。2. SSM打底三层架构怎么布局才经得起升级折腾2.1 项目结构从一开始就按SpringBoot的包结构来组织很多SSM老项目的包名喜欢按“controller/service/dao”平铺这种结构在SpringBoot时代也没问题但对于“要升级”的项目我更推荐按功能模块分包——也就是常说的“按业务垂直切分”。这套求职招聘系统中com.xxx.job下的分包逻辑是com.xxx.job ├── config // 配置类后续SpringBoot的JavaConfig都放这里 ├── controller // 接口层H5/小程序统一调用 ├── service // 业务层定义接口impl实现 ├── dao // MyBatis Mapper接口 ├── entity // 数据库实体 ├── vo // 视图对象专门给前端返回数据用 ├── common // 通用工具、统一返回体、异常处理 └── JobApplication.java // SpringBoot启动类迁移时新增为什么推荐这种分包因为SpringBoot的核心是“自动配置启动类包扫描”如果你一开始就把config包预留出来迁移时只需把原本分散在XML里的Bean定义改造成JavaConfig类启动类一扫描就能生效。反观那些把配置乱七八糟塞在工具类里的项目迁移时往往是“深夜改错一处排查一整晚”。2.2 数据库设计求职招聘系统的三张核心表数据库是整个系统最不能返工的部分。这里我给出核心的三张表结构它们支撑了完整的业务闭环。用户表userCREATE TABLE sys_user ( id bigint(20) NOT NULL AUTO_INCREMENT, openid varchar(64) NOT NULL COMMENT 微信openid, nickname varchar(64) DEFAULT NULL, avatar varchar(255) DEFAULT NULL, phone varchar(20) DEFAULT NULL, role tinyint(4) DEFAULT 1 COMMENT 0-管理员1-求职者2-招聘者, company_id bigint(20) DEFAULT NULL COMMENT 企业ID招聘者必填, status tinyint(4) DEFAULT 1, create_time datetime DEFAULT NULL, update_time datetime DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_openid (openid) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;职位表jobCREATE TABLE job ( id bigint(20) NOT NULL AUTO_INCREMENT, company_id bigint(20) NOT NULL, title varchar(100) NOT NULL, category varchar(50) DEFAULT NULL COMMENT 职位类别, salary_min int(11) DEFAULT NULL COMMENT 薪资下限千/月, salary_max int(11) DEFAULT NULL, city varchar(50) DEFAULT NULL, education varchar(20) DEFAULT NULL COMMENT 学历要求, experience varchar(20) DEFAULT NULL COMMENT 经验要求, description text COMMENT 职位描述, status tinyint(4) DEFAULT 1 COMMENT 0-下架1-招聘中, create_time datetime DEFAULT NULL, update_time datetime DEFAULT NULL, PRIMARY KEY (id), KEY idx_city_category (city, category) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;投递表deliveryCREATE TABLE delivery ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id bigint(20) NOT NULL, job_id bigint(20) NOT NULL, resume_id bigint(20) NOT NULL, status tinyint(4) NOT NULL DEFAULT 1 COMMENT 1-已投递2-已查看3-已通知面试4-已录用5-已拒绝, feedback varchar(500) DEFAULT NULL COMMENT HR反馈, create_time datetime DEFAULT NULL, update_time datetime DEFAULT NULL, PRIMARY KEY (id), KEY idx_user (user_id), KEY idx_job (job_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这个设计里有一个容易被忽略的点delivery表的status字段。很多招聘系统把投递状态做成简单的“已投递/已查看/已邀约”但实际业务中HR可能先标记“已查看”过几天再改成“已通知面试”这些状态转换都需要记录时间。我们额外加一个delivery_log表去记录状态变更历史方便求职者端展示“投递进度时间线”也让后续做数据分析有据可查。2.3 数据访问层的扩展性MyBatis的Generator和手写SQL怎么平衡用MyBatis就绕不开一个问题单表CRUD用MBG自动生成还是手写我的建议是基础的单表操作按主键查、按条件分页查交给MBG但所有关联查询、多表联查、复杂统计一定手写SQL。原因是MBG生成的代码升级依赖成本低但一旦遇到多表关联就代码冗余且效率极差。比如职位列表页需要展示企业名称和LOGO就必须联查company表。手写SQL时注意用LEFT JOIN而不是INNER JOIN避免企业信息缺失导致职位列表变短同时分页查询一定要用LIMIT offset, size并配合COUNT(*)统计总条数。如果数据量大了后续可以再考虑用PageHelper插件但初期手写就能完全控制SQL质量。3. 前后端契约先行小程序端接口设计与核心交互逻辑3.1 微信登录code换openid的完整时序微信小程序的登录流程第一次做的人特别容易在“后端到底存什么”上犯迷糊。完整流程是这样的小程序端调用wx.login()拿到临时code小程序把code通过POST /api/login发给后端后端拿着code去微信接口jscode2session换取openid和session_key后端查库如果openid不存在创建新用户存在则直接返回已注册信息后端生成自定义Token比如UUID存入Redis或数据库返回给前端小程序把Token存到storage之后的请求都放在请求头Authorization里// 后端核心代码片段 MapString, Object result new HashMap(); // 微信接口返回 JSONObject session wxService.code2Session(code); String openid session.getString(openid); User user userMapper.selectByOpenid(openid); if (user null) { user new User(); user.setOpenid(openid); user.setRole(1); user.setCreateTime(new Date()); userMapper.insert(user); } String token UUID.randomUUID().toString().replaceAll(-, ); redisTemplate.opsForValue().set(login:token: token, user.getId().toString(), 7, TimeUnit.DAYS); result.put(token, token); result.put(role, user.getRole());注意事项微信的session_key永远不要下发到前端它只用于解密敏感信息对求职招聘系统来说一般用不到。Token要设过期时间7天比较合理再配合wx.checkSession在前端判断登录态是否失效。3.2 三大核心接口职位检索、投递、HR管理接口是整个系统的“契约”先定契约再写代码前后端才能并行开发。列一下这套系统最核心的接口接口路径方法说明参数/api/job/listGET职位分页搜索keywordcitycategorypagesize/api/job/detailGET职位详情jobId/api/delivery/addPOST投递简历jobIdresumeId/api/delivery/listGET我的投递记录求职者pagesize/api/hr/job/addPOSTHR发布职位职位对象/api/hr/delivery/listGETHR收到的简历列表jobIdpagesize/api/hr/delivery/updatePOST更新投递状态deliveryIdstatusfeedback统一返回体也是这个阶段定下来的。我们用的是ResultT结构{ code: 200, message: success, data: { } }约定code为200表示成功其他code对应业务异常。小程序端封装了一个request方法所有请求进来先判断code不是200就统一弹Toast提示这样就避免了每个页面重复写错误处理。3.3 投递状态机从“已投递”到“已反馈”的闭环设计投递状态是做求职招聘系统时很容易想简单、做起来又容易乱的地方。我的做法是定义状态机1 已投递初始状态用户点击投递后创建2 已查看HR点击查看简历详情后自动变更3 已通知面试HR觉得合适点“通知面试”4 已录用面试后决定录用5 已拒绝不合适/未通过HR可填写反馈原因状态流转的规则是只允许从当前状态往“更靠后”的状态流转不允许用户撤销之后HR还能看到。比如求职者反悔投递我们设计的是新增status0标记“已撤销”而不是把状态改回初始值这样HR侧看到的就是一条撤销记录而不是凭空消失。状态变更统一走Service层的一个方法updateDeliveryStatus(deliveryId, targetStatus, hrId)内部先查当前状态再校验合法性这样可以杜绝前端传什么状态就改什么状态的风险。4. 从SSM到SpringBoot渐进式迁移的核心改造路径4.1 SSM和SpringBoot的本质差异不是“替换”而是“消解”很多人觉得SpringBoot是替换SSM的新框架这个理解有偏差。SpringBoot本质上还是用Spring SpringMVC MyBatis这一套东西它做的是把原本大量手工编写的XML配置、Bean装配动作变成“自动配置约定优于配置”。SSM时代一个接口从请求进入到响应返回要经过DispatcherServlet → HandlerMapping → Controller → Service → Mapper这套链路SpringBoot完全保留。区别在于传统SSM用web.xml声明DispatcherServlet用spring-mvc.xml开启注解驱动用spring-mybatis.xml配置数据源和SqlSessionFactorySpringBoot一个启动类 application.yml 几个Configuration类全部搞定4.2 配置迁移三步走依赖替换、配置收敛、启动器替换具体的迁移路径我总结成三步第一步替换Maven依赖把SSM里零散的Spring、MyBatis依赖全部删掉替换成parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version2.3.1/version /dependency dependency groupIdmysql-connector-j/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency /dependencies第二步把XML配置收敛进application.yml原来SSM的jdbc.properties加上spring-mybatis.xml里写的数据源、连接池、Mapper扫描路径全部收进一个文件spring: datasource: url: jdbc:mysql://localhost:3306/job?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.xxx.job.entity configuration: map-underscore-to-camel-case: true第三步新建启动类改造配置Bean原spring-mvc.xml里的拦截器、CORS配置、静态资源映射逐步改造成JavaConfig类。SpringBootApplication MapperScan(com.xxx.job.dao) public class JobApplication { public static void main(String[] args) { SpringApplication.run(JobApplication.class, args); } }迁移时最容易漏掉的是MapperScan。传统SSM项目在spring-mybatis.xml里用mybatis:scan或property namebasePackage配置DAO接口扫描SpringBoot里如果不显式加MapperScanMyBatis完全找不到Mapper启动直接报“Invalid bound statement”。4.3 MyBatis与事务管理两个最容易“灯下黑”的环节MyBatis这块最容易出的坑是Mapper XML文件路径不一致。SSM项目里许多人习惯把XML放在src/main/resources/mapper下也有放src/main/java下用Maven插件一起打包的。SpringBoot推荐前者mybatis.mapper-locationsclasspath:mapper/*.xml。如果你从SSM迁移后发现“接口存在但报statement not found”先检查XML有没有被maven-resources-plugin排除掉。事务也是重灾区。SSM里通常这么声明tx:advice idtxAdvice transaction-managertransactionManager tx:attributes tx:method nameadd* propagationREQUIRED/ tx:method nameupdate* propagationREQUIRED/ /tx:attributes /tx:adviceSpringBoot里如果还用这么细粒度的声明式事务控制就要自己声明TransactionInterceptor更简单的做法是直接用Transactional注解下沉到Service实现类的方法上。我的习惯是类级别不写Transactional但涉及多表写入的方法一定要加并且指定rollbackFor Exception.class不指定的话碰到RuntimeException没关系但遇到受检异常就不回滚了数据就脏了。5. 实测迁移中的三个典型坑静态资源、拦截器与文件上传5.1 静态资源404SpringBoot默认映射路径和SSM不一样先说静态资源。SSM项目里我们会在spring-mvc.xml中配置mvc:resources mapping/upload/** location/WEB-INF/upload//企业LOGO上传到/WEB-INF/upload/通过域名/upload/xxx.png访问。到了SpringBoot默认静态资源路径是classpath:/static/、classpath:/public/这些你之前放/WEB-INF/upload/的文件根本访问不到。当时我们改成了把上传文件存到服务器本地磁盘的/data/job/upload/然后通过自定义配置映射Configuration public class WebConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file:/data/job/upload/); } }这个场景说明一件事从SSM迁移到SpringBoot不只是改配置语法很多资源存储策略要顺应新框架的规范重做。5.2 拦截器不生效则请求直接进Controller登录拦截器是这套系统的安全底线。SSM里注册拦截器是在spring-mvc.xmlmvc:interceptors mvc:interceptor mvc:mapping path/api/**/ mvc:exclude-mapping path/api/login/ bean classcom.xxx.job.interceptor.LoginInterceptor/ /mvc:interceptor /mvc:interceptorsSpringBoot里我改成实现WebMvcConfigurer接口重写addInterceptorsOverride public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(loginInterceptor) .addPathPatterns(/api/**) .excludePathPatterns(/api/login, /api/job/list, /api/job/detail); }这个坑的隐蔽之处在于如果你的配置类忘了加Configuration注解或者项目里存在多个WebMvcConfigurer实现类没有统一管理拦截器会以“静默方式”不生效。排查的方法是启动日志里看MappingJackson2HttpMessageConverter或者请求进后端时打一条拦截器内的日志确认每一层都走到。5.3 文件上传临时目录小功能背后的大坑SpringBoot默认使用spring.servlet.multipart处理文件上传底层实现会用到系统临时目录比如Linux的/tmp。生产环境中/tmp下的文件有可能被系统定期清理上传过程中一旦临时文件丢了接口就报“Failed to parse multipart servlet request”。我们在SSM时代用的是CommonsMultipartResolver显式指定了上传临时目录所以从没遇到这个问题。SpringBoot切到MultipartAutoConfiguration之后如果你不做任何配置就踩到了系统清理临时目录的坑。解决方案是在配置里指定一个长期目录spring: servlet: multipart: enabled: true max-file-size: 10MB max-request-size: 20MB location: /data/job/upload_tmp这个location就是告诉Spring把临时文件写到指定目录而不是系统默认/tmp定期清理也不影响正在上传的请求。别小看这个配置生产环境跑几天之后突然有用户反馈“简历附件传不上来”你如果不知道这个机制排查起来相当耗时。6. 最后分享几点真实做这类项目的体会回到标题里“可升级SpringBoot”这个点我最大的体会是框架升级最怕的不是配置语法不熟而是业务代码和框架代码搅在一起分不开。这次项目里我们把Controller层尽量写薄连参数校验都交给Spring的Validated去处理Service层坚持面向接口编程所有跨表操作都以TransactionTemplate或注解事务收口数据访问层把复杂的联查SQL统一收敛到XML文件管理不散落在注解里。正因为这些坚持从SSM切到SpringBoot时实际修改的配置文件不到10个业务代码几乎零改动。给准备做相似项目的朋友两个具体建议网上Java毕设、项目实战的SSM项目很多但拿到手之后第一件事不是跑起来而是先把包结构和依赖梳理一遍。如果你发现某个项目里Controller里频繁操作HttpSession、Service里还有JSONObject满天飞这种项目就别指望靠换框架升级了重构成本比新写还高。做微信小程序端后端接口路径规划一定要留版本号前缀比如/api/v1/因为小程序发版审核是一个慢过程如果接口要变旧版本小程序可能还在线上运行。没有版本号的接口一旦升级就是“后端改了老用户全部白屏”。这个项目做完之后我们把部署方式也顺带改成了Docker Jenkins流水线从代码提交到测试环境发布全程自动。如果你打算长期维护这套求职招聘系统后续还可以扩展消息推送面试通知模板消息、职位订阅根据简历关键词匹配推荐、数据看板职位投递转化统计这些模块底子打好了加功能只是时间问题。本文还有配套的精品资源点击获取 SSM升级SpringBoot实战：微信小程序求职招聘系统设计与迁移全记录
简介面向求职招聘领域的微信小程序全栈开发资源以小程序客户端Java后端SSM可升级SpringBootMySQL为核心覆盖求职者、商户、管理员三类角色。求职端包含微信授权登录、个人资料完善、兼职分类浏览、预约面试与评价互评商户端支持学校认证、店铺信息维护、岗位发布及面试请求处理管理后台配置客服与评分系统。资源包共1207个文件包含jsp、java等后端源码html、css、js用于Web管理端页面wxml、wxss、json支撑小程序结构逻辑png、gif等作为界面展示素材同时附有数据库SQL脚本整体压缩包约4.07MB目录划分清晰便于快速部署与二次开发。已有218人学习下载适合具备Java Web基础、准备毕业设计或求职招聘类项目的开发者可据此理解SSM到SpringBoot的改造思路、小程序与后端交互流程以及多角色权限管理的实现细节。 做了几年企业级管理系统最近帮一个团队落地了一套“微信小程序求职招聘系统”。项目本身不算复杂但有个需求很有意思——后端先用SSM把业务跑起来又要求在架构上预留升级SpringBoot的路径。这个“既要又要”的要求恰恰踩中了很多从SSM时代过来的人的真实痛点。这篇文章就把整个设计和迁移过程完整拆开讲清楚从数据库设计、接口契约、SSM分层到SpringBoot落地改造和踩坑记录一次性说透。1. 为什么选“微信小程序求职招聘”需求定位与业务场景拆解1.1 求职招聘场景下小程序比App和H5更合适的原因先说选型逻辑。招聘系统的核心用户是两类人求职者要频繁刷新岗位、快速投递简历企业HR要发布职位、筛选候选人。这两类人对“便捷性”的要求极高——求职者不会为了看一个岗位专门下载AppHR更不会在电脑前24小时盯着后台。微信小程序恰好卡在这个平衡点上对求职者来说随手打开微信就能刷职位、投简历不需要额外安装对H5来说小程序的缓存能力和微信生态的登录体系能提供更顺滑的体验。我们做的这套系统小程序端面向“求职者”和“企业HR”两个角色后端统一通过HTTP接口提供数据服务前端只负责交互展示和数据提交。1.2 核心业务流程与角色权限模型整个系统的业务流程可以归纳为四条主线求职者微信授权登录 → 完善简历 → 浏览/搜索职位 → 投递简历 → 查看投递反馈企业HR注册并认证企业 → 发布职位 → 查看收到的简历 → 更新投递状态后台管理员审核企业资质 → 管理职位信息 → 处理异常数据比如违规职位下架这里要特别提一下用户在系统中的角色区分。我们用的方案是user表中加一个role字段取值是0/1/2对应管理员、求职者、招聘者。做权限拦截时后端统一在拦截器中校验而不是在小程序端做控制——小程序端的代码是能被绕过的真正的安全边界一定在后端。1.3 “可升级SpringBoot”到底升的是什么说到“SSM可升级SpringBoot”很多人理解为“项目写完之后把框架换掉”这是不对的。真正可升级的设计是写代码的时候就让业务逻辑与框架解耦Service层不出现Servlet API、不出现Spring特有的注解依赖数据访问层只依赖MyBatis的Mapper接口。这样从一个框架切到另一个框架时改的是装配方式配置文件、启动类而不是业务代码。我当时给团队的约定很简单Controller层只做参数接收和结果封装Service层不许写与HTTP相关的代码DAO层只通过接口暴露方法。这个约定在后来的迁移中节省了大量时间——真正改动的文件集中在config包、pom.xml和部署脚本上。2. SSM打底三层架构怎么布局才经得起升级折腾2.1 项目结构从一开始就按SpringBoot的包结构来组织很多SSM老项目的包名喜欢按“controller/service/dao”平铺这种结构在SpringBoot时代也没问题但对于“要升级”的项目我更推荐按功能模块分包——也就是常说的“按业务垂直切分”。这套求职招聘系统中com.xxx.job下的分包逻辑是com.xxx.job ├── config // 配置类后续SpringBoot的JavaConfig都放这里 ├── controller // 接口层H5/小程序统一调用 ├── service // 业务层定义接口impl实现 ├── dao // MyBatis Mapper接口 ├── entity // 数据库实体 ├── vo // 视图对象专门给前端返回数据用 ├── common // 通用工具、统一返回体、异常处理 └── JobApplication.java // SpringBoot启动类迁移时新增为什么推荐这种分包因为SpringBoot的核心是“自动配置启动类包扫描”如果你一开始就把config包预留出来迁移时只需把原本分散在XML里的Bean定义改造成JavaConfig类启动类一扫描就能生效。反观那些把配置乱七八糟塞在工具类里的项目迁移时往往是“深夜改错一处排查一整晚”。2.2 数据库设计求职招聘系统的三张核心表数据库是整个系统最不能返工的部分。这里我给出核心的三张表结构它们支撑了完整的业务闭环。用户表userCREATE TABLE sys_user ( id bigint(20) NOT NULL AUTO_INCREMENT, openid varchar(64) NOT NULL COMMENT 微信openid, nickname varchar(64) DEFAULT NULL, avatar varchar(255) DEFAULT NULL, phone varchar(20) DEFAULT NULL, role tinyint(4) DEFAULT 1 COMMENT 0-管理员1-求职者2-招聘者, company_id bigint(20) DEFAULT NULL COMMENT 企业ID招聘者必填, status tinyint(4) DEFAULT 1, create_time datetime DEFAULT NULL, update_time datetime DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_openid (openid) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;职位表jobCREATE TABLE job ( id bigint(20) NOT NULL AUTO_INCREMENT, company_id bigint(20) NOT NULL, title varchar(100) NOT NULL, category varchar(50) DEFAULT NULL COMMENT 职位类别, salary_min int(11) DEFAULT NULL COMMENT 薪资下限千/月, salary_max int(11) DEFAULT NULL, city varchar(50) DEFAULT NULL, education varchar(20) DEFAULT NULL COMMENT 学历要求, experience varchar(20) DEFAULT NULL COMMENT 经验要求, description text COMMENT 职位描述, status tinyint(4) DEFAULT 1 COMMENT 0-下架1-招聘中, create_time datetime DEFAULT NULL, update_time datetime DEFAULT NULL, PRIMARY KEY (id), KEY idx_city_category (city, category) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;投递表deliveryCREATE TABLE delivery ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id bigint(20) NOT NULL, job_id bigint(20) NOT NULL, resume_id bigint(20) NOT NULL, status tinyint(4) NOT NULL DEFAULT 1 COMMENT 1-已投递2-已查看3-已通知面试4-已录用5-已拒绝, feedback varchar(500) DEFAULT NULL COMMENT HR反馈, create_time datetime DEFAULT NULL, update_time datetime DEFAULT NULL, PRIMARY KEY (id), KEY idx_user (user_id), KEY idx_job (job_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这个设计里有一个容易被忽略的点delivery表的status字段。很多招聘系统把投递状态做成简单的“已投递/已查看/已邀约”但实际业务中HR可能先标记“已查看”过几天再改成“已通知面试”这些状态转换都需要记录时间。我们额外加一个delivery_log表去记录状态变更历史方便求职者端展示“投递进度时间线”也让后续做数据分析有据可查。2.3 数据访问层的扩展性MyBatis的Generator和手写SQL怎么平衡用MyBatis就绕不开一个问题单表CRUD用MBG自动生成还是手写我的建议是基础的单表操作按主键查、按条件分页查交给MBG但所有关联查询、多表联查、复杂统计一定手写SQL。原因是MBG生成的代码升级依赖成本低但一旦遇到多表关联就代码冗余且效率极差。比如职位列表页需要展示企业名称和LOGO就必须联查company表。手写SQL时注意用LEFT JOIN而不是INNER JOIN避免企业信息缺失导致职位列表变短同时分页查询一定要用LIMIT offset, size并配合COUNT(*)统计总条数。如果数据量大了后续可以再考虑用PageHelper插件但初期手写就能完全控制SQL质量。3. 前后端契约先行小程序端接口设计与核心交互逻辑3.1 微信登录code换openid的完整时序微信小程序的登录流程第一次做的人特别容易在“后端到底存什么”上犯迷糊。完整流程是这样的小程序端调用wx.login()拿到临时code小程序把code通过POST /api/login发给后端后端拿着code去微信接口jscode2session换取openid和session_key后端查库如果openid不存在创建新用户存在则直接返回已注册信息后端生成自定义Token比如UUID存入Redis或数据库返回给前端小程序把Token存到storage之后的请求都放在请求头Authorization里// 后端核心代码片段 MapString, Object result new HashMap(); // 微信接口返回 JSONObject session wxService.code2Session(code); String openid session.getString(openid); User user userMapper.selectByOpenid(openid); if (user null) { user new User(); user.setOpenid(openid); user.setRole(1); user.setCreateTime(new Date()); userMapper.insert(user); } String token UUID.randomUUID().toString().replaceAll(-, ); redisTemplate.opsForValue().set(login:token: token, user.getId().toString(), 7, TimeUnit.DAYS); result.put(token, token); result.put(role, user.getRole());注意事项微信的session_key永远不要下发到前端它只用于解密敏感信息对求职招聘系统来说一般用不到。Token要设过期时间7天比较合理再配合wx.checkSession在前端判断登录态是否失效。3.2 三大核心接口职位检索、投递、HR管理接口是整个系统的“契约”先定契约再写代码前后端才能并行开发。列一下这套系统最核心的接口接口路径方法说明参数/api/job/listGET职位分页搜索keywordcitycategorypagesize/api/job/detailGET职位详情jobId/api/delivery/addPOST投递简历jobIdresumeId/api/delivery/listGET我的投递记录求职者pagesize/api/hr/job/addPOSTHR发布职位职位对象/api/hr/delivery/listGETHR收到的简历列表jobIdpagesize/api/hr/delivery/updatePOST更新投递状态deliveryIdstatusfeedback统一返回体也是这个阶段定下来的。我们用的是ResultT结构{ code: 200, message: success, data: { } }约定code为200表示成功其他code对应业务异常。小程序端封装了一个request方法所有请求进来先判断code不是200就统一弹Toast提示这样就避免了每个页面重复写错误处理。3.3 投递状态机从“已投递”到“已反馈”的闭环设计投递状态是做求职招聘系统时很容易想简单、做起来又容易乱的地方。我的做法是定义状态机1 已投递初始状态用户点击投递后创建2 已查看HR点击查看简历详情后自动变更3 已通知面试HR觉得合适点“通知面试”4 已录用面试后决定录用5 已拒绝不合适/未通过HR可填写反馈原因状态流转的规则是只允许从当前状态往“更靠后”的状态流转不允许用户撤销之后HR还能看到。比如求职者反悔投递我们设计的是新增status0标记“已撤销”而不是把状态改回初始值这样HR侧看到的就是一条撤销记录而不是凭空消失。状态变更统一走Service层的一个方法updateDeliveryStatus(deliveryId, targetStatus, hrId)内部先查当前状态再校验合法性这样可以杜绝前端传什么状态就改什么状态的风险。4. 从SSM到SpringBoot渐进式迁移的核心改造路径4.1 SSM和SpringBoot的本质差异不是“替换”而是“消解”很多人觉得SpringBoot是替换SSM的新框架这个理解有偏差。SpringBoot本质上还是用Spring SpringMVC MyBatis这一套东西它做的是把原本大量手工编写的XML配置、Bean装配动作变成“自动配置约定优于配置”。SSM时代一个接口从请求进入到响应返回要经过DispatcherServlet → HandlerMapping → Controller → Service → Mapper这套链路SpringBoot完全保留。区别在于传统SSM用web.xml声明DispatcherServlet用spring-mvc.xml开启注解驱动用spring-mybatis.xml配置数据源和SqlSessionFactorySpringBoot一个启动类 application.yml 几个Configuration类全部搞定4.2 配置迁移三步走依赖替换、配置收敛、启动器替换具体的迁移路径我总结成三步第一步替换Maven依赖把SSM里零散的Spring、MyBatis依赖全部删掉替换成parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version2.3.1/version /dependency dependency groupIdmysql-connector-j/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency /dependencies第二步把XML配置收敛进application.yml原来SSM的jdbc.properties加上spring-mybatis.xml里写的数据源、连接池、Mapper扫描路径全部收进一个文件spring: datasource: url: jdbc:mysql://localhost:3306/job?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.xxx.job.entity configuration: map-underscore-to-camel-case: true第三步新建启动类改造配置Bean原spring-mvc.xml里的拦截器、CORS配置、静态资源映射逐步改造成JavaConfig类。SpringBootApplication MapperScan(com.xxx.job.dao) public class JobApplication { public static void main(String[] args) { SpringApplication.run(JobApplication.class, args); } }迁移时最容易漏掉的是MapperScan。传统SSM项目在spring-mybatis.xml里用mybatis:scan或property namebasePackage配置DAO接口扫描SpringBoot里如果不显式加MapperScanMyBatis完全找不到Mapper启动直接报“Invalid bound statement”。4.3 MyBatis与事务管理两个最容易“灯下黑”的环节MyBatis这块最容易出的坑是Mapper XML文件路径不一致。SSM项目里许多人习惯把XML放在src/main/resources/mapper下也有放src/main/java下用Maven插件一起打包的。SpringBoot推荐前者mybatis.mapper-locationsclasspath:mapper/*.xml。如果你从SSM迁移后发现“接口存在但报statement not found”先检查XML有没有被maven-resources-plugin排除掉。事务也是重灾区。SSM里通常这么声明tx:advice idtxAdvice transaction-managertransactionManager tx:attributes tx:method nameadd* propagationREQUIRED/ tx:method nameupdate* propagationREQUIRED/ /tx:attributes /tx:adviceSpringBoot里如果还用这么细粒度的声明式事务控制就要自己声明TransactionInterceptor更简单的做法是直接用Transactional注解下沉到Service实现类的方法上。我的习惯是类级别不写Transactional但涉及多表写入的方法一定要加并且指定rollbackFor Exception.class不指定的话碰到RuntimeException没关系但遇到受检异常就不回滚了数据就脏了。5. 实测迁移中的三个典型坑静态资源、拦截器与文件上传5.1 静态资源404SpringBoot默认映射路径和SSM不一样先说静态资源。SSM项目里我们会在spring-mvc.xml中配置mvc:resources mapping/upload/** location/WEB-INF/upload//企业LOGO上传到/WEB-INF/upload/通过域名/upload/xxx.png访问。到了SpringBoot默认静态资源路径是classpath:/static/、classpath:/public/这些你之前放/WEB-INF/upload/的文件根本访问不到。当时我们改成了把上传文件存到服务器本地磁盘的/data/job/upload/然后通过自定义配置映射Configuration public class WebConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file:/data/job/upload/); } }这个场景说明一件事从SSM迁移到SpringBoot不只是改配置语法很多资源存储策略要顺应新框架的规范重做。5.2 拦截器不生效则请求直接进Controller登录拦截器是这套系统的安全底线。SSM里注册拦截器是在spring-mvc.xmlmvc:interceptors mvc:interceptor mvc:mapping path/api/**/ mvc:exclude-mapping path/api/login/ bean classcom.xxx.job.interceptor.LoginInterceptor/ /mvc:interceptor /mvc:interceptorsSpringBoot里我改成实现WebMvcConfigurer接口重写addInterceptorsOverride public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(loginInterceptor) .addPathPatterns(/api/**) .excludePathPatterns(/api/login, /api/job/list, /api/job/detail); }这个坑的隐蔽之处在于如果你的配置类忘了加Configuration注解或者项目里存在多个WebMvcConfigurer实现类没有统一管理拦截器会以“静默方式”不生效。排查的方法是启动日志里看MappingJackson2HttpMessageConverter或者请求进后端时打一条拦截器内的日志确认每一层都走到。5.3 文件上传临时目录小功能背后的大坑SpringBoot默认使用spring.servlet.multipart处理文件上传底层实现会用到系统临时目录比如Linux的/tmp。生产环境中/tmp下的文件有可能被系统定期清理上传过程中一旦临时文件丢了接口就报“Failed to parse multipart servlet request”。我们在SSM时代用的是CommonsMultipartResolver显式指定了上传临时目录所以从没遇到这个问题。SpringBoot切到MultipartAutoConfiguration之后如果你不做任何配置就踩到了系统清理临时目录的坑。解决方案是在配置里指定一个长期目录spring: servlet: multipart: enabled: true max-file-size: 10MB max-request-size: 20MB location: /data/job/upload_tmp这个location就是告诉Spring把临时文件写到指定目录而不是系统默认/tmp定期清理也不影响正在上传的请求。别小看这个配置生产环境跑几天之后突然有用户反馈“简历附件传不上来”你如果不知道这个机制排查起来相当耗时。6. 最后分享几点真实做这类项目的体会回到标题里“可升级SpringBoot”这个点我最大的体会是框架升级最怕的不是配置语法不熟而是业务代码和框架代码搅在一起分不开。这次项目里我们把Controller层尽量写薄连参数校验都交给Spring的Validated去处理Service层坚持面向接口编程所有跨表操作都以TransactionTemplate或注解事务收口数据访问层把复杂的联查SQL统一收敛到XML文件管理不散落在注解里。正因为这些坚持从SSM切到SpringBoot时实际修改的配置文件不到10个业务代码几乎零改动。给准备做相似项目的朋友两个具体建议网上Java毕设、项目实战的SSM项目很多但拿到手之后第一件事不是跑起来而是先把包结构和依赖梳理一遍。如果你发现某个项目里Controller里频繁操作HttpSession、Service里还有JSONObject满天飞这种项目就别指望靠换框架升级了重构成本比新写还高。做微信小程序端后端接口路径规划一定要留版本号前缀比如/api/v1/因为小程序发版审核是一个慢过程如果接口要变旧版本小程序可能还在线上运行。没有版本号的接口一旦升级就是“后端改了老用户全部白屏”。这个项目做完之后我们把部署方式也顺带改成了Docker Jenkins流水线从代码提交到测试环境发布全程自动。如果你打算长期维护这套求职招聘系统后续还可以扩展消息推送面试通知模板消息、职位订阅根据简历关键词匹配推荐、数据看板职位投递转化统计这些模块底子打好了加功能只是时间问题。本文还有配套的精品资源点击获取