企业官网建设流程全解析

简介：这是一套面向高校学生与校园商户的微信小程序求职招聘系统源码，采用微信小程序客户端、Java后台服务器与MySQL数据库三层架构，并基于SSM框架实现，可平滑升级至SpringBoot。系统区分求职者、商家与管理员三种身份：求职者授权登录后完善院系、专业、性格等信息，按分类挑选兼职并预约面试；商家通过学校认证后发布岗位、接收面试请求；管理员在Web后台统一管理，同时内置评分互评与客服系统，便于优秀商户与学生获得更多曝光和录用机会。压缩包共1207个文件，约4.07MB，包含html、js、css、png等前端资源，jsp、java、xml、properties等后端代码，以及json、wxss、wxml等小程序页面文件，另有sql脚本与db数据文件，结构完整、便于二次开发。目前已有218人学习下载，适合作为课程设计、毕业设计或小程序全栈练手项目，帮助读者快速理解招聘类系统的业务闭环与前后端协作方式。

1. 求职招聘小程序后端：一个 SSM 到 SpringBoot 的平滑升级样本

招聘季那阵子，某高校实验室的 A 同学拿着这套源码来找我，说想改成一个垂直行业的招聘工具，结果卡在环境上——他本地跑的是 SpringBoot 3.x，而项目里还是传统的 SSM 三层结构加 JSP 时代的 XML 配置。这其实是很多人在搜「微信小程序 spring boot 求职招聘」时最真实的处境：手里有一份能跑通业务闭环的代码，但技术栈停在几年前，想升级又怕把业务逻辑改崩。这套求职招聘系统正好卡在这个位置上——它把职位发布、简历投递、企业审核、消息通知这条主链路完整跑通了，后端用 SSM 打底，同时预留了向 SpringBoot 迁移的空间。适合两类人：一类是想拿它当小程序全栈练手的新手，照着跑一遍就能理解招聘类产品的数据流转；另一类是手里有类似老项目、想看看怎么把 SSM 平滑迁到 SpringBoot 的熟手，它的分层结构和依赖注入方式给了很清晰的改造切口。

2. 技术栈与目录结构：SSM 打底，SpringBoot 留门

2.1 后端分层与依赖选型

这套系统的后端是标准的 SSM 组合：Spring 负责 IoC 和事务，SpringMVC 处理 HTTP 请求分发，MyBatis 做 ORM 映射。数据库用 MySQL，连接池常见做法是配 Druid，缓存层如果要做职位列表的高频读取，一般会挂 Redis。小程序端通过 wx.request 调后端 REST 接口，返回 JSON，不涉及服务端渲染，所以后端本质是一个纯 API 服务。

为什么说它「可升级 SpringBoot」？因为它的 Spring 配置虽然写在 XML 里，但 Bean 的划分是按功能模块切的，没有把业务逻辑硬编码进配置文件。升级时主要做三件事：把 XML 里的 Bean 定义搬到 @Configuration 类或直接用注解扫描，把 web.xml 里的 DispatcherServlet 注册换成 SpringBoot 的自动配置，把外置的 Tomcat 换成内嵌容器。业务代码里的 Service 和 Mapper 几乎不用动，这是它比那些把逻辑塞进 Servlet 的老项目好迁的地方。

依赖版本上，原文没给具体号，按这个场景下合格开发最可能用的组合：Spring 4.x 或 5.x、MyBatis 3.4+、MySQL 5.7/8.0、JDK 8。如果你要直接上 SpringBoot，建议选 2.7.x 这个过渡版本，它对老式 XML 配置的兼容性最好，等业务跑稳了再往 3.x 跳。

2.2 目录结构拆解

一个能跑起来的 SSM 项目，目录一般长这样，我按职责把关键路径标出来：

src/main/java/com/recruit/ ├── controller/ # 接口层，处理小程序请求 │ ├── JobController.java │ ├── ResumeController.java │ └── UserController.java ├── service/ # 业务逻辑层 │ ├── JobService.java │ └── impl/JobServiceImpl.java ├── mapper/ # MyBatis 映射接口 │ └── JobMapper.java ├── entity/ # 数据库实体 │ └── Job.java └── util/ # 工具类，如统一返回、Token 解析 src/main/resources/ ├── mapper/ # MyBatis XML 映射文件 │ └── JobMapper.xml ├── spring-*.xml # Spring 配置 └── jdbc.properties # 数据库连接

