随缘惜情每年一到开题季，就有学弟学妹来问我：毕设能不能做个校园二手商城？我一般会反问一句：为什么不做成“校园服务”？同样是 springboot 后端加微信小程序前端，服务类业务的角色关系、状态流转、权限设计比纯商品交易更有得写，也更能撑起毕业设计的完整度。很多做“校园二手”的人，最后都会卡在商品规格、退款、运费这类真正电商才需要的复杂逻辑上，真正做出一个能完整跑通、能讲清业务闭环的人反而不多。
这篇文章就按“springboot校园服务微信小程序”这条路线，完整梳理一套从选题、功能规划、技术选型、数据库设计、后端接口、小程序页面到上线发布和答辩演示的落地思路。适合两类人看：一类是准备做计算机毕业设计但还没确定具体方案的学生，另一类是已经选了这个题、代码写了一半但总被版本、登录态、资源路径、AppID这类问题卡住的同学。我会尽量把每一步背后的原因讲清楚，而不是只丢结论。
1. 选题价值与功能规划：这个题目为什么适合做毕设
1.1 服务类业务比商城更适合毕业设计展示
“校园服务”本身不是一个孤立的点，而是一个能包含多种真实场景的分类壳。跑腿取快递、代带饭、失物招领、打印拼单、运动搭子、维修上报、自习室占座互助，都可以作为其中一个服务分类，小程序端以“服务大厅”的方式呈现即可。
相比于校园二手商城，服务类业务天然具备几大优势。第一，用户角色清晰，平台里有发布服务的学生、有接单的学生、还有负责内容审核的管理员，三种角色天然需要权限控制，这在论文和答辩里都能成为实打实的模块；第二，业务闭环短，发布服务、浏览详情、接单、推进状态、完成、评价，整个链路完整却不复杂；第三，订单字段相对简单，不需要设计SPU、SKU、购物车、库存这类电商概念，减少了不必要的开发量。
评委最常问的一句话是“这个系统解决了什么实际问题”。校园服务的回答非常直接：学校里同学之间有很多临时性、碎片化的互助需求，但缺少一个统一的信息撮合平台，微信群消息又容易被刷掉。这个回答贴近场景，谁都能听懂，又能引出信息发布、订单撮合、状态同步这些技术点。
1.2 功能清单：先保证 MVP 闭环，再加分
毕设最怕的不是功能少，而是没闭环。一个“能登录、能发布、能接单、能状态流转、管理员能管”的小程序，远好过一个看起来菜单很多但核心流程走不通的后台。我把常用的功能切分成了下面这样，先标出 MVP，再加可选加分项。
| 功能域 | 具体功能 | 涉及角色 | MVP | 对应核心数据表 |
|---|---|---|---|---|
| 用户 | 微信授权登录、头像昵称维护、学生身份资料 | 学生 | 是 | user |
| 首页 | 轮播图、服务分类、服务列表搜索 | 学生 | 是 | category, service_order |
| 发布服务 | 填写标题、描述、金额、联系方式、上传图片 | 学生 | 是 | service_order |
| 接单流程 | 服务详情、抢单接单、状态更新 | 学生 | 是 | service_order |
| 个人中心 | 我发布的订单、我接到的订单、资料修改 | 学生 | 是 | service_order |
| 评价 | 已完成订单互相评价 | 学生 | 否 | evaluation |
| 管理后台 | 服务分类维护、违规服务下架、用户状态管理、简易统计 | 管理员 | 是 | category, user |
| 消息通知 | 站内消息或微信订阅消息 | 学生 | 否 | message |
这里想提醒一句：如果你想增加项目的工作量体现，更推荐加“Web 管理后台”，而不是在小程序端堆叠一些不常用页面。管理后台可以用 Vue 3 + Element Plus 做一套简易界面，调用同一套 Spring Boot 接口，通过角色权限隔离普通用户接口和管理端接口。这样一来，论文里的系统架构图会显得完整很多，“前端小程序 + 后端服务 + 管理端页面”三层结构也更好讲。但如果你时间已经很紧，管理后台可以退化成小程序端只对 admin 开放入口，不一定非要单独做一套 Web。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术选型与项目结构：先把版本和目录定下来
2.1 后端版本：Spring Boot 2.7.x 还是 3.x
看到热搜词里频繁出现“springboot 版本太高”，我就知道太多人在这里吃过亏。如果你的毕设指导老师没有硬性要求必须使用最新框架，我建议后端直接锁定 Spring Boot 2.7.18 + JDK 1.8 这个组合。
原因非常实际。第一，2.7.x 是 Spring Boot 2.x 系列的最后一个稳定版本，截至今天仍然有大量资料、课程、论文模板围绕这一版本写作，遇到问题随便一搜就能找到对得上的答案。第二，绝大多数学校的毕设环境、老师提供的框架代码，甚至实验室电脑上的 JDK、IDEA 版本，都还是围绕 Java 8 配置的，强行上 Spring Boot 3.x 意味着 JDK 至少 17，有些老电脑和旧版 IDEA 本身就跑不起来。第三，Spring Boot 3.x 做了很多包结构迁移，原来的 javax.servlet 变成了 jakarta.servlet，导致很多从网上复制的老代码在你项目里直接标红或启动失败，这种无谓的排错非常消耗精力。
如果确实因为课题要求被指定使用 Spring Boot 3.x，那也不是不行，但至少要做好三件事：JDK 升级到 17 或更高，所有依赖里原来是 javax 前缀的替换为 jakarta 前缀，MyBatis-Plus、Knife4j 等组件必须找对应 Spring Boot 3 的独立 starter 版本，不要直接照抄 2.x 时代的依赖。尤其是 Knife4j，在 Spring Boot 3 下要引入的是 knife4j-openapi3-jakarta-spring-boot-starter，版本号也需要单独确认。
建议选型组合如下：
| 组件 | 推荐版本 | 说明 |
|---|---|---|
| JDK | 1.8 | 和 Spring Boot 2.7.18 搭配最稳 |
| Spring Boot | 2.7.18 | 2.x 收官版本，资料最多 |
| MySQL | 8.0 | 如果机器旧可退到 5.7，注意驱动差异 |
| MyBatis-Plus | 3.5.x | 提供 BaseMapper 和分页插件，省去大量 XML |
| Knife4j | 4.x（对应 boot2） | 接口文档界面比原生 swagger 好用 |
| Hutool | 5.8.x | 封装 HttpUtil、JWTUtil、JSONUtil，很方便 |
| Lombok | 随 Boot 管理 | 减少实体 getter/setter 代码 |
这套组合最舒服的地方在于：你搜到的十篇博客里至少有七八篇能直接对应到相同版本语境，不需要一边写代码一边做“版本翻译”。
2.2 后端项目结构与分层思想
后端建议按标准的分层结构建包，既符合毕设要求，也方便自己维护。
code复制com.campus.service
├── common // 通用返回结果、异常处理、常量
├── config // 拦截器、资源映射、跨域配置
├── controller // 接收请求、参数校验
├── service // 业务逻辑、事务控制
├── mapper // MyBatis-Plus Mapper 接口
├── entity // 数据库实体
└── utils // JWT、日期等工具类
Controller 只做一件事：接收参数、调用 Service、返回结果。Service 里面写真正的业务逻辑和事务。很多学生喜欢把 SQL 写在 Controller 里省事，一旦被问到“项目分层是怎么设计的”就答不清楚。而在毕设答辩里，分层设计本身就是一个高频问题。
Service 层要特别重视事务。比如用户发布一条服务，要同时更新服务表记录和用户发布统计时，必须用 @Transactional 保证要么都成功，要么都回滚。回答“为什么项目里要使用事务”时，举一个订单发布的实际例子，比背事务四大特性有用得多。
2.3 小程序端用原生还是 uni-app
小程序端建议优先考虑原生 WXML、WXSS、JS，不推荐随意上 uni-app。原因并不复杂：原生小程序在微信开发者工具里写出来的效果就是最终线上效果，少一层编译转换，排查问题的时候最直接。
uni-app 本身没有问题，很多商用项目也在用。但如果你是为了毕设在一个月内快速交付，而之前没有接触过 HBuilderX 和 uni-app 的编译链路，那学习成本会被低估。热搜里有一条“为什么运行到微信小程序模拟器中，小程序 id 还是原来的”，这种问题几乎都出现在跨端工具的项目配置上。因此我会在第六章详细讲 AppID 继承问题，但更建议多数人直接选原生方案把精力花在业务逻辑上。
3. 数据库建模与订单状态：把最容易被问倒的部分写扎实
3.1 核心表设计以及字段背后的用意
数据库设计是整个项目的地基，也是答辩时老师最愿意深挖的部分。这里给出一套通用且不过度设计的表结构参考。
用户表 user，核心字段建议如下：
- id：主键，使用雪花算法或自增；
- openid：微信用户唯一标识，必须加唯一索引；
- nickname、avatar：用户昵称和头像；
- role：角色，0 表示普通学生，1 表示管理员；
- student_no、phone、real_name：选填，便于展示校园服务场景中的联系方式；
- status：账号状态，0 正常，1 禁用；
- create_time、update_time：创建和更新时间。
有一点必须提醒：微信登录接口返回的 session_key 不要直接存数据库。这个字段用于解密手机号等敏感数据，存下来会增加泄露风险，而且毕设场景基本用不到，只需在登录响应后丢弃即可。
服务分类表 service_category，字段包括 category_id、parent_id、category_name、icon、sort、status。如果希望页面更丰富，可以设计二级分类，例如“跑腿代办”下再分“代取快递”“代买零食”。但如果不做二级分类，建议去掉 parent_id 字段，不要为了复杂度而复杂度。
服务订单表 service_order 是核心表，需要重点设计：
- publisher_id：发布人 ID；
- accepter_id：接单人 ID，初始为空；
- category_id：服务分类；
- title、description：服务描述；
- price：金额，decimal 类型；
- status：订单状态，int 类型；
- image_urls：图片地址，多个用逗号分隔或 JSON 字符串存储；
- address、contact：服务地点和联系方式；
- create_time、accept_time、finish_time、cancel_time：各阶段时间；
- cancel_reason：取消原因。
很多学生会纠结服务图片要不要单独建一张表。对毕设场景来说，完全没有必要。把多张图片的 URL 直接拼接成逗号分隔字符串存在 service_order.image_urls 一个字段里，查询一次就能拿全，代码也简单。代价是你不能对图片做独立的统计和管理，但毕设阶段不会用到这个能力。
评价表 evaluation 设计为 order_id 唯一约束加 rating 评分、content 内容、create_time。一个订单完成后最多只能评价一次，所以直接对 order_id