SpringBoot+微信小程序上门维修系统毕设全攻略：从搭建到答辩

做毕设选“SpringBoot + 微信小程序上门维修服务系统”这个题目的同学，我猜你大概率是冲着这个组合“技术够主流、业务够生活化、演示够直观”去的。这个题我太熟了，几乎每年答辩都能见到几个做类似同城服务选题的学生，但真正能把整个链路讲清楚、被答辩老师追问不倒的，十个里面也就两三个。这篇东西我不给你整虚的，直接按“选题拆方案、后端怎么搭、小程序怎么写、联调怎么调、论文答辩怎么讲”的顺序来，把该避的坑和该加分的细节全给你点透。

先把这个系统到底是个什么东西说清楚。它的业务模型很简单：用户家里水管漏水、空调不制冷、电路跳闸，打开微信小程序，按服务分类下单，系统推送给附近的维修师傅，师傅抢单或由平台派单，上门维修完成后用户在线支付并评价。整个闭环涉及三类角色：用户端小程序、师傅端小程序（或同一个小程序分角色）、后台管理端。对于毕设来说，这个业务规模刚刚好——复杂度够写出一篇像样的论文，但也不至于做到一半做不下去。

适合谁来参考？如果你正在准备计算机毕业设计，或者想做一个同城到家服务类小程序当作品集项目，这篇内容可以直接照抄思路。下面我拆开讲。

1. 毕业设计选题与整体方案设计

1.1 需求画像拆解：这个系统到底要解决什么问题

上门维修这个场景，核心痛点就四个：用户找不到靠谱师傅、师傅接单没有稳定渠道、价格不透明、服务过程不可追踪。你的小程序系统要做的，就是通过线上下单、状态流转、评价体系把这些问题解决掉。所以在写需求分析的时候，不要只写“用户登录、下单、支付”这种流水账，而是要说清楚你设计的每个功能点在真实场景中对应什么环节。

整个系统按角色拆，用户端需要：注册登录、服务分类浏览、下单预约、订单状态查看、在线支付、评价投诉、个人中心。师傅端需要：注册入驻审核、接单抢单、订单状态更新、完工结算查看、个人业绩统计。管理后台需要：服务分类管理、师傅入驻审核、订单管理、用户管理、数据统计。这样拆分出来，你的功能结构图直接就出来了，而且每一块都可以对应到具体的表结构和接口设计。

核心业务流转建议做成这样：用户选择服务分类（比如“家电维修”“管道疏通”）→ 填写地址和预约时间 → 提交订单进入“待接单”状态 → 师傅在师傅端看到可抢订单列表 → 师傅接单，状态变“已接单” → 师傅上门，点击“开始维修” → 维修完成，用户确认 → 用户在线支付 → 互评。这套流程里每个状态变化都要记日志，方便后期论文画状态图和写测试用例。

1.2 技术栈选型：为什么是SpringBoot加微信小程序

先回答那个经典问题：为什么前端选微信小程序而不是H5或者App？三个理由。第一，微信小程序免安装、用完即走，最符合“家里突然漏水，用户快速找维修师傅”这种应急场景；第二，微信自带登录授权体系，用户不需要注册账号，体验门槛低；第三，对于毕设而言，小程序开发者工具免费、调试方便、演示效果好，答辩现场直接扫码就能跑。

后端选SpringBoot就更好解释了。生态成熟、社区资料多，遇到问题随便搜都有答案；内嵌Tomcat，打包成jar就能跑，不用单独配服务器；Spring家族的东西写在简历上是加分项，面试也爱问。另外SpringBoot对快速开发太友好了，集成MyBatis-Plus、Redis、JWT、MinIO这些组件基本就是加依赖加配置的事，能让把精力放在业务逻辑而非环境搭建上。

有人会问要不要用uni-app？这个看你自己的情况。如果你只做微信小程序，原生语法完全够用，而且不用多一层编译。但如果论文里想体现“跨端”概念，技术上可以换成uni-app。我个人建议毕设走稳妥路线——原生微信小程序配SpringBoot，这条路最成熟，踩坑最少。

