企业官网建设流程全解析

做校园勤工助学平台这类项目，我最常被问到的一句话是：“这题是不是被做烂了？”说实话，这类题目的确不少见，但真正能完整跑通、被老师认可、还能拿去面试讲出亮点的项目，并不太多。很多人把“Spring Boot + 微信小程序”当成一个固定模板，跟着教程敲了一遍，结果数据库几张表、接口十几个，登录逻辑还是一知半解，一问三不知。我今天想聊的这个“校园勤工助学平台”，是我在两届毕业设计指导里反复打磨过的一个版本，也是我认为在难度、完成度、展示效果三者之间平衡得比较好的一个方案。

这个平台要解决的核心问题很直白：校园里的兼职信息太分散，勤工助学中心的岗位表靠纸质或QQ群传递，学生报名靠私聊，结算靠人工统计，数据一多就乱。所以它的设计目标也很清楚——用微信小程序作为学生端入口，用Spring Boot提供后端接口，把“岗位发布、学生报名、管理员审核、录用、结算、信用评价”这一整条闭环线上化。适合正在筹备毕业设计的计算机专业学生，也适合想给学校做一套真实可用系统的开发者参考。下面我把这套系统的完整设计和实现思路拆开讲，从表结构到接口、从wx.login到小程序自定义导航栏，每一步都给出可复现的方案，顺便把我踩过的坑也一并放出来。

1. 项目定位与需求拆解

1.1 校园兼职场景里的真实痛点

做系统之前，先把业务场景想清楚比写代码重要一万倍。真实校园里的勤工助学，存在三个层面都很明显的问题。

第一是信息不对称。岗位发布渠道太多，校内官网、辅导员通知、学生群、兼职中介，各有各的信息源，学生找岗位靠运气，招聘方招人靠转发。这在技术上对应的是“岗位信息缺少统⼀的发布与检索入口”，也就是项目的一个核心业务模块：岗位管理。

第二是信任与安全问题。学生被骗押金、工资被拖欠、冒充校内招聘的校外中介混进群里，这类事情在校园里屡见不鲜。对应到系统设计上，就需要“单位认证、岗位审核、信用评价”三个环节相互配合。管理员不只是发公告的角色，更是系统里的风险控制节点。

第三是流程混乱。报名靠私聊，约定靠口头，结算靠Excel，链条一长就出纰漏。对应到系统设计上，就是必须把“报名—录用—结算”做成有状态、可追踪的完整流程，每一步改动都有记录，每一次状态变更都有依据。

把这三点翻译成系统功能，就是三端角色：学生端（微信小程序）、招聘方端（小程序内嵌雇主角色或独立商家端页面）、管理后台（Web端）。我最终选的是“小程序双角色 + Web管理后台”的组合，学生和校内用人单位共用小程序，后台单独做管理页面，这也是目前同类题目里性价比最高的一种方案。

1.2 角色与核心业务流程

系统里一共有三类用户，各自的职责和权限必须先梳理清楚，后面的表结构、接口设计全都围绕角色权限展开。

学生用户的核心操作是：注册登录、浏览岗位、按条件筛选兼职、报名、查看报名状态、确认工作时长、提现工资、对用人方进行评价。招聘方（校内部门、老师、运营校内兼职点的商家）的核心操作是：提交单位认证资料、发布岗位、审核学生报名、发放工资、管理自己发布的历史岗位。管理员的核心操作是：用户认证审核、岗位审核、处理违规举报、查看全站数据报表、手动干预异常订单。

业务主流程很经典，但实现细节要细致处理：招聘方认证通过后发布岗位 → 系统进入待审核状态 → 管理员审核通过后岗位上架 → 学生浏览岗位并报名 → 招聘方在申请列表里选择录用 → 学生完成工作后由招聘方确认并发起结算 → 系统生成工资流水 → 学生端确认收款 → 双方互评。每一步都要有状态字段支撑，后面我会专门讲状态机的设计。

2. 技术选型与整体架构设计

2.1 为什么锁定Spring Boot和微信小程序

技术选型是毕业设计答辩时被问得最多的问题，所以选择理由一定要能讲出逻辑，而不是“因为别人都用”。

