简介这份基于微信小程序与Java后端构造的灾情救助系统毕业设计资源面向计算机相关专业本科生或课程设计、项目实战练习者完整解决从小程序端到MySQL数据库及后台管理的全流程开发需求。管理员可处理会员、灾情视频、公告、咨询、论坛、轮播图等模块会员能浏览救助内容、在线申请救助并上传材料、发布求助信息整体功能贴近真实业务场景便于二次扩展。压缩包共1250个文件涵盖png/jpg图标素材、java后端源码、vue管理端页面、js逻辑脚本、wxml/wxss小程序界面、sql数据库脚本、mp4演示录像、docx说明文档等按前端、后端、数据库、录屏分类存放包体约124.54MB便于本地导入运行和逐模块学习。已有224人学习下载。除完整源码和数据库外还提供配套说明文档、操作演示录像、启动脚本及资源备份文件可帮助理清系统结构、快速跑通项目并参照修改适合毕业设计答辩准备与实战能力提升。1. 灾情救助系统毕业设计这个选题为什么值得做拿到「基于微信小程序java后端的灾情救助系统毕业设计(源码数据库说明演示录像).zip」的人多半刚熬完选题正卡在怎么把项目跑起来。这个题目本质是标准的前后端分离业务系统小程序端做灾情上报和救援进度查看Java 后端做登录、灾情管理和任务调度数据落在 MySQL。它正好覆盖 Spring Boot、MyBatis、微信小程序、数据库设计四块高频考核点所以常年是热门选题。适合两类人一是 Java 基础一般、想用完整案例串起课程知识的学生二是想快速搭一个应急系统充实简历的开发者。压缩包里有源码、数据库脚本、说明文档和演示录像但能解压不等于能运行。这份笔记把架构、数据库、接口、小程序端和排错经验一次讲透照着复现即可跑通答辩也能讲清设计理由。2. 系统架构与数据库设计先看懂表结构再动手改代码2.1 小程序Java后端的整体架构选型先确定选型再动代码是跑通这种旧项目的唯一正确顺序。最稳的组合是 Spring Boot 2.x MyBatis MySQL 8 微信小程序原生框架前后端通过 JSON 接口交互小程序用 wx.request 请求后端地址。单体应用足够承载灾情上报、任务分配这类业务不需要引入微服务和消息队列否则部署和答辩都会给自己挖坑。有些拿到手的工程是 uniapp 写的判断方法看根目录有 pages.json 就是 uniapp需要先 npm install 再通过 HBuilderX 编译成微信小程序直接有 app.json 的就是原生小程序用微信开发者工具导入即可。选型理由要能讲给答辩老师听。用 Spring Boot 是因为它内置 Tomcat、自动配置数据源、starter 依赖统一适合快速交付用 MyBatis 是因为 SQL 可控灾情列表、状态统计这类查询可以直接写 XML 或注解 SQL比 JPA 更容易讲清数据怎么取用微信小程序是因为微信生态里小程序用户基数大灾情上报入口贴近日常使用习惯。这些不是空话每一项都能对应到一个具体功能例如灾情列表的分页查询就依赖 MyBatis 的分页插件或手写 limit。注意先确认后端是 Maven 工程还是直接导入 IDEA 的普通 Java 工程。Maven 工程根目录有 pom.xml用 IDEA 以 Maven 方式打开没有 pom.xml 就按普通工程导入 lib 目录下的 jar。这两种处理方式不同搞错了连编译都过不去。2.2 核心数据表设计灾情上报、救援资源与用户体系数据库是这个系统的地基建议先把 SQL 脚本逐条导入再谈后端代码。最常见的表结构包含四类用户表 t_user、灾情上报表 t_disaster_report、救援任务表 t_rescue_task、救援队伍表 t_rescue_team。用户表负责存放微信 openid、昵称、手机号和角色灾情上报表是核心记录灾情类型、等级、经纬度、地址、描述、图片和状态救援任务表关联上报记录和救援队伍救援队伍表是资源的基础数据。角色一般用 0 普通用户、1 救援人员、2 管理员用 TINYINT 存比字符串更省空间。表与表之间的关系要提前想清楚。一个用户可以上报多条灾情所以 t_user 和 t_disaster_report 是一对多一个灾情可能被多个救援队伍协同处理所以 t_disaster_report 和 t_rescue_task 是一对多而不是一对一。在真实应急场景里火灾可能同时需要消防和医疗两支力量如果设计成一对一后期扩展协作功能就得改表结构。外键约束我建议不用逻辑关系在 Java 代码里维护避免删除用户时被外键拦住答辩时也能说“为了提高写入性能用应用层控制关联”。下面这段 SQL 是可直接执行的建库和建表脚本字段和注释按毕业设计常见格式书写方便你对照手里的数据库脚本看差异。CREATE DATABASE IF NOT EXISTS disaster_aid DEFAULT CHARSET utf8mb4; USE disaster_aid; CREATE TABLE t_user ( id INT PRIMARY KEY AUTO_INCREMENT, openid VARCHAR(64) NOT NULL COMMENT 微信用户openid, nickname VARCHAR(50) DEFAULT COMMENT 昵称, phone VARCHAR(20) DEFAULT COMMENT 联系电话, role TINYINT DEFAULT 0 COMMENT 角色:0普通用户,1救援人员,2管理员, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_openid (openid) ) ENGINEInnoDB COMMENT用户表; CREATE TABLE t_disaster_report ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL COMMENT 上报人ID, title VARCHAR(100) NOT NULL COMMENT 灾情标题, type TINYINT NOT NULL COMMENT 灾情类型:1火灾,2水灾,3地震,4其他, level TINYINT DEFAULT 1 COMMENT 严重程度:1一般,2较重,3严重, longitude DECIMAL(10,6) NOT NULL COMMENT 经度, latitude DECIMAL(10,6) NOT NULL COMMENT 纬度, address VARCHAR(255) DEFAULT COMMENT 详细地址, description TEXT COMMENT 灾情描述, image_url VARCHAR(255) DEFAULT COMMENT 现场图片URL, status TINYINT DEFAULT 0 COMMENT 状态:0待处理,1救援中,2已完成,3已关闭, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_status (status), KEY idx_user_id (user_id) ) ENGINEInnoDB COMMENT灾情上报表; CREATE TABLE t_rescue_team ( id INT PRIMARY KEY AUTO_INCREMENT, team_name VARCHAR(50) NOT NULL COMMENT 队伍名称, team_type TINYINT DEFAULT 1 COMMENT 类型:1消防,2医疗,3综合, contact_phone VARCHAR(20) DEFAULT COMMENT 值班电话, available TINYINT DEFAULT 1 COMMENT 是否可用:1可用,0忙碌 ) ENGINEInnoDB COMMENT救援队伍表; CREATE TABLE t_rescue_task ( id INT PRIMARY KEY AUTO_INCREMENT, report_id INT NOT NULL COMMENT 灾情上报ID, team_id INT NOT NULL COMMENT 救援队伍ID, assign_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 指派时间, finish_time DATETIME DEFAULT NULL COMMENT 完成时间, status TINYINT DEFAULT 0 COMMENT 任务状态:0进行中,1已完成, remark VARCHAR(255) DEFAULT COMMENT 备注, KEY idx_report_id (report_id) ) ENGINEInnoDB COMMENT救援任务表;建表脚本的关键点有两处。t_user 的 openid 加了唯一索引这在微信登录场景里是刚需同一个微信用户重复调用登录接口时后端能通过唯一键判断是已存在的老用户还是新用户。t_disaster_report 的 longitude 和 latitude 用 DECIMAL(10,6)小数点后 6 位能精确到米级满足小程序地图选点的展示需求比用双精度 DOUBLE 更省空间。整体字符集用 utf8mb4 而不是 utf8因为微信昵称可能包含 emoji 表情utf8 存不下会直接报错。导入之后先不要急着改表结构有些项目会在演示录像里展示额外的统计图表那是通过视图或额外字段实现的。如果少了字段先把说明文档里的《数据库设计说明书》拿出来对比说明文档没有就按上面的脚本补只要保证小程序端用到的字段都存在运行就不会报错。也可以在 mybatis 的 SQL 日志里跑一次接口看查询语句比盲目加字段更靠谱。2.3 连接池与 MyBatis 配置改完数据库先解决这两个点数据库脚本导入之后接下来要处理后端的 application.yml。这个文件是后端能否连上数据库的命门常见翻车点集中在数据源 URL 时区、数据库连接池参数和 MyBatis 驼峰映射三处。MySQL 8 的驱动要求 URL 里带 serverTimezone否则启动时直接抛异常MyBatis 不开启驼峰映射Java 实体里的 createTime 默认映射不到数据库的 create_time 字段查出来全是 null。spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/disaster_aid?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse username: root password: 你的数据库密码 hikari: maximum-pool-size: 10 minimum-idle: 5 connection-timeout: 30000 servlet: multipart: max-file-size: 10MB max-request-size: 20MB mybatis: configuration: map-underscore-to-camel-case: true这段配置里的 hikari 是 Spring Boot 2.x 自带的数据库连接池不需要额外引入依赖。maximum-pool-size 设 10 足够毕业设计的小并发数值不是越大越好超过数据库默认连接数反而启动变慢minimum-idle 设 5 能避免每次请求临时创建连接。注意 multipart 的两个参数决定小程序端 wx.uploadFile 上传图片能不能成功max-file-size 是单张图片上限max-request-size 是单次请求总大小建议分别设 10MB 和 20MB因为有些灾情上报页面会同时上传两张现场照片。配置完成后启动 Spring Boot 应用看到 Tomcat started on port(s): 8080 就说明后端起来了。如果端口被占用在 application.yml 里改 server.port比如改成 8081同时记得小程序端请求地址里的端口也要跟着改。这里有个血泪经验windows 上 MySQL 8 默认账号 root 的密码方式可能是 caching_sha2_password旧版驱动连不上如果报 Public Key Retrieval is not allowed就在 URL 后加 allowPublicKeyRetrievaltrue或把账号密码认证方式改成 mysql_native_password。3. 后端接口落地Spring Boot 实现灾情上报与调度3.1 登录接口用 code 换 openid 再签发 token灾情救助系统里小程序端的所有写操作都需要身份信息所以第一个要跑通的接口是登录。微信小程序登录的标准流程是前端调用 wx.login 拿到临时 code把 code 传到后端后端拿 code 加上 AppID 和 AppSecret 去微信接口换取 openid。openid 是用户在微信生态里的唯一标识后端用它去查用户表查出就登录查不出就自动注册一个新用户。这套流程在毕业设计中已经是最简做法不需要额外开发账号密码注册模块。实现登录接口时换 openid 这一步可以封装成 service 里的一个方法。用 Spring 的 RestTemplate 发起 HTTP GET 请求把 appid、secret、js_code 放在查询参数里微信返回的 JSON 中有 openid 和 session_key。换到 openid 之后生成 JWT token把用户 ID 和角色放进 claims过期时间设 7 天小程序端每次请求带在 header 里。下面是一个简化版但可运行的 controller 代码。RestController RequestMapping(/api/user) public class UserController { Autowired private UserService userService; PostMapping(/login) public Result login(RequestBody LoginRequest req) { String openid userService.exchangeOpenid(req.getCode()); if (openid null || openid.isEmpty()) { return Result.error(登录凭证已失效请重试); } User user userService.findOrCreate(openid); String token JwtUtil.createToken(user.getId(), user.getRole()); return Result.ok() .put(token, token) .put(userInfo, user); } }controller 里的 login 接口把业务全部委托给 service自己只做参数接收和结果封装。这里有几个参数细节要注意LoginRequest 里只需要一个 code 字段不用传用户昵称和头像因为微信昵称和头像更换频繁以 openid 为主的用户体系才稳定Result 是一个统一返回包装类包含 code、msg、data 三个字段小程序端根据 code 判断成功失败这样比直接返回裸对象更好扩展。service 层里 exchangeOpenid 是整条链路最容易出问题的位置因为 code 是一次性的而且有时效。如果前端把旧 code 传来微信接口会返回 errcode 40029也就是 invalid code。所以前端每次进登录页都要重新 wx.login不能把 code 存在全局变量里复用。findOrCreate 方法可以拆成两步先按 openid 查询用户查不到就 insert 一条新记录再查一次注意这里要捕获唯一键冲突异常防止并发登录时同一个 openid 插入两条记录。3.2 灾情上报接口图片上传和业务提交要拆开小程序端灾情上报页面的动作一般分两步先选择照片再填写灾情类型和位置信息。对应的后端接口也应该拆成两个一个接收 multipart 图片一个接收 JSON 业务数据。很多同学图省事把图片和 JSON 放同一个接口结果 wx.request 和 wx.uploadFile 的 contentType 不一致接口要么拿不到图片要么拿不到字段这是典型的自找麻烦。我自己的做法是先上传图片拿到返回的 imageUrl再把它拼进灾情提交的 JSON 里一次性提交。图片上传接口用 Spring MVC 的 MultipartFile 接收保存到本地磁盘目录后返回访问链接。保存路径要写成可配置的不能写死在代码里如果是 Windows 本机调试建议存到 D:/upload/ 然后配置静态资源映射到 /upload/**如果是 Linux 服务器建议存到 /data/disaster/upload/ 并同样映射出来。你手里这套源码多半已经把路径写在了 application.yml 里只要改成自己机器能访问的路径即可。PostMapping(/api/upload/image) public Result uploadImage(RequestParam(file) MultipartFile file) { if (file.isEmpty()) { return Result.error(上传文件为空); } if (file.getSize() 10 * 1024 * 1024) { return Result.error(图片大小不能超过10MB); } String originalName file.getOriginalFilename(); String ext originalName.substring(originalName.lastIndexOf(.)); String newName UUID.randomUUID().toString().replace(-, ) ext; File dir new File(uploadDir); if (!dir.exists()) dir.mkdirs(); file.transferTo(new File(dir, newName)); return Result.ok().put(url, /upload/ newName); }这段代码里最关键的是生成新文件名用 UUID 去重直接避免了重名覆盖也避免了中文文件名在部分容器里乱码。ext 取扩展名的逻辑要小心如果前端传的文件名没有点号lastIndexOf 返回 -1 会导致异常稳妥写法是先判断 lastIndexOf 是否大于 0否则报“不支持的文件类型”。保存路径 uploadDir 从配置里读取不要用相对路径因为 IDEA 里的工作目录和打包后 jar 的运行目录可能不一致。灾情上报的业务接口相对简单但状态初始化容易漏。插入 t_disaster_report 时status 必须显式赋 0待处理否则数据库默认值如果没设置正确可能会插入 NULL前端列表按状态筛选时查不到数据。上报灾情时还应该带 user_id这个值不要从小程序传来的 JSON 里取而要从 JWT token 里解析防止用户伪造他人身份上报。3.3 救援任务分配状态机与权限控制救援任务分配是整个系统的核心业务也是答辩环节最能体现设计能力的地方。完整的流程是管理员看到待处理的灾情列表进入详情页点击“分配救援队”选择队伍后提交后端创建救援任务同时把灾情状态从 0 改成 1救援队伍在自己的任务列表里点击“完成任务”灾情状态从 1 变成 2。这背后是一个典型的业务状态机每个状态只能转移到合法的下一个状态不能随意跳转。权限控制建议用最简单直接的方式在 controller 里校验当前登录用户角色。前端登录后 token 里有 role后端写一个拦截器解析 token 并放入 request attribute分配接口从 attribute 取 userId 再去查用户角色。角色为 2 的管理员才能执行分配操作普通用户调用直接返回无权限。下面是分配接口的核心代码实现思路是两件事放在同一个事务里完成。PostMapping(/api/task/assign) Transactional(rollbackFor Exception.class) public Result assign(RequestBody AssignRequest req, RequestAttribute(userId) Integer userId, RequestAttribute(userRole) Integer userRole) { if (userRole ! 2) { return Result.error(无权限执行此操作); } DisasterReport report reportMapper.selectById(req.getReportId()); if (report null) { return Result.error(灾情记录不存在); } if (report.getStatus() ! 0) { return Result.error(该灾情已处理不能重复分配); } RescueTask task new RescueTask(); task.setReportId(req.getReportId()); task.setTeamId(req.getTeamId()); task.setStatus(0); taskMapper.insert(task); reportMapper.updateStatus(req.getReportId(), 1); return Result.ok(); }这段代码的关键点是顺序先查灾情记录校验状态再插入救援任务最后更新灾情状态。三个步骤用 Transactional 包住中间任何一步抛异常整体回滚不会出现任务插入成功但灾情状态没变的半成功状态。AssignRequest 里的 teamId 是对应 t_rescue_team 表的自增 ID而不是队伍名称这样后续要显示队伍信息时可以直接 join 查询。参数校验上reportId 和 teamId 都用包装类 Integer避免前端传 null 时空指针。注意状态机设计要留一条“关闭灾情”的路径否则管理员误操作之后没有后悔药。最简单做法是提供一个 status 从 0 或 1 改为 3 的接口并记录操作人。这个小功能在答辩演示时有奇效老师会认为你考虑了实际业务中的异常情况。4. 微信小程序端从登录到灾情上报的完整链路4.1 小程序登录与请求封装先解决 token 的存取小程序端的第一步是处理登录这一步不成功后面所有接口都弹“未登录”。在微信开发者工具里app.js 的 onLaunch 里调用 wx.login 拿到 code再通过 request 封装调用后端的 /api/user/login。拿到 token 后存到 wx.getStorageSync 或全局变量里。要注意 wx.login 的 code 必须每次重新获取不能缓存因为微信后端只认一次性的 code。一个稳定的小程序请求封装要同时处理三件事header 带 token、统一处理业务错误码、处理 401 或 token 过期。token 过期时主动调用重新登录逻辑而不是直接提示用户重新打开小程序。下面是简化版的 request 封装可以直接放到 utils/request.js 里。const BASE_URL http://localhost:8080; function request(url, method GET, data {}) { return new Promise((resolve, reject) { const token wx.getStorageSync(token); wx.request({ url: BASE_URL url, method: method, data: data, header: { Content-Type: application/json, Authorization: token ? Bearer token : }, success(res) { // 后端统一返回 {code, msg, data} if (res.data res.data.code 0) { resolve(res.data.data); } else if (res.statusCode 401) { wx.removeStorageSync(token); reject(new Error(登录已过期)); } else { wx.showToast({ title: res.data.msg || 请求失败, icon: none }); reject(new Error(res.data.msg)); } }, fail(err) { wx.showToast({ title: 网络异常, icon: none }); reject(err); } }); }); } function login() { return new Promise((resolve, reject) { wx.login({ success(res) { if (res.code) { request(/api/user/login, POST, { code: res.code }) .then(data { wx.setStorageSync(token, data.token); resolve(data); }) .catch(reject); } else { reject(new Error(获取code失败)); } }, fail: reject }); }); } module.exports { request, login };BASE_URL 在小程序真机调试时必须改成你的后端服务器公网 IP 或域名本地调试时 localhost 只能用于微信开发者工具在手机预览上 localhost 指向手机自身这是大量新手第一次真机跑失败的原因。代码里统一从 storage 取 token并在 401 时清掉 token配合后端拦截器形成一套完整的认证闭环。登录成功回调里可以先获取用户角色用于控制页面上“分配任务”入口的显示。4.2 灾情上报页面地图选点与图片上传灾情上报页面是灾情救助系统的核心页面它要同时处理地图选点、图片上传、文本输入三类交互。微信小程序的地图组件 map 自带 bindtap 事件点击地图后通过 e.detail 能拿到经纬度再把经纬度设置成标记点显示在地图上。这里要注意地图组件的 id 属性必须设置否则获取地图上下文会失败这是很多小程序地图功能跑不起来的隐藏原因。图片上传用 wx.chooseMedia 选择照片再用 wx.uploadFile 传送到后端。wx.chooseMedia 是较新的 API旧项目里如果用的是 wx.chooseImage虽然还能用但官方已经不推荐。调用 wx.uploadFile 时后端返回的是字符串需要 JSON.parse 转成对象这一点和 wx.request 不同。上传完成后再和灾情表单一起提交提交前校验经纬度和图片是否已选。以下代码片段假设 BASE_URL 已从 utils/request.js 引入。Page({ data: { latitude: 0, longitude: 0, imagePath: , typeIndex: 0, levelIndex: 0, description: }, onMapTap(e) { this.setData({ latitude: e.detail.latitude, longitude: e.detail.longitude }); }, chooseImage() { wx.chooseMedia({ count: 1, mediaType: [image], sizeType: [compressed], sourceType: [album, camera], success: (res) { this.setData({ imagePath: res.tempFiles[0].tempFilePath }); } }); }, uploadImage() { const token wx.getStorageSync(token); wx.uploadFile({ url: BASE_URL /api/upload/image, filePath: this.data.imagePath, name: file, header: { Authorization: Bearer token }, success: (res) { const result JSON.parse(res.data); if (result.code 0) { this.setData({ imageUrl: result.data.url }); } else { wx.showToast({ title: result.msg, icon: none }); } } }); }, submitReport() { // 组装数据并调用 /api/report/submit } });onMapTap 里取到的经纬度只有 6 位小数这会直接命中 t_disaster_report 表 DECIMAL(10,6) 的精度存储时不会有问题。chooseImage 里 sizeType 选 compressed 能减小上传体积微信会压缩图片到大约 200KB但压缩后仍可能大于后端限制所以后端那边的 10MB 上限其实已经留了很大余量。uploadImage 必须在 submitReport 前执行可以用 async/await 包一层或者把上传动作和提交动作合并在一个按钮事件里按顺序调用。4.3 顶部导航栏高度与页面布局小程序端最容易忽略的适配灾情列表、个人中心这类页面在 iPhone 刘海屏和其他安卓机上顶部导航栏高度不一致这是小程序开发中一个很经典的问题。原生导航栏高度通常由系统决定但自定义导航栏时需要在 app.json 里设置navigationStyle: custom然后手动用 wx.getWindowInfo() 获取状态栏高度和菜单按钮的位置来推算导航栏高度。如果你拿到的项目用了自定义导航栏可以参考下面这段获取高度的工具函数。function getNavBarHeight() { const winInfo wx.getWindowInfo(); const menuRect wx.getMenuButtonBoundingClientRect(); const statusBarHeight winInfo.statusBarHeight; const navBarHeight (menuRect.top - statusBarHeight) * 2 menuRect.height; return { statusBarHeight: statusBarHeight, navBarHeight: navBarHeight }; }这段代码的原理是菜单按钮胶囊顶部到状态栏底部的距离乘 2 再加胶囊自身高度就是自定义导航栏的总高度。不同机型的状态栏高度不同直接用这个函数计算最稳妥。如果你的项目使用系统默认导航栏就不需要这个函数但要注意在 page.json 里设navigationBarTitleText否则每个页面顶部都会显示默认的“微信”标题演示录像里看着很掉价。页面层级上灾情上报页建议做成 tabBar 之外的独立页面避免位置信息丢失。提示真机预览时把“不校验合法域名”开关只用于开发阶段。正式演示或提交审核前必须在微信公众平台后台配置 request 合法域名和 uploadFile 合法域名域名必须是 HTTPS。本地做毕业设计演示时可以用开发者工具的“详情-本地设置-不校验合法域名”临时绕过但答辩前最好改回规范方式并说明这一项。5. 避坑记录一套灾情救助系统跑不起来最常见的5个问题5.1 MySQL 8 驱动与时区报错启动后端直接抛异常现象Spring Boot 启动时报The Server Time Zone offset is not configured或Public Key Retrieval is not allowed应用起不来控制台红字一片。原因MySQL 8 默认驱动类名是 com.mysql.cj.jdbc.Driver它在建立连接时要求服务器时区明确同时连接串没允许公钥检索导致密码验证失败。很多旧代码里的 driver-class-name 还是老的 com.mysql.jdbc.Driver那个驱动类在 MySQL 8 下已经移除了。解决把 application.yml 里的驱动改成 com.mysql.cj.jdbc.DriverURL 加上 serverTimezoneAsia/Shanghai 和 allowPublicKeyRetrievaltrue。注意时区别用 GMT8那会在夏令时地区出错直接用 Asia/Shanghai 最稳。改完重启后端再报错就去看 MySQL 的 root 用户认证方式执行ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 你的密码;刷一下。5.2 微信开发者工具能跑但真机请求失败localhost 指向手机现象在微信开发者工具里所有接口正常但用手机扫码预览时灾情列表加载不出来控制台显示 request:fail。原因真机预览时小程序运行在手机上代码里的 localhost 指向的是手机自己不是电脑。手机的请求既找不到 localhost 上的后端也会因为请求的是 http 明文地址被微信拦截。这两层因素叠加表现就是开发者工具正常、真机失败。解决局域网调试时把 BASE_URL 改成电脑的局域网 IP比如 192.168.1.100:8080同时打开微信开发者工具的“不校验合法域名”开关并且手机和电脑连同一个 Wi-Fi。如果后端是部署到云服务器就直接用服务器公网 IP 并配置好安全组放行 8080 端口。演示录像里看到的真机画面基本都是走这个方案录的。5.3 图片上传失败multipart 参数和上传路径对不上现象小程序的 wx.uploadFile 调用后一直报“文件为空”或 404但同一个接口在 Postman 里传文件又是正常的。原因常见有两个原因。一是小程序端 name 参数和后端 RequestParam 的 name 对不上后端写的是 file小程序里写成了 image二是后端的 uploadDir 目录不存在或者没有静态资源映射文件虽然传上去了但访问 URL 返回 404。解决先看后端启动日志确认有没有走到上传方法再检查 MultipartFile 参数名是否一致最后看配置里的 upload-dir 路径有没有 mkdirs。上传成功后在浏览器里直接访问返回的 imageUrl如果 404就在 WebMvcConfigurer 里加 addResourceHandlers把 /upload/** 映射到磁盘目录。这块是很多项目演示录像里看着正常、实际跑全是坑的重灾区。上传成功后还要检查后端返回的 imageUrl 能不能直接在小程序 image 组件里显示。如果小程序端开启了域名校验http 的图片地址同样会被拦截。常见做法是在开发者工具里临时关闭校验或者把图片转成 base64 回显。这个细节不影响接口逻辑但影响演示效果图片裂开会给答辩印象减分。5.4 说明文档与源码版本对不上照着文档操作反而翻车现象说明文档写的是 MySQL 5.7实际 SQL 脚本里用了DEFAULT CURRENT_TIMESTAMP在 5.5 上语法报错或者文档里让导入的数据库名是 aid源码里连接的是 disaster_aid导致后端起不来。原因毕业设计源码包经常经过多次修改说明文档是最初版本源码是最终版本。压包的人可能只更新了代码没同步文档于是出现文档内容和实际代码不一致。解决拿到压缩包后先看说明文档最后的“更新记录”没有就用文本对比工具比较 application.yml 里的数据库名和 SQL 脚本开头的 CREATE DATABASE 是否一致。以源码为准改文档不要以文档为准改源码。跑通之后自己补一份一页纸的运行说明答辩提交时把这份和源码放一起比原来的说明文档更贴近实际状态。另一个容易踩的坑是说明文档里的端口号是 8081后端实际端口是 8080小程序 BASE_URL 写的是 8080。文档、源码、前端配置三处不一致很常见排查时用文本编辑器全局搜索端口号把三处统一起来。我一般会把最终跑通的端口写进自己的说明里形成一份真实可用的运行手册。5.5 演示录像和当前环境不一致照着录像点按钮在页面却找不到现象演示录像里灾情列表页有“分配任务”按钮自己跑起来后怎么找都找不到或是点进去报无权限。原因演示录像是用管理员账号录的你登录的是普通用户账号前端的权限判断让按钮直接隐藏了。有时录像里的页面和当前代码不是同一个版本也会出现按钮位置不同的问题。解决先看说明文档里有没有提供测试账号。用管理员账号登录再看对应页面没有账号就直接改数据库把 t_user 里你的那条记录的 role 改成 2。前端如果做了严格的角色控制保留管理员登录入口即可答辩演示时用管理员账号操作一遍就能和演示录像基本一致。这里要提醒自己演示前先把所有页面的空数据状态处理掉否则列表空空如也录像里却是满屏数据观感差距会很明显。6. 让答辩更稳的验证技巧用 Postman 和压测脚本证明系统可用答辩时最容易被追问的一个问题是“你的系统到底能不能扛住真实请求”。空口说“可以”不够最好现场用 Postman 或接口测试脚本演示一遍完整的业务闭环。我会先把 Postman 里的环境变量配好base_url、token、reportId。先调用登录接口拿到 token 存入环境变量再调用灾情上报接口创建一个测试灾情返回的 reportId 作为后续分配任务的入参。最后用管理员身份调分配接口把灾情状态改成救援中。整个过程控制在两分钟内视频或截图作为答辩辅助材料比翻代码讲实现更有说服力。轻量并发测试不一定要上 JMeter毕业设计规模用一段 Python 脚本就够了。以下脚本模拟 20 个用户同时上报灾情主要验证数据库连接池和事务是否正常。如果 maximum-pool-size 配置太小或连接泄漏脚本会抛出连接超时。这类测试结果可以截图放进论文测试部分比单纯写“系统运行稳定”可信得多。import requests import threading BASE http://localhost:8080 def report_once(uid): try: # 1. 登录拿到 token login_resp requests.post(BASE /api/user/login, json{code: fmock_code_{uid}}) token login_resp.json()[data][token] # 2. 提交一条灾情 headers {Authorization: Bearer token} data { title: f并发测试灾情{uid}, type: 1, level: 2, longitude: 120.123456, latitude: 30.123456, description: 压测用数据不影响真实业务 } resp requests.post(BASE /api/report/submit, jsondata, headersheaders) assert resp.json()[code] 0, resp.text except Exception as e: print(fuser {uid} failed: {e}) threads [threading.Thread(targetreport_once, args(i,)) for i in range(20)] for t in threads: t.start() for t in threads: t.join() print(done)脚本里每线程先登录再上报完整模拟真实用户链路。实际测试时注意把标题加上线程编号方便测试后在数据库里筛掉这批数据避免污染演示数据。压测通过后再去录演示录像。录制前把数据库清理干净预置两条灾情记录和一支救援队按管理员视角录“列表-详情-分配-完成”这条主线顺便录一次地图选点和图片上传。我自己的习惯是录完用播放器倍速检查一遍确认没有空白等待和报错弹窗再决定要不要重录。这个项目做完最大的收获其实是学会了一套“拿到老旧代码先验环境再改业务”的调试顺序。毕业设计通常不会验收多么高深的技术但会验收你是不是真的跑通了系统、讲得清每个模块的职责。把环境配置、账号权限、演示数据这三样提前处理好答辩就成功了一大半。希望这些经验能帮到你尽快把灾情救助系统在自己的机器上跑起来。本文还有配套的精品资源点击获取