这个结构里最值得关注的是 controller 和 service 的边界。招聘类业务里，职位列表要按关键词、城市、薪资区间做组合筛选，这种查询逻辑如果写在 controller 里，升级时会被 SpringBoot 的注解搅得更乱。这套代码把它放在 service 层拼装查询条件，controller 只做参数校验和结果包装，迁移时这一层几乎零改动。

2.3 小程序端与后端的接口约定

小程序端不直接连数据库，所有数据都走后端接口。常见的接口划分是：用户模块负责登录和身份切换（求职者/企业），职位模块负责发布、搜索、详情，简历模块负责创建和投递，消息模块负责通知。后端统一返回一个包含 code、msg、data 的 JSON 结构，小程序端根据 code 判断成功失败。

这里有个容易忽略的点：小程序的登录态不是靠 Session 维持的，而是用 wx.login 拿到的 code 换 openid，后端生成一个自定义 Token 返回给前端，后续请求带在 header 里。这套系统如果用的是拦截器校验 Token，升级 SpringBoot 时要把拦截器注册方式从 XML 的 mvc:interceptors 改成 WebMvcConfigurer 的 addInterceptors，逻辑本身不变。

3. 核心模块拆解：职位发布与简历投递的完整链路

3.1 职位发布接口的实现

职位发布是招聘系统的入口，涉及企业身份校验、字段完整性检查、数据库写入三步。先看 controller 层的写法：