Spring Boot的优势不光是“快速搭建”。它的自动配置机制让项目起步成本极低，一个main方法启动内嵌Tomcat，省去传统SSH/SSM繁琐的XML配置；Spring生态整合能力很强，Spring Security做认证授权、Spring Data Redis做缓存、MyBatis-Plus做数据访问，都是开箱即用。另外，Java语言本身在校园环境中的普及度最高，遇到问题能查到的资料也最多，这对需要独立完成项目的学生来说是非常重要的隐性加分项。

微信小程序端的优势则在于“触达成本低”。国内学生的微信使用率几乎是百分之百，小程序免安装、扫码即开，非常契合校园高频但低时长的使用场景。相比开发Android/iOS双端App，一套代码覆盖两端，开发和维护的成本都低很多。用户授权登录后可以直接拿到OpenID，天然就是一套轻量级的实名体系，省去短信验证码和邮箱验证的麻烦。

有人会问：那为什么不用UniApp？我对UniApp的评价是可以，但要看目标。如果你打算以后还做跨端App、鸿蒙适配，UniApp确实有优势；但如果只是为毕业设计交一个完成度高的作品，原生小程序 + Spring Boot这种“最通用”的组合，反而更稳妥。既然题目明确写的是“Spring Boot框架下微信小程序”，那就老老实实用官方原生开发，不要把简单问题复杂化。

2.2 整体架构与项目结构划分

整体架构采用前后端完全分离的经典模式，这种模式在面试时也最容易讲清楚。

小程序端负责UI渲染和用户交互，通过微信的wx.request发起HTTP请求；后端以RESTful API的形式提供数据服务；MySQL承担数据持久化；Redis用来做短信防刷、Session/Token缓存，以及部分热点数据的缓存。生产环境下可再加Nginx做反向代理与SSL证书卸载，小程序上线强制要求HTTPS，Nginx加上免费证书就能轻松满足。

后端项目结构上，我推荐按“controller/service/mapper/entity/vo/dto”分层，不要全堆在一个类里。有一个常见误区是“分层太多繁琐”，实际上对毕设算是积极作用——答辩时展示代码规范度，这是非常大的加分点。考虑到项目周期，也不用引入太重的微服务体系，单模块足够。

小程序端目录方面，我习惯按页面目录 + 公共模块拆分：pages下按tab页和子页面划分，utils放request请求封装、工具函数，components放自定义组件，static放静态图片。分包加载不用急着做，等项目过审后还有余力再优化，但页面目录如果一开始就乱，后面改起来才是真要命。