1.3 数据库设计与表关系规划

表结构设计直接决定了你论文里的E-R图好不好画，也决定了后面写代码顺不顺畅。核心表我建议按这个清单来：

订单表是重中之重。订单号建议用“日期+随机数”的格式，比如 20250615 加 6 位随机数，方便人眼识别和后期排查。地址信息一定要冗余一份快照到订单表里，不要只存用户ID再去关联查地址，因为用户后面改地址的话，历史订单的地址就会被改写。状态字段用int类型，每个数字对应含义，在代码里用枚举常量维护。再加一张订单状态日志表，记录每一次状态的变更，这个表在答辩时很好用，可以直接证明你考虑了数据可追溯性。

2. 后端SpringBoot工程搭建与核心功能实现

2.1 Maven工程脚手架搭建与实际目录分层建议

创建项目的方式有两种，一种是去Spring Initializr网站勾选依赖然后生成包，另一种是直接用IDEA的Spring Initializr功能新建。IDEA 2026版本里创建SpringBoot项目的入口在New Project -> Spring Initializr，选好JDK版本和依赖后等待下载就行。毕设环境我建议用JDK 8或JDK 11，不要一上来就上JDK 17或更高——热词里提到的“SpringBoot版本太高”问题，大多是JDK和SpringBoot版本不兼容导致的，比如SpringBoot 3.x要求JDK 17起步，且包名从javax.servlet变成了jakarta.servlet，很多老教程里的代码直接import javax就会编译报错。

依赖方面，毕设项目通常需要：spring-boot-starter-web、mybatis-plus-boot-starter、mysql-connector、lombok、hutool（工具类库，可选项）、jjwt（JWT库）、minio（对象存储）、spring-boot-starter-data-redis（如果做验证码或缓存）。Maven构建慢的问题，在settings.xml里配上阿里云镜像基本就解决了。

项目目录结构我推荐经典分层，不要花里胡哨：

com.example.repair ├── config // 配置类，如CORS、MybatisPlus分页插件、MinIO配置类 ├── controller // 接口层 ├── service // 业务层，接口+实现分开 ├── mapper // MyBatis-Plus的Mapper接口 ├── entity // 数据库实体类 ├── dto // 请求参数对象 ├── vo // 响应视图对象 ├── common // 统一返回结果、错误枚举、全局异常 └── utils // JWT工具、MinIO工具等

为什么要强调分包？因为答辩的时候老师一定会翻你的代码结构，如果你所有代码全堆在controller一个类里，印象分直接崩塌。分包清晰，说明你有工程化意识。

2.2 统一返回结构与全局异常处理

这是很多自学的同学最容易忽略、但规范项目必有的东西。前后端分离开发时，你不可能每个接口返回的格式都不一样，这样小程序端没法做通用处理。统一返回结构长这样：

@Data public class Result<T> { private Integer code; private String msg; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMsg("success"); result.setData(data); return result; } public static <T> Result<T> error(String msg) { Result<T> result = new Result<>(); result.setCode(500); result.setMsg(msg); return result; } }

全局异常处理用@RestControllerAdvice，把业务异常、参数校验异常、未知异常统一拦截，返回同一个格式。这样做的好处是小程序端请求封装的时候只需要判断code是不是200就行，不用每个接口单独处理异常情况。我在实际项目里见过太多因为异常格式不统一，前端联调时反复改代码的情况，这个坑你提前避开。

2.3 微信登录鉴权与JWT身份认证

微信登录的原理要先讲清楚：用户在小程序端调用wx.login得到临时凭证code，然后小程序把code发给你的后端，后端拿着code再加AppId和AppSecret去微信接口换取openid。openid是用户在你这个小程序下的唯一标识，基于它去查或建用户表记录。

获取openid的后端接口核心逻辑：

// 调用微信接口：GET https://api.weixin.qq.com/sns/jscode2session // 参数：appid, secret, js_code, grant_type=authorization_code // 返回：openid, session_key String url = "https://api.weixin.qq.com/sns/jscode2session?appid=" + appId + "&secret=" + appSecret + "&js_code=" + code + "&grant_type=authorization_code"; String result = restTemplate.getForObject(url, String.class); // 解析result，拿到openid