@RestController @RequestMapping("/api/job") public class JobController { @Autowired private JobService jobService; // 发布职位，企业身份由拦截器校验后放入 request attribute @PostMapping("/publish") public Result publish(@RequestBody Job job, HttpServletRequest request) { // 从拦截器解析出的企业 ID，避免前端伪造 Long companyId = (Long) request.getAttribute("companyId"); if (companyId == null) { return Result.fail("请先登录企业账号"); } job.setCompanyId(companyId); // 必填字段校验，标题和薪资区间不能为空 if (job.getTitle() == null || job.getSalaryMin() == null) { return Result.fail("职位名称和薪资不能为空"); } jobService.publish(job); return Result.success("发布成功"); } }

这段代码的关键在 companyId 的来源。很多新手写的时候直接从请求体里取 companyId，结果被前端一改就能替别的公司发职位。这里从拦截器解析 Token 后塞进 request attribute，是更稳的做法。参数上，Job 实体至少包含 title、city、salaryMin、salaryMax、education、experience、description、companyId 这些字段，具体看你的表设计。

Service 层的 publish 方法做两件事：补全创建时间和默认状态，然后调 Mapper 插入。

@Service public class JobServiceImpl implements JobService { @Autowired private JobMapper jobMapper; @Override public void publish(Job job) { job.setCreateTime(new Date()); // 新发布的职位默认待审核，审核通过才在小程序端展示 job.setStatus(0); jobMapper.insert(job); } }

状态字段 status 是招聘类系统的常见设计：0 待审核、1 已上线、2 已下线。小程序端查职位列表时只查 status=1 的记录，这样企业乱发的内容不会直接暴露。升级 SpringBoot 时，@Service 和 @Autowired 都能直接用，唯一要改的是如果原来在 XML 里配了事务通知，要换成 @Transactional 注解。

3.2 简历投递与状态流转

简历投递比职位发布多一层关系校验：求职者不能重复投同一个职位，企业不能看到未投递的简历。先看投递接口：

@PostMapping("/deliver") public Result deliver(@RequestBody DeliverDTO dto, HttpServletRequest request) { Long userId = (Long) request.getAttribute("userId"); if (userId == null) { return Result.fail("请先登录求职者账号"); } // 检查是否重复投递 int count = deliverService.countByUserAndJob(userId, dto.getJobId()); if (count > 0) { return Result.fail("你已经投递过该职位"); } Deliver deliver = new Deliver(); deliver.setUserId(userId); deliver.setJobId(dto.getJobId()); deliver.setResumeId(dto.getResumeId()); deliver.setStatus(0); // 0 已投递，1 已查看，2 邀请面试 deliver.setCreateTime(new Date()); deliverService.save(deliver); return Result.success("投递成功"); }

这里的 DeliverDTO 只暴露 jobId 和 resumeId，userId 同样从 Token 解析，防止替别人投递。状态流转是招聘系统的核心：求职者投递后状态为 0，企业查看后改为 1，发起面试邀请改为 2。小程序端根据这个状态渲染不同的按钮文案，后端只需要在查询时把状态带出去。

对应的 Mapper XML 里，统计重复投递的 SQL 很直接：

<select id="countByUserAndJob" resultType="int"> SELECT COUNT(*) FROM deliver WHERE user_id = #{userId} AND job_id = #{jobId} </select>

注意这里没有加逻辑删除条件，如果你的表设计里有 is_deleted 字段，要补上AND is_deleted = 0，否则用户撤销投递后重新投会被误判为重复。这是我在类似项目里踩过的坑，撤销功能一上线，重复投递的校验就失效了。

3.3 统一返回与异常处理

小程序端解析响应时最怕格式不统一，所以后端要有一个 Result 包装类：

public class Result<T> { private int code; // 0 成功，非 0 失败 private String msg; private T data; public static <T> Result<T> success(T data) { Result<T> r = new Result<>(); r.code = 0; r.msg = "ok"; r.data = data; return r; } public static <T> Result<T> fail(String msg) { Result<T> r = new Result<>(); r.code = 500; r.msg = msg; return r; } }

配合一个全局异常处理器，把 Service 抛出的业务异常统一转成 Result.fail，避免堆栈信息直接返回给小程序端。SSM 里用 @ControllerAdvice + @ExceptionHandler 实现，升级 SpringBoot 后这套注解原样保留，这也是它好迁的一个原因——Web 层的注解在两代框架里是通用的。

4. 本地跑通：从数据库到小程序联调

4.1 数据库初始化与配置

拿到源码后第一步是建库。项目一般会带一个 sql 文件，里面包含建表语句和少量测试数据。执行前先确认 MySQL 版本，5.7 和 8.0 在驱动类名上有区别：5.7 用 com.mysql.jdbc.Driver，8.0 用 com.mysql.cj.jdbc.Driver，并且连接串要加时区参数。

# 登录 MySQL 后执行 CREATE DATABASE recruit_db DEFAULT CHARACTER SET utf8mb4; USE recruit_db; SOURCE /path/to/recruit.sql;

字符集一定要用 utf8mb4，招聘信息里经常出现生僻字和表情符号，utf8 存不下会报错。建完库后改 jdbc.properties：

jdbc.driver=com.mysql.cj.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/recruit_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai jdbc.username=root jdbc.password=你的密码

serverTimezone 这个参数在 MySQL 8.0 下不加会直接连不上，报时区错误，这是新手最常见的翻车点。

4.2 后端启动与接口自测

SSM 项目传统上要配 Tomcat，如果你拿到的是 Maven 项目，可以在 pom 里加 tomcat7-maven-plugin 直接跑：

mvn clean package mvn tomcat7:run

启动后先用 Postman 或 curl 测登录接口，拿到 Token 后再测职位列表。注意 SSM 项目的拦截器可能对静态资源也生效，如果访问接口返回 404 但日志没报错，先检查 web.xml 里的 url-pattern 是不是配成了 /，改成 /api/更稳妥。

如果你打算直接升级到 SpringBoot 再跑，把 pom 里的 spring-webmvc 换成 spring-boot-starter-web，加一个启动类：

@SpringBootApplication @MapperScan("com.recruit.mapper") public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } }

然后把原来的 XML 配置用 @ImportResource 引进来过渡，等业务验证没问题再逐步拆成注解配置。这样改的好处是启动方式变了，但业务代码一行没动，出问题容易定位。

4.3 小程序端配置与联调

小程序端在微信开发者工具里打开，找到请求封装的文件，把 baseUrl 改成你本机的地址。本地调试时开发者工具要勾选「不校验合法域名」，否则请求会被拦。真机预览时本机地址不通，常见做法是用内网穿透工具映射一个临时域名，或者直接部署到测试服务器。

联调时重点看三个接口：登录换 Token、职位列表分页、简历投递。如果列表能出来但投递报 401，说明 Token 没带上或者拦截器放行规则写错了。小程序端的 header 里要带Authorization: Bearer xxx，后端拦截器解析时注意去掉前缀。

5. 避坑与排查：升级和联调中最容易翻车的几处

5.1 现象：升级 SpringBoot 后接口全部 404

原因通常是包扫描路径不对。SSM 时代 controller 的扫描写在 XML 里，升级后 @SpringBootApplication 默认只扫描启动类所在包及其子包。如果你的启动类放在 com.recruit 下，而 controller 在 com.recruit.controller，那没问题；但如果启动类放到了别的包，就要手动加 @ComponentScan("com.recruit")。解决方式是先看启动日志里有没有 RequestMapping 的注册记录，没有就是没扫到。

5.2 现象：MyBatis 报 Invalid bound statement

这是 mapper 接口和 XML 没对上的典型症状。SSM 里靠 mapperLocations 配置 XML 路径，升级后如果没配 mybatis.mapper-locations，XML 就不会被加载。解决是在 application.yml 里补上：

mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.recruit.entity

另外检查 XML 里的 namespace 是否和接口全限定名完全一致，差一个字母都会报这个错。

5.3 现象：小程序请求返回 200 但数据为空

先看后端日志有没有执行 SQL。如果 SQL 执行了但结果为空，多半是查询条件里带了 status=1 而测试数据全是 status=0。招聘系统的测试数据经常忘了改状态，导致列表页空白。解决是手动 update 几条记录的状态，或者在测试环境把状态过滤去掉。

5.4 现象：简历投递后企业端看不到

检查投递表的 user_id 和企业的 company_id 是不是关联错了。有些实现里投递记录只存了 job_id，企业端查询时要 join 职位表才能拿到 company_id，如果 join 条件写错，数据就查不出来。建议在投递时就冗余一个 company_id 字段，查询时少一次 join，也避免关联错误。

5.5 现象：中文职位描述存进数据库变问号

这是字符集问题。除了建库时用 utf8mb4，还要检查连接串里的 characterEncoding 和表的字符集。如果表已经建成了 latin1，改连接串也没用，要执行 ALTER TABLE 转换。升级 SpringBoot 后如果换了连接池，注意连接池的初始化 SQL 里有没有 set names。

6. 二次开发：把招聘系统改成垂直行业工具的改造思路

这套代码最有价值的二次开发方向，是把它从通用招聘改成某个垂直领域的撮合工具，比如家教、兼职、实习。改造的核心不在页面，而在数据模型和匹配逻辑。

第一步是收窄职位字段。通用招聘的 Job 表字段很宽，垂直行业往往只需要几个关键维度。比如做家教撮合，核心字段是科目、年级、授课方式、时薪，其他字段可以隐藏或删掉。改的时候不要直接删表字段，先在前端隐藏，后端保留，等业务稳定再清理，避免改一半发现还要用。

第二步是改匹配逻辑。通用招聘是求职者搜职位，垂直撮合往往是双向推荐。你可以在 JobService 里加一个 match 方法，根据求职者的简历标签和职位的需求标签算一个匹配度，按分数排序返回。匹配算法不用复杂，标签交集除以并集就够了，先跑通再优化。

public double matchScore(Resume resume, Job job) { Set<String> resumeTags = parseTags(resume.getTags()); Set<String> jobTags = parseTags(job.getTags()); if (resumeTags.isEmpty() || jobTags.isEmpty()) { return 0; } Set<String> intersection = new HashSet<>(resumeTags); intersection.retainAll(jobTags); Set<String> union = new HashSet<>(resumeTags); union.addAll(jobTags); return (double) intersection.size() / union.size(); }

这段代码里 parseTags 把逗号分隔的标签串转成 Set，matchScore 返回 0 到 1 之间的匹配度。你可以把它用在列表排序上，也可以设一个阈值只推高分职位。参数上，标签的粒度要控制好，太细会导致交集为空，太粗又失去区分度，一般每个简历和职位控制在 5 到 10 个标签比较合适。

第三步是验证改造效果。改完匹配逻辑后，不要只看接口返回，要造几组测试数据跑一遍：一个简历标签和职位完全重合的，一个部分重合的，一个完全不重合的，看排序是否符合预期。我一般会在 Service 层写一个 main 方法直接调，比启动整个项目快得多。

最后说个习惯。每次改完数据模型，我都会强制走一遍「发布职位 → 投递简历 → 企业查看 → 状态流转」这条主链路，不管改的地方看起来多不相干。因为招聘系统的表关联太密，动一个字段经常在另一个环节炸出来。从那以后我每次升级依赖或改表结构，都先把这条链路跑通再提交，省了很多回头查的时间。希望帮到你。

本文还有配套的精品资源，点击获取