## 3. 数据库设计与核心表结构 ### 3.1 实体关系梳理 这个系统的表数量，我建议控制在10到12张之间。太少显得业务单薄，太多会拖累开发进度。核心表我理出了8张：用户表、单位认证表、岗位表、报名表、结算流水表、工资提现表、评价表和公告表。 用户表是所有角色共用的基础表，用userType字段区分学生与招聘方，比把学生和招聘方拆成两张表更灵活，因为现实中一个人可能既是勤工俭学的学生，也是某个校内团队招人的负责人。单位认证表专门记录招聘方提交的资质材料，审核通过后该用户才能发布岗位。岗位表是业务核心，所有发布内容、薪资信息、状态都在这张表里。报名表是学生与岗位之间的关联，也是整个流程里状态最复杂的一张表。 结算流水表和提现表很多人会忽略，但“工资穿透”恰恰是这个项目区别于普通信息发布平台的关键。没有结算流水，整个“勤工助学”就只是一张招贴栏，谈不上平台。这两张表的设计我稍后详细说。 ### 3.2 核心表字段设计细节 这里的字段不是随便拍脑袋，而是我在反复迭代后确认下来的最小完备集合，并且每一个关键字段的设计都对应一个真实踩坑经验。 **用户表**：openid（登录唯一凭证）、nickname、avatar、phone、userType（1学生/2招聘方）、roleStatus（正常/被封禁）。openid必须加唯一索引，并且永远不要用主键承载业务逻辑。userId才是主键，openid只是授权标识。这个区分早期容易想不明白，但一旦你接入第三方登录就能体会为什么这么设计。 **岗位表**：是整张表里的权重之王。字段包括title、description、workType（校内岗位/校外兼职）、salaryType（按小时/按次/按月）、salaryAmount、salaryUnit、workStartTime、workEndTime、recruitCount、appliedCount、status（0待审核/1招聘中/2已结束/3已下架）、publisherId、auditRemark。 这里有个关键点：appliedCount是冗余字段。你没看错，冗余是刻意为之。每次报名成功都count++，而不是每次统计时去报名表里count，好处是列表页不需要JOIN操作就能直接显示“已报名/总名额”，列表加载速度能明显提升。代价是必须保证数据一致性，事务里同时更新报名表和岗位的appliedCount，避免超录。 **报名表**：applyStatus状态机是整个系统的灵魂。我设计了五个核心状态：0已提交、1已录用、2已完成待结算、3已结算、4已取消/未录用。后面接口设计部分会单独演示这个状态机如何流转，这里先留个印象：不要用两个布尔字段去表示状态，一个int状态字段远比双布尔清晰、可扩展。 **结算流水表**：orderNo（唯一业务单号）、applyId、studentId、publisherId、amount、status（待支付/已支付/已到账）、createTime、payTime、transactionId。每个字段都是用来回答“钱去哪了”这个问题的。唯一单号必须由后端生成，格式建议用时间戳加随机数，不要迷信雪花算法，在学生这种低并发场景里反而更简洁。 **用户表字段补充**：我建议加一个creditScore信用分字段，初始100，每次投诉成立或未按时履约就扣分，对同一学生和招聘方都生效。这个方法能让“信用评价”不只是一个空壳功能，而是真正进入业务决策。比如信用分低于80的招聘方，新岗位发布后会被自动要求管理员二次审核。 我用一张表列出关键表的主要字段和约束，方便你对照建库： | 表名 | 关键字段 | 说明/约束 | |---|---|---| | user | userId, openid, userType, creditScore | openid唯一索引 | | job | jobId, title, salaryType, salaryAmount, recruitCount, appliedCount, status | appliedCount冗余用于列表性能 | | apply_record | applyId, jobId, studentId, publisherId, applyStatus | 联合唯一索引(jobId, studentId) 防重复报名 | | settlement | orderNo, applyId, amount, status | orderNo唯一，事件可追溯 | | withdrawal | withdrawalId, studentId, amount, status | 与结算流水配合，防止“虚假已付” | | evaluation | evalId, orderId/applyId, fromUser, toUser, score, content | 只允许现实履约过的订单评价 | ### 3.3 防重复报名的数据库层设计 讲到防重复报名，先明确一个很常见的坑：只要在小程序端做了“按钮置灰”就以为万事大吉，这是绝对不行的。用户快速双击、网络异常导致的重复请求，以及并发环境下两个请求同时到达后端，按钮灰化完全拦不住。 解决这个问题，靠数据库唯一约束是最省心的方案。在apply_record表里加联合唯一索引(jobId, studentId)，只要同一个学生对同一个岗位发起第二条报名SQL，数据库就会直接报DuplicateKeyException，后端捕获后返回“你已报名过该岗位”，比在代码里先用select查一次判断再insert要快且安全得多。这一招在答辩时拿出来讲，是很好的加分项，会显得你真正理解了并发控制的基本思想。 ## 4. 后端核心功能实现 ### 4.1 微信登录鉴权与用户体系建设 微信小程序登录的完整链路是：小程序端调用wx.login拿到一个临时code，把这个code传给后端；后端拿着code加上appid和secret请求微信的code2Session接口，换回openid和session_key；后端用openid去user表查询，查到就返回登录态，查不到就自动注册一个新用户。 后端建议不要直接拿openid当用户主键。我给每次登录成功生成一个自定义Token，格式上可以直接用UUID，也可以稍微讲究一点，用header.payload.signature的JWT格式。毕设场景里UUID简单可靠，但不建议直接裸存：最好在Redis里以“userId:token”作为键存一份，并设置7天过期，这样注销和踢人下线都好处理，比JWT纯粹的“不可撤销性”更可控。 核心伪代码逻辑大致是这样： ```java public class AuthService { public String wxLogin(String code) { // 1. 请求微信接口获取openid String openid = wxApi.code2Session(code); // 2. 查询用户是否存在 User user = userMapper.selectByOpenid(openid); if (user == null) { // 3. 首次进入自动注册，默认学生身份 user = new User(); user.setOpenid(openid); user.setUserType(1); user.setCreditScore(100); userMapper.insert(user); } // 4. 生成登录态Token String token = UUID.randomUUID().toString().replace("-", ""); redisTemplate.opsForValue() .set("LOGIN:USER:" + token, user.getUserId(), 7, TimeUnit.DAYS); return token; } }

