简介：这是一份面向计算机专业毕业生与课程设计者的校园服务平台毕业设计项目，技术栈为微信小程序前端、Java后端与MySQL数据库，完整覆盖用户、卖家、管理员三类角色的业务闭环，包含商品发布、订单管理、校园公告、后台管理等典型模块，适合用于毕设参考、答辩演示或二次开发学习。压缩包内包含1112个文件、约27.76MB，其中png/svg/jpg为界面与图标素材，js/vue/java构成前后端核心逻辑，wxml/wxss为小程序页面骨架与样式，sql为数据库初始化脚本，另有mp4演示视频、docx说明文档及一键启动/构建脚本，目录结构清晰，便于对照部署与功能梳理。目前已有140人浏览学习。这份资源提供完整的项目源码、操作演示录屏、部署说明和数据库文件，并附带项目构建脚本与常见配置，既能直接运行查看效果，也可帮助读者快速理解小程序与Java后端的交互方式，适合从0到1搭建同类校园服务平台时参考。
1. 校园服务平台毕设：看起来是“买源码”，实际是“拆项目”，拆什么决定答辩成绩
一句话说透这套题目的本质：它不是让你从零设计并实现一个高并发校园中台，而是让你在毕业设计的半年周期里，用一套结构清晰的微信小程序前端和 Java 后端，把校园二手交易、活动报名、失物招领、场地预约这类真实业务串成一条完整链路。源码、演示视频、说明文档、数据库文件打包好放在面前，真正拉开学生差距的不在“能不能跑”，而在“能不能把这个项目讲成自己的方案”。适合谁？Java 基础薄弱但需要一份能运行、能演示、能答得上追问的工程代码的人。能解决什么？一个接口文档、实体关系、权限校验都齐全的闭环项目，以及从环境重建到真机联调全流程的实战经验。能让你少熬几个通宵，但前提是你愿意把源码当成一份“施工图纸”，而不是期末答案。
2. 技术选型与总体结构：为什么“原生微信小程序 + Spring Boot”是这套毕设最稳的组合
2.1 前端为什么选原生微信小程序而不是 uniapp
你在热搜里会看到“uniapp 微信小程序打包”这类词，但如果毕设题目明确写的是“微信小程序+Java 后端”，我建议核心页面全部用原生 WXML、WXSS 与 JavaScript 实现，而不是套 uniapp。原生小程序在微信开发者工具里能直接运行和断点，不需要经过 HBuilderX 的编译链和云打包环节，少一层黑匣子，答辩时被问“这个页面是怎么渲染的”也能直接指向真实代码。uniapp 适合你有多端上线需求，但毕业设计的验收主体是学校老师，他们要看到的是你对一个平台的完整掌控，而不是多端适配能力。
原生小程序的另一个好处是 API 语义与文档一一对应：wx.request、wx.navigateTo、wx.getLocation、wx.openBluetoothAdapter。这些接口的入参、回调、失败分支都有官方说明可查，出问题时你能准确描述“哪个接口在什么机型上报什么错误”，这本身就是答辩加分项。
2.2 后端模块划分与源码包的读法
Java 后端在这个项目里几乎可以确定是 Spring Boot 体系，常见结构是 controller、service、mapper、entity、config 五层。拿到源码包，我建议不要从页面开始读，而是按这个顺序：pom.xml 里看依赖粒度，application.yml 里看数据源和端口，然后找 SQL 脚本重建数据库，最后用演示视频里的操作路径反向定位到对应的 Controller 接口。这个顺序能让你在半天内建立“按钮 → 接口 → SQL”的完整映射，而我们最容易犯的错是直接在 WXML 里找事件绑定，然后顺着 JS 一层层找下去，最后在十几个文件里迷失。
合理分层对于这个项目的意义不只是代码整洁。答辩时老师大概率会问“订单状态流转写在哪”，你需要能立刻说出“状态变量在 service 层更新，mapper 只负责持久化”这类话。如果源码的 controller 里直接拼 SQL，也不是不能跑，但你很难把这种设计讲得让人信服，所以拿到源码后，先把业务逻辑是否在 service 层这件事核实清楚。
2.3 数据库在“微信小程序 + Java”里的连接点
校园服务平台的数据量远不到大数据级别，MySQL 8.x 加 MyBatis-Plus 是常见做法。数据库在这个架构里的角色不是“存储容器”那么简单，它承担了业务规则的落地：用户表与角色表决定谁能发布闲置物品，预约表的时间段唯一索引防止同一个自习座位被两个人占用，订单表的状态字段驱动交易流程。这些约束如果只靠 Java 代码判断，会出现并发场景下的重复插入，所以在建表时就要通过索引和唯一键把业务边界立住。
表与表之间的关系也要按真实校园场景来建模。一个学生可以发布多件闲置物品，这是用户表与商品表的一对多；一个订单必须关联一个买家和一个卖家，这是订单表与用户表的两次外键关联；失物招领和活动报名各自独立成表，不与二手交易混在一起。关系清晰，后端 service 层写起来就不拧巴。
2.4 前后端接口约定与状态码设计
前后端分离项目实战中，最容易扯皮的就是接口约定。这个项目里，约定全凭一份接口设计文档来约束，常见做法是统一 JSON 结构：业务状态码 code 为 200 表示成功、401 表示未登录、403 表示无权限、500 表示服务端异常；data 字段返回业务对象或列表；msg 字段返回给用户看得懂的提示。分页接口的返回体建议固定为 total、current、size、records 四个字段，这样小程序端做“加载更多”时不需要关心数据库方言。
还有一个约定常被忽略：时间格式。后端返回的时间如果格式不统一，小程序端 new Date 解析会出兼容性问题。建议接口层把所有时间统一为字符串“yyyy-MM-dd HH:mm:ss”，前端不自行转换格式。
| 接口 | 方法 | 请求参数 | 返回 data 示例 |
|---|---|---|---|
| /user/login | POST | code、nickname、avatar | { token, userId } |
| /goods/page | GET | current、size、keyword、categoryId | { total, records[] } |
| /booking/add | POST | goodsId、startTime、endTime | { bookingId } |
| /found/publish | POST | title、description、images | { foundId } |
这个表格不是让你背下来，而是提醒你：拿到源码后的第一件事，就是把所有接口按这种粒度整理成一页纸。整理完，整个系统的数据流就立体了。
3. Java 后端从零跑通：配置、鉴权、跨域三件套
3.1 最小可运行的依赖与配置文件
后端能不能在本地快速启动，依赖选择比代码本身更关键。pom.xml 里常见的核心依赖是 spring-boot-starter-web、mybatis-plus-boot-starter、mysql-connector-java、jjwt、lombok。不要贪多，不要引入 dubbo、xxl-job 这类与校园平台无关的组件，依赖越多，版本冲突概率越大，而版本冲突是毕业设计启动阶段最容易遇见的坑。
<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3.1</version> </dependency> <dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt</artifactId> <version>0.9.1</version> </dependency> </dependencies>需要说明的是 mysql-connector-j 是 MySQL 8.x 驱动的新坐标，旧写法 mysql-connector-java 在新版本里已经迁移。如果你导入源码后报驱动类找不到，先检查这里是不是版本没对齐。resource 目录下的 application.yml 是第二个要核对的文件，主要看数据源和 MyBatis-Plus 配置。
server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/campus_service?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver servlet: multipart: max-file-size: 10MB max-request-size: 20MB mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0这里有两个参数对新手最关键。第一个是 serverTimezone=Asia/Shanghai，不加这个参数，MySQL 8 在连接时会报时区错误，项目直接起不来。第二个是 logic-delete-field，这是 MyBatis-Plus 的逻辑删除配置，字段值为 1 表示已删除，0 表示未删除。如果你删一条数据却查不到记录变少，多半是逻辑删除生效了，不是代码出 bug。
3.2 建表脚本与核心表设计
下面是一份比较典型的校园服务平台建表脚本核心片段，覆盖用户、商品、订单、预约、失物招领五张主表。细心的读者会发现，我没有写活动报名表，原因是很多校园服务平台的“活动”业务已经合并到预约体系里，报名一次活动本质就是预约一个名额。
CREATE TABLE `tb_user` ( `id` bigint NOT NULL AUTO_INCREMENT, `openid` varchar(64) NOT NULL COMMENT '微信openid', `nickname` varchar(64) DEFAULT '' COMMENT '昵称', `avatar` varchar(255) DEFAULT '' COMMENT '头像', `role` tinyint NOT NULL DEFAULT 0 COMMENT '0普通用户 1管理员', `deleted` tinyint NOT NULL DEFAULT 0, `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_openid` (`openid`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表'; CREATE TABLE `tb_goods` ( `id` bigint NOT NULL AUTO_INCREMENT, `user_id` bigint NOT NULL COMMENT '发布者ID', `title` varchar(100) NOT NULL, `description` text, `price` decimal(10,2) NOT NULL DEFAULT 0.00, `images` varchar(1000) DEFAULT '' COMMENT '图片路径,逗号分隔', `status` tinyint NOT NULL DEFAULT 0 COMMENT '0在售 1下架 2已卖出', `deleted` tinyint NOT NULL DEFAULT 0, `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_user_id` (`user_id`), KEY `idx_status` (`status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='闲置商品表'; CREATE TABLE `tb_booking` ( `id` bigint NOT NULL AUTO_INCREMENT, `user_id` bigint NOT NULL, `target_type` tinyint NOT NULL COMMENT '1自习座位 2器材 3活动', `target_id` bigint NOT NULL, `start_time` datetime NOT NULL, `end_time` datetime NOT NULL, `status` tinyint NOT NULL DEFAULT 0 COMMENT '0待审核 1已确认 2已取消', `deleted` tinyint NOT NULL DEFAULT 0, `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_user_id` (`user_id`), UNIQUE KEY `uk_target_time` (`target_type`, `target_id`, `start_time`, `end_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='预约表';标注一下需要留意的设计细节。tb_user 的 uk_openid 唯一索引很关键，微信登录拿到 openid 后，用“先查再插”或“直接插入冲突后查询”都能防止同一个人创建多个账号。tb_booking 的 uk_target_time 唯一索引是防止座位被重复预约的兜底手段，如果后端代码里的并发校验失效，数据库会直接拒绝第二条重复预约，这是数据正确性的最后防线。images 字段存的是逗号分隔的相对路径，不塞 base64，否则单条记录可以超过几兆，数据库同步和备份都会很痛苦。
CREATE TABLE `tb_order` ( `id` bigint NOT NULL AUTO_INCREMENT, `order_sn` varchar(32) NOT NULL COMMENT '订单号', `goods_id` bigint NOT NULL, `buyer_id` bigint NOT NULL, `seller_id` bigint NOT NULL, `amount` decimal(10,2) NOT NULL, `status` tinyint NOT NULL DEFAULT 0 COMMENT '0待付款 1已付款 2已完成 3已取消', `deleted` tinyint NOT NULL DEFAULT 0, `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_order_sn` (`order_sn`), KEY `idx_buyer_id` (`buyer_id`), KEY `idx_seller_id` (`seller_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单表'; CREATE TABLE `tb_found` ( `id` bigint NOT NULL AUTO_INCREMENT, `publisher_id` bigint NOT NULL, `type` tinyint NOT NULL COMMENT '1寻物 2招领', `title` varchar(100) NOT NULL, `description` text, `images` varchar(1000) DEFAULT '', `status` tinyint NOT NULL DEFAULT 0 COMMENT '0未解决 1已解决', `deleted` tinyint NOT NULL DEFAULT 0, `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_type` (`type`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='失物招领表';建表脚本执行完后，用 show tables 和 desc tb_user 验证一下结构。很多配有数据库文件的毕设会直接把建表语句写成一个 .sql 脚本，你需要确认里面的表名和实体类里的注解是否完全一致，包括大小写。MySQL 在 Linux 下表名大小写敏感，Windows 上默认不敏感，这种环境差异会带来非常隐蔽的报错。
3.3 JWT 登录与拦截器
微信小程序登录的常规链路是：wx.login 拿到临时 code，后端用 code 调微信接口换 openid，然后签发 token 返回小程序。毕设项目通常不会自己维护 session，因为 JWT 无状态特性正好匹配前后端分离架构，后端不需要存登录态，token 过期时间由签发时决定，这能省掉 Redis 的依赖。
@Component public class JwtUtil { @Value("${jwt.secret}") private String secret; @Value("${jwt.expire}") private Long expire; public String createToken(Long userId, String role) { return Jwts.builder() .claim("userId", userId) .claim("role", role) .setExpiration(new Date(System.currentTimeMillis() + expire)) .signWith(SignatureAlgorithm.HS256, secret) .compact(); } public Claims parseToken(String token) { return Jwts.parser() .setSigningKey(secret) .parseClaimsJws(token) .getBody(); } }这段代码里的 secret 不要写死在类里，放在 application.yml 的 jwt.secret 配置项中，每位同学部署时改成自己的随机字符串。expire 参数建议设 7 天，太短会导致小程序用户频繁重新登录，太长会有安全风险，毕设场景 7 天是一个比较平衡的值。
有了 token 生成工具，还需要一个拦截器来保护接口。注意要放行登录接口和图片静态资源，否则小程序第一次请求就会被 401 挡住。
public class AuthInterceptor implements HandlerInterceptor { @Autowired private JwtUtil jwtUtil; @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (token != null && token.startsWith("Bearer ")) { try { Claims claims = jwtUtil.parseToken(token.substring(7)); request.setAttribute("userId", claims.get("userId")); return true; } catch (Exception e) { // 解析失败说明token已过期或非法 } } response.setStatus(401); response.setContentType("application/json;charset=UTF-8"); response.getWriter().write("{\"code\":401,\"msg\":\"未登录或登录已过期\"}"); return false; } }代码里有一个容易被忽略的细节：token 写在请求头 Authorization 字段，并以“Bearer ”开头。这是业界的通用约定，小程序端的 request 封装必须把这一行拼对，否则后端永远解析不到 token。拦截器里把 userId 塞进 request attribute，后续 controller 方法里直接取值，避免每个接口都重复解析 token。
3.4 CORS 跨域配置与联调
微信小程序请求后端时不会触发浏览器跨域，因为小程序的运行环境不是浏览器。但你仍然需要配 CORS，原因是至少有三个场景会用到：一是你用浏览器调试 Swagger 或 Knife4j 接口文档；二是后期如果做一个简单的 Web 管理后台；三是在微信开发者工具里使用“不校验合法域名”模式时，某些版本的开发者工具会带 Origin 头。后端不配 CORS，这些场景全都会被浏览器拦截。
@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }联调时最典型的报错是“Access-Control-Allow-Origin”与请求头里的 Origin 不一致。如果你的项目里同时存在前端页面直连和调试工具连两种方式，allowedOriginPatterns 用“*”会省很多事。有些同学会把 allowCredentials 设为 false 来避开“Cannot use wildcard with credentials”的报错，但那样小程序里携带 token 的自定义请求头会被浏览器丢掉，得不偿失。
4. 微信小程序端实现：顶部导航栏高度、列表加载更多与蓝牙定位落地
4.1 自定义顶部导航栏：用系统信息算高度，别写死 64px
微信小程序的顶部导航栏高度不是一个固定值。iPhone 带刘海屏的机型状态栏高度通常在 44px 到 47px 之间，Android 机型普遍是 24px 到 30px，胶囊按钮的位置也随系统版本变化。如果你在 app.json 里把 navigationStyle 设成 custom，就必须自己处理这部分高度，否则自定义的标题栏会顶到状态栏里，或者离胶囊按钮太近。
获取导航栏高度的稳定做法是用 wx.getWindowInfo 拿到 statusBarHeight，用 wx.getMenuButtonBoundingClientRect 拿到胶囊按钮的位置信息。具体适配逻辑如下。
const getNavbarHeight = () => { const windowInfo = wx.getWindowInfo(); const menuButton = wx.getMenuButtonBoundingClientRect(); const statusBarHeight = windowInfo.statusBarHeight || 24; const menuButtonTop = menuButton.top; const menuButtonHeight = menuButton.height; // 导航栏高度 = (胶囊顶部 - 状态栏底部) + 胶囊高度 + 下方留白 const navBarHeight = (menuButtonTop - statusBarHeight) * 2 + menuButtonHeight; return { statusBarHeight, navBarHeight, totalHeight: statusBarHeight + navBarHeight }; };计算思路不复杂：状态栏和胶囊按钮之间的间隙通常等同于胶囊按钮到导航栏底部的间隙，所以用胶囊顶部减去状态栏高度的两倍，再加上胶囊高度，就是自定义导航栏的完整高度。把这组数值存到全局变量里，页面上的自定义头部组件统一读取，不要在每个页面重复计算。如果你在真机上发现标题文字偏上或偏下，多半是自己算的高度少了或多了 4px，用 iPhone 13 和一台 Android 低端机分别测一遍就能定位。
4.2 列表加载更多：分页参数、onReachBottom 与请求锁
校园服务平台里，二手商品列表和失物招领列表都要用“下拉加载更多”的交互。微信小程序已经提供了 onReachBottom 页面生命周期事件，不需要自己监听滚动事件。但真正实现时容易犯的两个错误是：一是在 onReachBottom 里重复发起请求，导致数据重复；二是在 setData 里直接往数组尾部拼接数据，造成渲染层数据量无限增长。
// pages/goods/list.js const app = getApp(); Page({ data: { goodsList: [], current: 1, size: 10, total: 0, hasMore: true, loading: false }, onLoad() { this.loadGoods(true); }, onReachBottom() { if (this.data.hasMore && !this.data.loading) { this.loadGoods(false); } }, async loadGoods(init) { if (this.data.loading) return; const current = init ? 1 : this.data.current + 1; this.setData({ loading: true }); try { const res = await app.request({ url: '/goods/page', data: { current, size: this.data.size } }); if (res.code === 200) { const records = res.data.records || []; const total = res.data.total || 0; // init时替换列表，loadMore时追加 const goodsList = init ? records : this.data.goodsList.concat(records); const hasMore = goodsList.length < total; this.setData({ goodsList, current, total, hasMore, loading: false }); } } catch (err) { this.setData({ loading: false }); wx.showToast({ title: '加载失败', icon: 'none' }); } } });关键点有三个。第一，loading 标志位必须放在请求之前，否则用户快速滚动到底部时会同时发起多个分页请求，数据顺序错乱。第二，current 的更新逻辑是核心：初始化时 current 为 1，加载更多时先自增再赋值，如果顺序写反，点击进入详情再返回时列表会从头开始。第三，hasMore 的判断标准是“当前已加载数量小于后端返回的 total”，不是“current 小于 total/size”，因为总条数可能正好被 size 整除，后一种写法会漏掉最后一页。
4.3 蓝牙定位场景：用蓝牙做校园室内定位辅助，先扫到设备再上报
校园服务平台里经常会加一个“室内容纳量查询”或“设备状态巡检”的功能。既然热词里有微信小程序蓝牙定位，这里展开讲一个落地场景：在图书馆自习室或实验室门口放几个低功耗蓝牙信标，小程序扫描到信标后，通过信标 ID 向服务端上报当前位置，实现“入室打卡 + 座位推荐”。这个方案的业务价值是，GPS 在室内完全失效，而蓝牙信标部署成本低，特别适合图书馆、体育馆这类场景。
const startScan = () => { wx.openBluetoothAdapter({ success() { wx.startBluetoothDevicesDiscovery({ allowDuplicatesKey: true, interval: 1000, powerLevel: 'high', success() { wx.onBluetoothDeviceFound((res) => { const devices = res.devices || []; const beacons = devices.filter(item => item.name && item.name.startsWith('CAMPUS_') ); if (beacons.length > 0) { // 取扫描结果中RSSI最强的信标上报位置 const target = beacons.reduce((prev, cur) => (cur.RSSI || -100) > (prev.RSSI || -100) ? cur : prev ); wx.request({ url: `${app.globalData.baseUrl}/checkin/beacon`, method: 'POST', data: { beaconId: target.deviceId, rssi: target.RSSI, timestamp: Date.now() } }); } }); } }); }, fail() { wx.showToast({ title: '蓝牙未开启', icon: 'none' }); } }); };这里有两个参数值得研究。allowDuplicatesKey 设为 true 表示允许同一个信标重复上报，这是为了实时性；如果做的是“进入区域触发一次”的业务，应该设为 false，并在拿到首次结果后主动调用 wx.stopBluetoothDevicesDiscovery。interval 是扫描间隔，单位毫秒，值越小越耗电但对信标响应越及时，毕设演示建议用 1000。最大的坑在于：蓝牙扫描在微信开发者工具里根本扫不到任何设备，必须用手机真机调试，同时把手机蓝牙和微信定位权限都打开，否则 wx.openBluetoothAdapter 永远走向 fail 分支。
5.4 请求封装：baseURL、token 注入与统一错误提示
如果每个页面都直接写 wx.request，你的代码会被“请求头拼接、401 处理、错误码提示”这三块重复逻辑塞满。正确做法是封装一个全局 request，返回 Promise，页面里用 async/await 调用。
// utils/request.js const app = getApp(); const request = (options) => { return new Promise((resolve, reject) => { wx.request({ url: `${app.globalData.baseUrl}${options.url}`, method: options.method || 'GET', data: options.data || {}, header: { 'Content-Type': 'application/json', 'Authorization': `Bearer ${wx.getStorageSync('token')}` }, success(res) { if (res.statusCode === 401) { // 登录态失效，跳转登录页并清空本地token wx.removeStorageSync('token'); wx.navigateTo({ url: '/pages/login/login' }); reject(res); return; } if (res.data && res.data.code === 200) { resolve(res.data); } else { wx.showToast({ title: res.data.msg || '请求失败', icon: 'none' }); reject(res); } }, fail(err) { wx.showToast({ title: '网络异常', icon: 'none' }); reject(err); } }); }); }; module.exports = request;baseURL 的值在开发阶段建议用 http://127.0.0.1:8080，并在微信开发者工具中勾选“不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书”，这样本地后端可以直接连。真机调试时，127.0.0.1 指向的是手机自身，你需要把 baseURL 改成电脑的局域网 IP，并确保手机与电脑在同一 Wi-Fi。request 封装里的 Authorization 头是后端拦截器能放进来的唯一渠道，改 token 的存储 key 时，前后端要一起改，否则会出现“有 token 但后端不认识”的灵异问题。
5. 从源码到可演示系统：数据库初始化、打包部署与性能边界
5.1 数据库初始化与演示数据核对
拿到数据库文件后，第一步不是在微信开发者工具里预览，而是把数据库先还原起来。用 MySQL 命令行或 Navicat 执行你手上的 .sql 脚本，执行完毕后，打开三张核心表检查演示数据的完整度。
mysql -u root -p campus_service < campus_service.sql如果导入时报错，大概率是 SQL 文件里的表已经存在，可以在命令行前加上 drop database if exists campus_service; create database campus_service; 两句，保证导入环境是全新的。导入完成后执行下面三条查询，分别核对商品、订单、预约的演示数据量。
SELECT COUNT(*) FROM tb_goods; SELECT COUNT(*) FROM tb_order; SELECT COUNT(*) FROM tb_booking;这里有一个很实用的检查技巧：演示视频里展示的每个功能，都要能在数据库里找到对应数据。比如视频里演示了“发布二手手机”，你就应该在 tb_goods 里找到一条 title 为“二手 iPhone”且 user_id 对应某个演示账号的记录。如果数据库里根本没有这条数据，说明源码包里的 SQL 与演示视频不是同一套数据，这时候需要按视频里的路径重新走一遍业务流程来造数据，否则答辩现场很容易出现信息对不上的尴尬。
5.2 后端启动与小程序导入顺序
后端和前端有严格的启动顺序。先启动后端，再用微信开发者工具导入小程序项目。如果顺序反过来，开发者工具会在编译时请求后端接口，超时后报了错，你会误以为代码有问题。
mvn spring-boot:run后端启动成功的标志不是控制台打出一串日志，而是能看到类似“Tomcat started on port(s): 8080”的地方，并且用浏览器直接访问 http://127.0.0.1:8080/goods/page?current=1&size=10 能返回 JSON。如果此接口返回 401，属于正常现象，说明拦截器生效；如果返回 404，请检查 @RequestMapping 里的路径是否以 /goods 开头。小程序端导入时，AppID 先用测试号，等真机调试时再换成自己的个人 AppID。测试号与正式 AppID 在 wx.login 获取 code 的流程上没有区别，但测试号无法调用部分开放接口，比如需要用户手机号授权的场景，需要提前说明这一点。
5.3 答辩演示：功能对照与数据准备
演示环节最怕的不是功能报错，而是操作路径与源码实现不一致。拿到项目后，按照演示视频把全部业务流程自己走一遍，并把每一条流程拆成“页面 → 按钮 → 接口 → 后端逻辑 → 数据变化”五个步骤，形成一页纸的对照表。这张表既是你的排练脚本，也是老师追问时的答题提纲。
| 演示功能 | 操作路径 | 关键接口 | 数据变化 |
|---|---|---|---|
| 微信登录 | 首页 → 点击登录 | POST /user/login | tb_user 新增记录 |
| 发布闲置 | 个人中心 → 发布闲置 | POST /goods/add | tb_goods 新增记录 |
| 预约自习座位 | 首页 → 座位预约 → 提交 | POST /booking/add | tb_booking 新增记录 |
| 确认订单 | 订单列表 → 点击确认收货 | POST /order/confirm | tb_order.status 变为 2 |
演示前把数据库里状态为“1”的订单改成“0”，把可能被误删的失物招领数据恢复好，给自己留一条干净的数据链路。最好准备两个演示账号：一个普通用户账号用于走发布与预约流程，一个管理员账号用于演示权限控制，比如下架违规商品。双账号能同时展示前端交互和后端权限校验，比单账号更有说服力，也更容易撑起答辩时间。
5.4 性能边界：分页、图片、接口响应应该做到什么标准
毕业设计不要求你做高并发压测，但基础性能规范还是要守住，否则演示时界面会卡顿到让你不敢操作。前端列表的分页 size 建议设在 10 到 20 之间，超过 20 条在小程序里渲染的时间明显变长；图片必须压缩后再上传，常见做法是将图片控制在 500KB 以内、分辨率不超过 1280px，后端存储用相对路径而非 base64。后端接口在本地环境下的响应时间应该控制在 200ms 以内，如果你发现某个接口超过 1 秒，先看 SQL 有没有走全表扫描，再看循环里有没有阻塞调用。
并发场景只建议做一层防护：预约表靠数据库唯一索引兜底，订单状态更新用乐观锁或版本号，不引入 Redis 分布式锁。你用不上，也讲不清楚，反而容易被追问到漏洞百出。性能测试也不要引入 JMeter 这类重型工具，打开开发者工具的 Network 面板，观察每个请求的耗时和资源体积，就能写出“接口平均响应 150ms、首页资源加载 300KB”这类可量化结论。
6. 避坑与常见问题：拿到毕设源码后的 5 个翻车现场
6.1 现象：导入数据库脚本时报语法错误
原因：数据库文件可能是用 MySQL 5.7 导出，你的本地环境是 MySQL 8.0，两者在 utf8mb4 排序、timestamp 默认值、索引命名等细节上有差异。解决：优先用源码包说明文档推荐的数据库版本；如果必须用新版，把 SQL 文件里的 ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 附近的注释和多余字符清掉，再手工执行 CREATE TABLE 语句片段，直到定位到报错的那一行。不要整文件反复导入，浪费时间且遮蔽真实错误。
6.2 现象：小程序请求后端一直转圈，最终报“request:fail”
原因：开发环境中 90% 是地址不通。常见场景是电脑开了防火墙阻止了 8080 端口的入站连接，或者真机调试时 baseURL 写成了 127.0.0.1。解决：先用电脑浏览器访问 http://127.0.0.1:8080 确认后端存活；再用开发者工具请求 http://localhost:8080，看是网络层错误还是 HTTP 状态码错误；最后在真机调试时把 baseURL 改成电脑的局域网 IP，并在手机浏览器里访问该 IP 加端口验证连通性。如果你用的是云服务器，还要检查安全组是否放行了 8080 端口，这一步属于服务器配置，不是代码问题。
6.3 现象：蓝牙相关功能在开发者工具里永远扫不到设备
原因：微信开发者工具基于 PC 的蓝牙适配能力是模拟的，不支持真实 BLE 扫描。解决：所有蓝牙功能必须用手机真机调试。操作路径是点击开发者工具右上角“真机调试”按钮，手机会自动打开项目，此时 wx.openBluetoothAdapter 才能正常工作。如果你的手机型号较老，还要在系统设置里给微信打开“位置权限”，因为 Android 系统的蓝牙扫描会间接依赖定位权限，缺了它不会报权限错误，但回调里一个设备都收不到。
6.4 现象：列表加载更多的数据与总条数对不上，首页出现重复数据
原因：onReachBottom 触发频率高于 setData 更新频率，或者你在加载数据时 current 自增与接口返回不是原子操作，导致后端返回了同一页数据。解决：在 loadGoods 函数开头加 loading 判断，并在请求结束后统一更新 current。另一个隐蔽原因是有多条记录 create_time 相同，order by create_time 的分页顺序不稳定，解决方法是排序条件改为 order by create_time desc, id desc，用主键打破时间戳的并列问题。
6.5 现象：后端返回的图片在小程序里显示不出来，控制台没有报错
原因：图片字段存的是相对路径，比如 /upload/2025/04/01/a.jpg，小程序拿到的完整地址变成了 http://127.0.0.1:8080/upload/2025/04/01/a.jpg。此时大概率是后端的静态资源映射没有配置，或配置的路径与图片实际存放目录不一致。解决：在 Spring Boot 里加一个资源映射，把 /upload/** 指向本地磁盘目录，再确认上传图片的代码里保存路径与返回路径一致。如果图片是 MySQL 中历史写入的，检查 images 字段开头是否有斜杠，前后端拼接 baseURL 时多一个斜杠会拼出双斜杠地址，再次请求就 404。
7. 进阶与验收：从“能运行”到“讲得清”的一周验收清单
项目能跑通只是第一关，真正拉开答辩差距的是你能不能把一个功能从页面讲到数据库，再从数据库讲回页面。我的个人习惯是，验收时用的不是代码行数，而是一张逐项打勾的清单。第一项是登录链路：前端 wx.login 获取 code，后端换成 openid，签发 token，之后每次请求携带 token，拦截器放行或拦截，这条线每个环节都要能画出图。第二项是列表链路：首页商品分页如何加载更多、字段如何组装、加载更多时 loading 如何阻止重复请求、hasMore 如何计算。第三项是状态流转：订单从待付款到已付款再到已完成，每一步修改哪张表的哪个字段，谁有权限修改。
验证技巧上我在毕业设计阶段用过两个效果很好的方案。第一个是给关键接口加一个简单的耗时统计，用一个 OncePerRequestFilter 记录每个请求的处理时间，把它输出到日志里。这样答辩时你能拿出“商品分页接口平均耗时 80ms”这种硬数据，比“系统很流畅”更有说服力。第二个方案是给所有查询接口加一个 explain 分析，确认没有全表扫描，用这个结果说明你对索引和 SQL 优化有真实理解。
有时间的话，再把项目里的一个小模块改成另一种实现，比如把 JWT 的解析结果用 AOP 切面注入到方法参数里，或者把 wx.request 封装换成基于 await 的版本。这种改动不会破坏现有功能，但会让你在回答“你做了什么优化”时有真正的差异点可以讲，而不是复述别人的代码。
我做毕业设计时最深的体会是：源码最难的部分不是读代码，而是把代码从“别人写的”变成“我能讲清楚的”。给数据库文件加一个字段注释，给 Controller 加一段接口说明，给小程序页面加一段数据流注释，这些动作做下来，源码里哪怕只有三五行是你亲手写的，答辩时你都更有底气。希望帮到你，拿去用，跑不通再回来查排查思路。
本文还有配套的精品资源，点击获取