注意微信这个接口本身不能被在小程序端直接调用，AppSecret一旦暴露在客户端就等于是裸奔，所以必须走你的后端转发。拿到openid后，查用户表，如果没有就自动注册，有就直接登录，然后签发一个JWT返回给小程序端。JWT的载荷里放userId和角色，过期时间给24小时，小程序端收到后存到storage里，后续每个请求在header里带上。

// JWT生成示例 String token = Jwts.builder() .setSubject(userId.toString()) .claim("role", "user") .setExpiration(new Date(System.currentTimeMillis() + 24 * 60 * 60 * 1000)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact();

鉴权部分用拦截器实现。写一个Interceptor，实现HandlerInterceptor接口，在preHandle里从请求头取Authorization字段，解析token，校验通过就放行，异常就返回401。注册拦截器的时候注意用addPathPatterns指定拦截路径，excludePathPatterns放行登录相关的路径。这个设计在答辩时可以顺便展开讲“JWT无状态认证为什么适合分布式部署”，是很好的加分话题。

2.4 订单状态机与抢单并发处理

订单状态流转是整个项目最核心的业务逻辑。建议在代码里维护一个OrderStatus常量类：

public class OrderStatus { public static final Integer WAIT_ACCEPT = 0; // 待接单 public static final Integer ACCEPTED = 1; // 已接单 public static final Integer IN_PROGRESS = 2; // 维修中 public static final Integer WAIT_PAY = 3; // 待支付 public static final Integer FINISHED = 4; // 已完成 public static final Integer CANCELLED = 5; // 已取消 }

师傅抢单这里有一个并发问题值得专门设计：多个师傅同时抢同一个订单，如果直接用“先查询订单状态再更新”的写法，极可能出现两人都看到“待接单”，然后都去更新，造成一单多接。解决的思路有两个。简单可靠的是用MySQL的乐观锁，在订单表加一个version字段，更新时带上where version=?，影响行数为0就说明被别人抢了。进阶一点的是用Redis的setnx做分布式锁，抢单时先加锁再更新，释放锁要处理超时问题。毕设阶段用乐观锁完全够，而且逻辑简单好解释：

int rows = workOrderMapper.updateStatusByVersion(orderId, OrderStatus.WAIT_ACCEPT, OrderStatus.ACCEPTED, workerId, version); if (rows == 1) { // 抢单成功 } else { // 已经被别人抢了 }

派单策略可以做成手动派单加自动派单可选：管理员在后台指定师傅，或者系统按师傅技能分类和当前待处理订单数智能派单。后者你能写一个简单的分配算法，论文里还能多一张流程图。

2.5 文件上传与MinIO集成：让图片存储更像真实项目

毕设项目里用户报修时上传故障照片、完成后上传维修凭证，这些都是图片上传需求。本地磁盘存储不是不行，但有两个问题：重启容易丢、非本机访问不了。云OSS要钱要配置，对学生来说也不是最优解。MinIO这个开源对象存储就非常合适，完全私有化部署，没有额外费用。

SpringBoot集成MinIO的步骤概括为三步：

<dependency> <groupId>io.minio</groupId> <artifactId>minio</artifactId> <version>8.5.7</version> </dependency>

配置项写到application.yml里：endpoint（MinIO服务地址）、accessKey、secretKey、bucket名称。然后写一个MinioConfig配置类，注入一个MinioClient的Bean。工具类提供两个核心方法：上传文件返回文件名，获取访问URL。上传时要注意文件名不要用用户原始文件名，防止重名和路径穿越，建议用UUID或时间戳重命名。MinIO控制台和SpringBoot要部署在同一台内网机器上的话，小程序端访问图片时不能用内网IP，要在桶的策略里配置成公网可访问的URL，或者通过Nginx做一下反向代理。

2.6 Redis的合理应用场景（别为了用而用）

很多毕设同学听到“技术亮点”就想着把Redis塞进来，但用不好反而画蛇添足。这个项目里Redis合适的场景有：手机验证码存储（5分钟过期）、师傅位置缓存（实时坐标短期存储）、热点服务分类缓存。验证码用Redis的setex设置过期时间，天然匹配验证码的使用模式。服务分类这种不常变的数据，第一次查询后缓存到Redis，后面直接走缓存，这就是典型的缓存穿透、缓存雪崩的答辩题目切入点。但注意别把订单这类核心数据放进Redis做持久化存储，MySQL才是主存储，Redis只做辅助，这个主从关系要在答辩时说清楚。

3. 微信小程序端开发与关键技术实现

3.1 工程结构、tabBar与页面规划

微信小程序的工程结构主要分成这么几个文件：app.json是全局配置，包括页面注册、window样式、tabBar；app.js是全局生命周期；utils目录放公共工具；pages目录下每个页面一个文件夹，包含wxml、wxss、js、json四个文件。

tabBar建议放三个：首页、订单、我的。首页展示服务分类和服务项目，订单页面展示我下单的订单列表并区分状态标签，我的页面放个人资料、地址管理、售后入口。如果你是“一个程序两种角色”的设计，师傅登录后看到的页面结构就要有所区分，可以在登录逻辑里判断用户角色，然后通过switchTab或redirectTo跳转到不同的tabBar页面。

页面顶部导航栏高度在iPhone X及以上机型会有刘海，热词里提到“微信小程序顶部导航栏高度”，实际是不同机型适配的问题。简单粗暴的做法是自定义导航栏，用wx.getSystemInfo获取statusBarHeight和menuButtonBoundingClientRect来计算高度；省事一点的做法是用默认导航栏，需要适配的元素只有安全区域，给底部加padding-bottom: env(safe-area-inset-bottom)就行。毕设阶段我建议直接用默认导航栏，把精力放在核心功能上。

3.2 微信小程序请求封装与登录态管理

小程序端请求不要每个页面都写一遍wx.request，一定要封装。在utils目录下新建request.js，用Promise包一层：

const request = (url, method = 'GET', data = {}) => { return new Promise((resolve, reject) => { wx.request({ url: baseUrl + url, method: method, data: data, header: { 'Authorization': wx.getStorageSync('token'), 'Content-Type': 'application/json' }, success: (res) => { if (res.data.code === 200) { resolve(res.data.data); } else if (res.data.code === 401) { // token失效，重新登录 wx.removeStorageSync('token'); login().then(() => { // 重新发起当前请求 }); } else { wx.showToast({ title: res.data.msg, icon: 'none' }); reject(res.data); } }, fail: (err) => { wx.showToast({ title: '网络异常，请稍后重试', icon: 'none' }); reject(err); } }); }); };

这里有几个细节是实测踩出来的。第一，请求超时时间wx.request默认是60秒，有些慢接口建议单独设置timeout，不要迷信默认值；第二，Content-Type要根据后端接口的接收方式设置，SpringBoot接口用@RequestBody接收就必须设application/json，用@RequestParam就必须走form格式；第三，登录态失效的处理一定不能只是在页面上弹个错，而是要跳回登录流程重新获取token，不然用户会一直卡在报错界面。

登录流程建议在一个独立页面做：进入小程序时检查storage里有没有token；没有就调wx.login拿code，再调后端登录接口换取token；换到token后存入storage，再跳转到首页。这里说一个常见的迷思，有些人会直接在app.js里写死登录判断，但其他页面有同步请求依赖登录结果时就会偶发拿不到token。稳妥做法是app.js里只做静默登录，暴露一个loginReadyPromise，其他页面用await等待登录完成后再发初始化请求。

3.3 首页服务分类展示与滚动加载优化

首页通常包含两个核心板块：顶部的服务分类九宫格（或横向滑动分类）和服务项目列表。分类数据通过后端接口获取后渲染，列表默认加载第一页。这里要处理的典型问题是“微信小程序页面列表加载更多”，大部分前端新手都会踩到的坑是：一次性把后端所有数据全查出来渲染到页面上，数据量一上来，渲染性能就崩了。

正确做法是分页。小程序支持两种途径触发加载更多：页面滚动触底（onReachBottom）和用户下拉加载。先用page参数记录当前页码，size固定10条。每次请求完成后把新数据concat到已有列表，并在本地维护一个hasMore标志位判断是否还有下一页：

Page({ data: { list: [], page: 1, size: 10, hasMore: true, loading: false }, loadMore() { if (!this.data.hasMore || this.data.loading) return; this.setData({ loading: true }); request('/service/list', 'GET', { page: this.data.page, size: this.data.size }) .then((res) => { const list = this.data.list.concat(res.records); this.setData({ list: list, page: this.data.page + 1, hasMore: res.records.length === this.data.size, loading: false }); }); }, onReachBottom() { this.loadMore(); } });

防重复请求的loading判断非常关键。没有这个判断，用户快速滑动时会同时发出多个相同页码的请求，列表会出现重复数据，后端也会收到一堆无用流量。页面底部加一个“加载中/没有更多了”的提示条，这个交互细节可以截图放到论文里作为功能展示。

3.4 定位与地址选择：这个环节最容易出幺蛾子

上门维修系统的地址选择是核心交互之一。方案上可以用微信自带API或者腾讯地图SDK。如果用微信自带能力，流程是：

wx.chooseLocation({ success: (res) => { // res.name 地址名称，res.address 详细地址，res.latitude 纬度，res.longitude 经度 this.setData({ address: res.address, latitude: res.latitude, longitude: res.longitude }); } });

注意wx.chooseLocation需要在app.json里配置permission参数，includeLocation: true。如果只弹授权框不开权限，用户点“允许”也进不去选择器。这是一个非常隐蔽的坑，有些人调了半天还是提示“请授权定位”，其实就是这个配置没写。另外真机测试时定位精度受环境影响较大，室内可能偏移一两百米，所以不要让用户手动填经纬度，而是让用户选地址，然后由腾讯地图的逆地理编码把地址转成经纬度。后端保存坐标字段时统一用Decimal类型的经度、纬度，方便后续做“附近师傅”的范围查询。

3.5 支付逻辑简化：小程序支付的正确打开方式

微信小程序支付对于个人开发者来说，最大的门槛是——个人主体的小程序申请不了微信支付商户号，这个限制会卡死很多个人项目。毕设阶段的处理方式我认为有两种：第一种，如果本身有企业资质或能借到企业主体，走正常的wx.requestPayment流程；第二种，普通学生项目就用“模拟支付”功能。模拟支付的实现，就是在支付页面展示一个虚拟的支付弹窗，用户点“确认支付”，前端调后端接口把订单状态直接改成已支付，并生成一条支付记录。

答辩的时候老师基本都知道个人主体做不了真实支付，所以不用心虚。论文里就写“系统设计了支付接口，预留微信支付对接能力，开发环境中使用模拟支付完成闭环”。这比硬着头皮接一个第三方支付包挨批要好得多。真要做对接，记得处理好payment_record表和微信回调通知（notify_url），这一块代码量不大但是流程要完整，回调验签和订单金额核对是重点。

4. 前后端联调、抓包调试与Verilog常见问题排查

4.1 联调环境配置：真机调试的地址问题

开发时在小程序开发者工具里，后端地址填http://localhost:8080通常没问题，但一旦上真机调试，手机访问不了你电脑上的localhost，这时就要换成局域网IP：在application.yml里把服务配成0.0.0.0，或者让服务监听你的局域网网卡IP。还有一点很容易被忽略：手机和电脑必须连同一个WiFi。如果办公室或宿舍有AP隔离，可能互相ping不通，最简单的方案是手机开热点，电脑连手机热点，这样局域网环境绝对互通。

另外一个小程序端的注意项：开发时需要在开发者工具右上角“详情 -> 本地设置”里勾选“不校验合法域名、web-view（业务域名）、TLS版本以及HTTPS证书”。不然请求一发就会被卡住，提示“不在以下合法域名列表中”。如果是体验版或正式版，则必须在微信公众平台配置request合法域名，且必须是HTTPS。很多同学第一次发布体验版后所有接口全挂，就是只完成了开发环境配置，忘了去公众平台配置生产环境的request合法域名。这里补一句，没有备案域名的话，可以先把后端部署到云服务器，配一个HTTPS域名，或者用云厂商的API网关方案，过程稍烦，但这是小程序的硬性限制。

4.2 用Charles抓包小程序请求：排查问题的利器

小程序前端报错但后端日志全无痕迹，这种问题遇到几次你就知道抓包工具的重要性了。Charles是一个HTTP代理工具，原理很好理解：它作为中间人，手机端所有请求都先经过它再转发到服务器，这样你就能看到完整的请求头、请求体、响应体。

用Charles抓小程序包的步骤：第一步，电脑上安装Charles并保证和手机在同一局域网；第二步，开启Proxy菜单下的SSL Proxying，添加要抓的域名（比如你的后端IP或localhost）；第三步，手机WiFi设置里手动配置HTTP代理，填电脑IP和默认端口8888；第四步，如果是HTTPS请求，还需要在手机浏览器访问chls.pro/ssl下载并信任Charles证书，然后在设置里“允许从网络安装证书”并开启用户凭据信任。完成这些后，在小程序里触发一个请求，Charles的Interface列表就能看到这个请求，点击进去可以查看headers、JSON body、耗时。有一次我排查一个“小程序里永远拿不到数据但Postman正常”的问题，就是用Charles发现小程序请求头里带了Authorization，而后端拦截器对未带token的请求会返回401，但后端日志没有打印这个请求，一下子定位到了是token解析失败。

不过要强调一点：抓包只能抓你自己写的、你有权调试的小程序，不要拿这个技巧去做任何违反法律法规的事情。抓包的全部目的就是排查自己的联调问题。

4.3 小程序请求后端接口报错的排查清单

联调阶段最容易遇到的一类问题是请求发出去了，后端返回各种异常。这里整理一个速查表：

CORS问题给的统一解法是在SpringBoot里写一个CorsConfig：

@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); } }

SpringBoot版本如果高于2.4，注意allowedOriginPatterns方法和allowCredentials搭配使用的坑，直接用allowedOrigins("*")加allowCredentials(true)会导致浏览器拦截。

4.4 那些“高级话题”要不要碰：金仓、读写分离、SpringBoot高版本

热词里有“金仓读写分离配置”“SpringBoot版本太高”这类搜索词，这里结合毕设实际说一句：国产数据库适配是很好的加分方向，但不要在初版就把主存储放在金仓上。建议的做法是先用MySQL把系统跑通，论文的数据库设计部分写清楚表结构和关系，然后在“系统扩展”章节写一段“兼容适配方案”，说明系统数据访问层基于MyBatis-Plus的通用Mapper设计，可以平滑切换到人大金仓、达梦等国产数据库。如果答辩老师恰好研究这个方向，你可以顺势聊聊读写分离与中间件的概念；如果不懂，也不会翻车。

SpringBoot版本这块，很多刚接触Java的朋友会用最新版本，结果配置文件、导入的包名都跟网上教程对不上，报错连环炸。毕设求稳，用Spring Boot 2.7.x或3.0.x配对应版本的JDK即可。我见过用Spring Boot 3.2 + JDK 21跑的毕设，报一堆spring.factories读取失败的问题，因为新版改了自动装配机制，很多旧依赖不支持。最终项目能跑起来比版本新不从像素上重要一万倍。

5. 论文撰写、图表绘制与答辩准备

5.1 论文结构安排与各章内容要点

计算机毕业设计论文一般结构是：绪论、关键技术介绍、需求分析、总体设计、详细设计与实现、系统测试、总结展望。绪论里“研究背景与意义”从行业痛点写起，但不要胡编数据，比如不说“统计接入纠纷率上升了30%”，除非有真实来源。国内外研究现状这块要查文献，可以搜类似家政服务App、到家服务平台的研究，相关文献是很多的。

需求分析章节放用例图和用例说明，总体设计放功能结构图、系统架构图、E-R图、数据库表设计。详细设计是对每个模块的讲解，配合核心代码片段、时序图，代码不要大段全贴，截图关键代码并配上文字说明。系统测试章节，除了功能用例，最好加一个测试结论的表格，列出用例编号、功能模块、测试步骤、预期结果、实际结果、是否通过。这个表格极其加分，能证明你真的跑过一遍系统。

5.2 图表工具与绘制技巧

画图工具推荐ProcessOn或draw.io，免费、模板多、导出方便。论文里必配的图有：系统功能结构图、用户端业务流程图、订单状态图、系统架构图、数据库E-R图、部分核心时序图。功能结构图用树状图表达，业务流程图用泳道图表达各个角色的交互，订单状态图可以用状态机图。画图的核心原则是图要跟实现一致，千万不要为了好看画出代码里就没有的模块，答辩时被追问某一个功能时你完全不知道怎么回答，场面会很尴尬。

5.3 答辩高频问题与应对思路

答辩老师问的问题主要集中在几个方向：技术原理、功能逻辑、设计取舍。列几个经常被问到的：

“SpringBoot的自动装配原理是什么？”——这是一个必问问题。你至少要能说清楚：@SpringBootApplication包含@EnableAutoConfiguration，后者通过@Import导入AutoConfigurationImportSelector，这个类会扫描META-INF/spring.factories文件里配置的自动配置类，再根据@ConditionalOnClass等条件注解按需装配。不要只会说“启动时自动加载”，要把SPI机制和条件装配说透。

“为什么用MyBatis-Plus不用MyBatis？”——答：MyBatis-Plus提供了单表CRUD的通用方法，减少手写SQL；内置分页插件；底层仍然是MyBatis，不改变原有生态。

“订单状态这样设计有什么好处？”——这个问题考察状态机设计，你可以答：通过状态字段配合状态日志表，能够追溯订单流转过程；状态枚举集中管理，避免硬编码；后续如果要加“退款中”等状态，只需扩展枚举。

“微信小程序存储的openid会不会泄露隐私？”——答：openid是当前小程序下的用户唯一标识，不是用户微信号，并且后端不会回传openid，只下发JWT，用户自身也看不到自己的openid，设计上满足最小化原则。

“你的系统安全性是怎么考虑的？”——三个层面答：传输层走HTTPS；业务层JWT做身份认证、参数校验、统一异常处理；存储层密码使用BCrypt加密，敏感操作记录日志。顺带提一下接口幂等性设计，比如支付重复回调只处理一次。

5.4 答辩演示的演示路径建议

演示环节最忌讳在现场边想边点。提前准备一份“演示走查表”，路径建议是：进入首页展示服务分类 → 选择一个维修服务项目 → 填写故障描述和地址 → 提交下单，订单状态显示待接单 → 切到师傅端，查看可抢订单列表 → 点击接单，订单状态变为已接单 → 师傅端点击开始维修，状态变维修中 → 用户端确认完成 → 进入支付页，模拟支付 → 支付成功，双方可以评价 → 管理后台上线，看到新订单数据和评价数据。每个环节之间把关键接口的调用情况用开发者工具network或Charles展示一下。整条链路走下来，时间控制在8到10分钟，正好覆盖核心功能，不会拖沓。

最后再分享一个我做这类毕设辅导比较多年的个人体会：这个题目的上限和下限都跟工程完成度挂钩。最怕的不是功能少，而是做完主流程但关键支线断节——比如师傅审核没有后台入口、订单取消逻辑没处理库存，答辩时老师随便一追问就露馅。建议你在写代码时先梳理一份“完整流程路径清单”，把每个角色的完整生命周期走一遍，状态能进能退、订单能取消能退款，该有的日志和校验都补上，这套基本功练出来的工程习惯去工作后都吃得开。就按这个路子做，你的毕业设计和答辩稳得很。