注意第二步“自动注册”之后，小程序需要再请求一次/user/info拿到完整用户资料，前端跳转到个人信息完善页，补填姓名、学号、手机号。这是很多新手忽略的一个交互细节：不要指望用户一进小程序就把所有信息填好，移动端产品都遵循“先低门槛进入，再渐进式完善”的设计原则。

写接口时，Token统一从请求头Authorization里取，后端写一个拦截器（HandlerInterceptor）把所有非白名单路径拦下，在PreHandle里解析Token并从Redis取值校验用户身份。不要在每个Controller里重复写检查逻辑，这是代码可维护性的底线。

4.2 岗位发布、审核与列表接口设计

岗位发布是招聘方端最核心的接口。调用链上有一个前置条件：招聘方必须已经通过管理员认证。所以岗位发布接口第一步先判断当前用户roleStatus，未认证直接抛出“请先完成资质认证”。

岗位发布请求参数很杂，我用一个JobCreateDTO接收，在Controller层做基础校验，然后组装成Job实体。服务层里把状态置为0待审核，插入数据库。审核操作在管理后台完成，管理员看到待审核列表，点通过或拒绝，拒绝时必须填auditRemark，直接把原因展示在小程序端，这个体验细节很值得做。

岗位列表接口我推荐内部带一个条件查询JobQueryDTO，支持分页、按工作类型筛选、按关键词模糊搜索、按薪资排序。用MyBatis-Plus的LambdaQueryWrapper实现非常简洁：

public Page<Job> pageJobs(JobQueryDTO dto) { LambdaQueryWrapper<Job> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Job::getStatus, 1) // 只展示招聘中 .like(StringUtils.hasText(dto.getKeyword()), Job::getTitle, dto.getKeyword()) .eq(dto.getWorkType() != null, Job::getWorkType, dto.getWorkType()) .orderByDesc(Job::getCreateTime); return jobMapper.selectPage(new Page<>(dto.getPageNum(), dto.getPageSize()), wrapper); }

注意一个性能细节：查询列表时不要直接select全部字段，description这种大文本字段单独摘出来，列表页只查概要字段，进入详情页再全量查询。这个写法和前面appliedCount冗余字段的思路是一致的，都是在“性能”和“实现复杂度”之间取得平衡。

4.3 报名、录用、结算的完整闭环与状态机

报名接口需要同时做三件事：插入报名记录、给岗位表appliedCount加一、判断是否已满员。这三步必须在同一个事务里完成。应用的典型代码如下：

@Transactional(rollbackFor = Exception.class) public ApplyResult applyJob(Long jobId, Long studentId) { Job job = jobMapper.selectByIdForUpdate(jobId); // 行级锁防超录 if (job == null || job.getStatus() != 1) { throw new RuntimeException("岗位不存在或已停止招聘"); } if (job.getAppliedCount() >= job.getRecruitCount()) { throw new RuntimeException("岗位已报满"); } // 联合唯一索引兜底，防止同一人重复报名 ApplyRecord record = new ApplyRecord(); record.setJobId(jobId).setStudentId(studentId).setApplyStatus(0); applyRecordMapper.insert(record); // 更新已报名人数 job.setAppliedCount(job.getAppliedCount() + 1); jobMapper.updateById(job); return ApplyResult.success(); }

这里我用了selectByIdForUpdate悲观锁，并发场景下确保不会出现“最后一个名额被多个人抢到”。你可能会问：加了唯一索引为什么还要行锁？因为唯一索引防的是“同一个人重复报名”，行锁防的是“多人同时报满后仍然超卖”。这两者解决的问题不一样。

录用与结算的状态流转逻辑可以概括成一条清晰的时间线：报名成功(0已提交) → 招聘方审核并录用(1已录用) → 工作完成后招聘方发起结算并等待学生确认(2待确认) → 学生确认到账(3已结算)。中途招聘方拒绝报名，则状态切换到4已取消/未录用。

结算接口涉及资金变动，订单号必须在服务端生成，绝不能让前端传；金额计算规则要写清楚，比如按小时计薪的岗位，实际工作小时数需要招聘方填写，平台端只做上限校验，防止超出岗位标准工时乱填。

4.4 Redis与消息通知的轻量级方案

消息通知在这里不推荐引入消息队列，阶段不符。轻量做法是后端建一张通知表，学生端通过定时刷新或下拉刷新来拉取未读消息。小程序本身没有常驻后台，真正要主动推送应该用微信订阅消息，但这个有严格模板审核限制，作为毕设可以先做“站内信模式”，在答辩时说明“生产环境可替换为微信订阅消息”即可。

Redis在这里的用途很务实：验证码缓存、登录Session、岗位列表首页热门岗位缓存。热门岗位缓存建议缓存五分钟，加一个手动清理接口，管理员更新岗位状态后主动删除对应缓存。不要一上来就搞分布式缓存，项目规模还撑不起那么大的架构，完成优先。

5. 微信小程序端实现细节

5.1 页面结构与tabbar设计

小程序页面我按四个tab组织：首页（岗位推荐）、岗位列表、消息、我的。首页放搜索框和分类入口，非常适合答辩演示时给评委快速展示业务逻辑；岗位列表页走常规的筛选列表；消息页展示系统通知和报名状态通知；我的页面囊括个人资料、我的报名、工资账户、评价记录。

页面文件可以这样组织：

pages/ ├─ index/ # 首页 ├─ jobs/ # 岗位列表 ├─ job-detail/ # 岗位详情 ├─ apply/ # 我的报名 ├─ message/ # 消息中心 ├─ profile/ # 我的 ├─ wallet/ # 钱包/余额 ├─ publish/ # 发布岗位 └─ auth/ # 身份认证提交

tabBar使用微信自带的原生tabBar就好。首页想做得好看一点可以加一个swiper轮播广告位，里面放勤工助学中心的通知，底部再加一个“极速报名”入口，这样的首页结构对演示效果提升很大，又不增加多少开发成本。

5.2 登录流程与请求封装

小程序的登录必须处理好“静默登录”和“主动登录”的关系。我的做法是：小程序启动后先调用wx.login拿code，把它传给后端，接口返回token和“是否新用户/是否资料完善/是否认证通过”的状态。如果新用户，弹窗引导去完善资料；如果老用户，直接用token走业务。

请求封装是避免重复代码的关键。在utils/request.js里封装一个promise化的wx.request请求方法，统一注入Authorization header，统一拦截HTTP 401跳转登录页，统一处理超时和网络错误，并在服务端错误时把后端返回的message用wx.showToast弹给用户。用心封装这一层，你会发现后面写业务页面非常省事：

const request = (url, method, data) => { return new Promise((resolve, reject) => { wx.request({ url: BASE_URL + url, method, data, header: { 'Content-Type': 'application/json', 'Authorization': getToken() }, success: (res) => { if (res.data.code === 200) { resolve(res.data.data); } else if (res.data.code === 401) { reLogin(); reject(res.data); } else { wx.showToast({ title: res.data.message, icon: 'none' }); reject(res.data); } }, fail: (err) => { wx.showToast({ title: '网络异常', icon: 'none' }); reject(err); } }); }); };

5.3 岗位详情页与报名按钮的交互状态管理

岗位详情页是学生完成核心操作的地方，按钮状态机必须严格对应后端状态。我把按钮状态拆成了五种情况：岗位已下架或已满员时，按钮置灰显示“已报满/已结束”；当前用户已报名但未录用时显示“已报名，等待通知”；已录用且任务未完成时显示“工作反馈入口”；已完成后显示“已结算查看评价”；未报名的学生显示“立即报名”。

这五种状态靠一个接口返回的detail对象里的两个字段组合判断：job.status + 当前用户对该岗位的applyStatus。前端拿到详情后一次性算好按钮文案和状态码，比每次都在模板里写if elseif清爽很多。

5.4 顶部导航栏高度与安全区适配

自定义导航栏听起来很麻烦，但在勤工助学平台里却很有必要。默认导航栏只能显示页面标题，如果我们想要在导航栏里放一些自定义按钮，比如首页的扫码入口，或者希望导航颜色跟随主题色，就必须使用自定义导航。这里有一个经典配置：在页面json里"navigationStyle": "custom"，然后页面上自己画一个导航栏占位。

计算导航栏高度有“标准答案”式公式：状态栏高度statusBarHeight + 胶囊按钮高度menuButton.height + 胶囊距离顶部间距menuButton.top × 2，得到一个近似的总导航高度。我通过调用uni.getSystemInfo和uni.getMenuButtonBoundingClientRect来动态计算：

const { statusBarHeight } = wx.getSystemInfoSync(); const menu = wx.getMenuButtonBoundingClientRect(); const navHeight = menu.height + (menu.top - statusBarHeight) * 2; const totalHeight = statusBarHeight + navHeight;

这个公式很容易被忽视，但一旦做错，真机预览时胶囊按钮会和你的自定义导航按钮重叠，非常掉档次。因为不同手机的胶囊位置并不一致，用固定高度一定会出问题。

底部使用TabBar时不用额外处理安全区，但如果是在详情页做底部的固定按钮（比如“立即报名”），就必须在样式上加padding-bottom: env(safe-area-inset-bottom)，确保按钮不会被iPhone底部小黑条遮挡。这种细节在演示时虽然看不到，但在审核与答辩演示环节，很容易因为页面观感扣印象分。

6. 管理后台与数据统计模块

6.1 管理端功能梳理

管理后台我建议用现成的Web前端模板快速搭建，不必从零写HTML/CSS。后端接口能力和小程序完全共享同一套，只需要再增加几个管理端专用的接口。

管理端最核心的几个模块：用户管理列表（支持搜索、禁用/恢复）、单位认证审核（查看资质材料图片、通过/驳回）、岗位审核列表（操作岗位上下架）、结算异常处理、全站数据看板。

数据看板不需要特别华丽，三个数字卡片即可碾压很多“空壳毕设”：今日新增岗位数、今日报名人次、累计结算金额。下面再放一个近7天报名趋势图和一个岗位类型占比饼图，图表库可以直接在管理前端用ECharts，非常成熟，配置简单。

6.2 统计数据的后端实现

统计接口包含管理员权限校验，这部分不要漏。实现上很直接，写一个DashboardController，通过MyBatis-Plus的applyRecordMapper来做查询。

@GetMapping("/admin/dashboard") public AdminDashboardVO dashboard() { AdminDashboardVO vo = new AdminDashboardVO(); // 近7天报名趋势 List<Map<String, Object>> trend = applyRecordMapper .selectMaps(new QueryWrapper<ApplyRecord>() .select("DATE(create_time) as date, count(*) as count") .ge("create_time", DateUtil.offsetDay(new Date(), -7)) .groupBy("DATE(create_time)") .orderByAsc("DATE(create_time)")); vo.setApplyTrend(trend); // 今日新增岗位数 vo.setTodayJobCount(jobMapper.selectCount(new QueryWrapper<Job>() .apply("TO_DAYS(create_time) = TO_DAYS(NOW())"))); // 累计结算金额 vo.setTotalSettledAmount(settlementMapper.selectOne( new QueryWrapper<Settlement>().select("IFNULL(SUM(amount),0) as total") ).getTotal()); return vo; }

这些SQL都不复杂，但能直观证明你已经理解了“聚合统计”的基本思路，也方便扩展。有一点要提醒，统计类SQL里别用小写命名不一致，MyBatis-Plus对表字段大小写敏感，一旦数据库字段和实体映射对不上，报错会非常隐蔽，建议字段命名一律采用下划线风格并开启mapUnderscoreToCamelCase配置。

7. 测试部署与上线踩坑记录

7.1 本地联调：从小程序开发工具到后端服务

本地联调最容易出问题的就是域名校验。小程序开发工具中，默认勾选“不校验合法域名”，这个在开发期必须勾上，否则localhost请求直接报“url not in domain list”。但要注意，这只是开发期的妥协，上线时必须在微信公众平台后台配置request合法域名，并且必须是HTTPS。

后端本地跑通之后，小程序端可以直接请求http://localhost:8080，如果要用手机真机预览，就必须保证手机和电脑在同一局域网，并把localhost改成电脑的局域网IP。不要用127.0.0.1，因为手机访问的是电脑的局域网地址。

开发期藏着一个非常大的坑：微信开发者工具默认不校验合法域名，但你换到真机预览后，如果真机预览调试模式开启，有时也仍然能访问；一旦关闭调试模式，真实环境就会严格校验。所以我的建议是：从第一天就把后端接口地址写成变量，本地配置一份、线上配置一份，不要到最后一个环境一个环境改。

7.2 文件上传与图片处理的注意点

岗位发布和单位认证里都要用到图片上传。图片处理我建议后端统一接收base64或临时文件，再转存到MinIO。Spring Boot集成MinIO其实非常简单，只需要引入minio依赖，配置好endpoint、accessKey、secretKey，然后封装一个MinioService做文件上传和URL生成即可：

@Value("${minio.endpoint}") private String endpoint; public String uploadFile(MultipartFile file, String objectName) { MinioClient minioClient = MinioClient.builder() .endpoint(endpoint) .credentials(accessKey, secretKey) .build(); boolean exists = minioClient.bucketExists(BucketExistsArgs.builder() .bucket(bucketName).build()); if (!exists) { minioClient.makeBucket(MakeBucketArgs.builder() .bucket(bucketName).build()); } minioClient.putObject(PutObjectArgs.builder() .bucket(bucketName) .object(objectName) .stream(file.getInputStream(), file.getSize(), -1) .contentType(file.getContentType()) .build()); return endpoint + "/" + bucketName + "/" + objectName; }

小程序端上传图片要特别注意：wx.chooseMedia选图后，不是直接把临时路径当url放到image标签里，而是要再调wx.uploadFile把它先上传到服务器，获取到服务器返回的永久URL后再展示。很多新手会直接把tempFilePath往数据库里存，结果一刷新页面图片就全裂了。这个逻辑上的顺序差，是文件上传功能里最常见的一个翻车点。

另外要给上传文件加大小和格式限制。小程序端通过sizeType控制选择原图或压缩图，服务端再加一层文件大小校验。一个完整的毕设，建议至少对图片做文件类型白名单拦截，防止上传恶意文件，这层安全校验不难写，但很多人不做。

7.3 常见问题速查表

我把自己和历届学生在这套系统里反复踩过的典型问题整理成一个速查表，每一条都对应过线上事故：

8. 项目后续扩展与个人实操体会

8.1 从毕设走向真实可用系统的几个扩展方向

如果做完主体功能还有余力，有四个扩展方向投入产出比最高。

第一个是“微信订阅消息通知”。学生报名后、被录用后、工资到账后，推送微信订阅消息提醒，闭环体验立刻上一个档次。实现上不难，就是调用subscribeMessage.send接口，难点在于模板ID需要在小程序后台申请，且每个模板都有固定的字段要求，需要仔细匹配。

第二个是信用体系升级。目前只做了信用分扣减，可以增加申诉流程、评价权重、黑名单自动拦截等。比如信用分低于阈值的用户，自动进入“高危名单”，报名前弹窗风险提示。

第三个是移动端缓存优化。把首页的热门岗位缓存到本地storage，设置过期时间，让用户在弱网环境也能看到上一次浏览的岗位列表。这是“微信小程序设置缓存时间”这类需求在真实项目里的落地形态。

第四个是视频答辩素材录制。答辩前把小程序在真机上一遍操作流程录下来，特别是学生报名、管理员审核、工资结算这条全链路，可以剪成2分钟演示视频。这个视频在毕业答辩时非常有说服力，不要让评委自己盯着屏幕看操作。

8.2 我做完这个项目之后最深的几点体会

这套系统我前后带过不少学生落地，如果说有什么话想反复强调，我的体会非常具体。第一，状态机是这套系统的灵魂，岗位有生命周期，报名有生命周期，结算也有生命周期，如果你能把这种“状态流转”意识建立起来，后面不管做任何管理系统，都能触类旁通。第二，“会写接口”和“能上线”是两码事，面试官最在意的是你思考过并发下的数据一致性，思考过安全校验，思考过手机真机与开发工具的环境差异，这些才是区分“抄代码”和“做项目”的分水岭。第三，不要追求把所有功能都堆上去，一个功能做到完整闭环，比十个功能各自半吊子要好得多，明确主链路“发布-审核-报名-录用-结算-评价”，把它做到极致，你就能把整个项目讲得很扎实。

这个项目做完之后，你可以很自然地向更复杂的系统演进：引入消息队列做异步通知、引入Redis Cluster做分布式会话、引入定时任务做未完成订单的自动关闭。基础打得牢，后面这些技术栈的引入都只是水到渠成而已。