多彩编程 多彩编程MZPH · CODE BLOG
ARTICLE DETAIL

文章详情

深耕前端与后端开发技术的一线实战笔记与踩坑复盘。

仓储管理系统毕业设计:小程序+Java后端+MySQL源码全流程避坑指南

仓储管理系统毕业设计:小程序+Java后端+MySQL源码全流程避坑指南 简介面向高校计算机相关专业毕业设计或课程设计场景这份微信小程序仓储管理系统源码包适合需要快速搭建完整前后端项目的学生参考与二次开发。系统仅一名管理员即可管理个人中心、供应商、员工、商品分类、商品信息、商品入库出库、供应商货物、货物采购、在线沟通及系统管理等模块业务链路清晰。压缩包共1373个文件、约32.13MB涵盖Java后端、Vue小程序前端、SQL数据库脚本等核心代码并含png/jpg界面截图、js/json/wxml/wxss小程序逻辑与配置、xml/scss工程配置等目录结构完整便于按模块检索。目前已有97人学习下载。包内提供完整前后端源码和数据库文件并附JDK1.8、MySQL5.7、Tomcat7等环境说明可帮助快速配置运行环境理解业务实现并扩展功能。1. 起手看工程这套仓储管理系统到底给了你什么先说结论这套源码包不是那种只让你「看一眼架构图」的半成品它是完整能跑、能交、能答辩的毕业设计实物而且正好卡在「小程序 Java 后端 MySQL」这条最稳妥的技术路线上。很多同学毕设翻车不是思路不行是前后端各写各的最后对不上接口这套系统的价值在于它把商品入库、出库、供应商货物、采购、在线沟通这些仓储核心流程全串起来了并且只用一个管理员账号就能覆盖全部后台功能权限逻辑简单正好匹配课程设计的管理难度。适合两类人一类是时间紧张、需要一份能正常启动的 Java 小程序毕设源码的学生另一类是刚接触小程序开发、想找个完整案例看「Java 后端如何给小程序提供接口」的从业者。拿到手先别急着跑我建议你按我下面的顺序来先理解工程结构和环境搭配逻辑再动手导数据库、启动后端、编译小程序最后集中过一遍我踩过的坑。这套流程走完你答辩时可以理直气壮说「每一个功能我都亲手跑通过」。2. 版本搭配不是玄学JDK 1.8、MySQL 5.7、Tomcat 7 为什么能凑在一起2.1 技术选型的内在逻辑与边界环境说明里写得很明确Java 语言、JDK 1.8、MySQL 5.7、Navicat 11、Eclipse/IDEA、Maven 3.3、Tomcat 7、HBuilderX 或微信开发者工具。这套组合看起来像「老古董」但它确实是当前毕设源码圈里兼容性最好的一套搭配原因有三。第一JDK 1.8 是很多高校机房和旧机器的默认版本也是 Spring Boot 2.x 和传统 SSM 框架的最后黄金兼容线。如果你一上来装 JDK 17Tomcat 7 直接跑不起来Maven 3.3 对高版本 JDK 的编译支持也很拉胯。第二MySQL 5.7 相比 8.0 少了认证插件和时区那堆坑Navicat 11 连它非常丝滑导出导入 SQL 不会因为字符集和版本差异报一堆语法错误。第三Tomcat 7 对应 Servlet 3.0跟这个项目后端用的 Spring 版本和 JSP/Servlet API 是配套的强行用 Tomcat 9 反而可能遇到类加载问题。当然这套组合也有边界它不是万能的如果你要部署到云服务器建议保持和本地一致的操作系统位数和软件版本不要随便升级。我看到过有人毕设答辩当天把 MySQL 从 5.7 升到 8.0结果项目里某个 SQL 用了容易歧义的语法整个登录接口直接罢工。2.2 工程目录结构逐个拆拿到 zip 解压后先别急着点 bat 脚本。用编辑器打开看一眼顶层目录里面有几个.bak文件和一个源码目录。.bak后缀的文件是备份比如main.js.bak、IndexMain.vue.bak、IndexHeader.vue.bak、BreadCrumbs.vue.bak、IndexAsideStatic.vue.bak、update-password.vue.bak、main.css.bak这些是前后端修改过程中留下的旧版本用于你改坏了随时回退不是部署必需文件。真正的工程主体应该是三块后端代码工程含 Java 源码和 Maven 配置、小程序前端含页面、JS 逻辑、配置文件、数据库一个.sql文件通常放在 database 或 doc 目录。我建议你先在本地建一个干净的目录结构把这三块分开存放方便后续用 IDEA 和微信开发者工具各自打开。# 以 Windows 为例我的习惯是建一个统一工程目录 mkdir D:\code\warehouse-system cd D:\code\warehouse-system # 目录规划如下 # warehouse-backend/ 后端 Java 工程 # warehouse-miniapp/ 小程序前端工程 # database/ 数据库脚本及其他文档提示不要直接在 zip 包解压后的路径里启动服务项目路径带中文或带空格在 Tomcat/Maven 解析时容易出怪问题我每次都会先归整目录再动手。2.3 三个 bat 脚本的用途与顺序陷阱工程根目录下的1-install.bat、2-run.bat、3-build.bat看名字是「安装-运行-构建」一条龙很多人上来就双击结果在第一步就卡住。原因是它们本质上是调用 Maven 命令的简化封装假设你的本机已经装好了 Maven、Java、和 MySQL且「环境变量配置正确」。我先给你看一个典型的构建脚本内容和顺序逻辑echo off rem 1-install.bat 的作用先清理旧编译产物再安装依赖到本地仓库 rem 实际执行的是 Maven 的 clean 和 install mvn clean install -Dmaven.test.skiptrue pauseecho off rem 2-run.bat 的作用用 Tomcat 插件或内嵌容器启动后端 rem 实际执行的是 Maven 的 spring-boot:runSSM 项目则为 tomcat7:run rem 前端工程如果依赖 npm则这里可能还有 npm install 环节但注意看实际项目采用的是后端打包还是前后端分离联调 mvn spring-boot:run -Dmaven.test.skiptrue pauseecho off rem 3-build.bat 的作用通常用于最终打成 war 包或 jar 包 mvn clean package -Dmaven.test.skiptrue pause参数解释-Dmaven.test.skiptrue是跳过测试用例编译和运行毕业设计项目里基本没有成体系的单测跳过能缩短编译时间clean是把target目录删掉重来防止旧 class 文件残留导致莫名其妙的「方法找不到」package会生成最终可部署的包位置在目标工程的target/目录下。你需要注意顺序陷阱不要先双击 3-build.bat 再跑 2-run.bat。因为 build 只打包不启动run 跑的是当前代码如果 build 生成的包里有旧接口定义你后续改动代码没重新 build2-run 就会加载到过期内容表现出来就是前端调用某个接口报 404 或返回空值。正常操作顺序是先 1-install 拉齐依赖再改代码每次改动完跑 3-build 验证能否编译通过最后用 IDEA 里的 Tomcat 配置直接启动调试而不是反复依赖 bat。3. 数据库是地基用 Navicat 11 导入 SQL 与账号权限坑3.1 先建库、再导入、后检查这个顺序不要动仓储管理系统全部功能的根基是 MySQL 里的若干张表管理员表、供应商表、员工表、商品分类表、商品信息表、商品入库表、商品出库表、供应商货物表、货物采购表、在线沟通表。这套表结构逻辑很直白没有复杂的存储过程和视图对毕设来说正好但「不会建库导致系统启动连不上数据库」是我见过最多的卡点。正确的导入步骤是用 Navicat 11 连接 MySQL 5.7先手动创建一个空库名字建议用warehouse_db注意字符集选utf8mb4排序规则选utf8mb4_general_ci。然后右键这个库选择「运行 SQL 文件」选中项目里给的.sql文件勾选「遇到错误继续」开始导入。-- 如果你习惯用命令行也可以这样做 -- 第一步登录 MySQL mysql -uroot -p -- 第二步创建数据库注意字符集 CREATE DATABASE IF NOT EXISTS warehouse_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; -- 第三步选择数据库 USE warehouse_db; -- 第四步导入项目提供的 SQL 文件 SOURCE D:/code/warehouse-system/database/warehouse_db.sql;注意SQL 文件里通常已经包含了CREATE DATABASE IF NOT EXISTS和USE语句你如果手动建库又在 Navicat 里重复执行可能出现「数据库已存在」的提示这时要仔细看报错内容强行覆盖可能把已有数据清掉。我的习惯是先打开 SQL 文件看前 20 行判断它是否自带建库语句再决定要不要手动建库。3.2 密码强度、时区、授权三个隐藏配置导入成功后后端真正连接数据库靠的是 JDBC 配置。在这个 Spring 时代的老项目里配置文件通常叫jdbc.properties或application.properties里面写着数据库地址、端口、库名、用户名、密码。你需要重点检查三项。第一项是密码匹配。很多人本机 MySQL 的 root 密码跟项目里写的不一样项目里写的是123456你本机设的是admin123那启动后端必然报Access denied for user。解决方法是把配置文件改成你本机真实密码或者把你 MySQL 的 root 密码临时改成123456我倾向于改配置文件因为不动数据库全局状态。第二项是时区参数。MySQL 5.7 默认时区不是 UTC 也没有大问题但 JDBC 连接串里如果没有serverTimezoneAsia/Shanghai有些版本的驱动会报时区异常表现为所有数据库操作都失败错误日志里出现The server time zone value Öйú±ê׼ʱ¼ä is unrecognized。这是老项目最常见的「换环境就死」原因配置成项目原本带的连接串即可不要手贱移除。第三项是字符集。连接串里通常有characterEncodingutf-8如果你建库时选了 utf8 而不是 utf8mb4导入的中文数据可能正常但你新增数据时遇到特殊字符比如某些生僻字会报Incorrect string value。解决方向是统一库、表、连接串三处的字符集不要只改一处。# 一份典型的 jdbc.properties 配置以实际项目文件为准 jdbc.drivercom.mysql.jdbc.Driver jdbc.urljdbc:mysql://127.0.0.1:3306/warehouse_db?useUnicodetruecharacterEncodingutf-8serverTimezoneAsia/Shanghai jdbc.usernameroot jdbc.password123456参数说明127.0.0.1表示本机3306是 MySQL 默认端口warehouse_db是你建的库名必须和 SQL 文件里的库名一致。useUnicodetruecharacterEncodingutf-8保证中文正常读写serverTimezoneAsia/Shanghai解决时区报错。如果你用的是 MySQL 8.0 的驱动driver 类要换成com.mysql.cj.jdbc.Driver但本项目是 5.7保持原样更稳。3.3 一张表看清数据模型这份系统事实上已经把仓储业务的最小闭环搭出来了供应商供货给仓库系统记录供应商货物和采购单商品信息管理维护商品档案商品入库增加库存商品出库减少库存员工和管理员通过在线沟通模块协作。数据库表数量控制在十张左右字段命名大多直观参考下面的对应关系就能读懂模块关联表核心字段示例业务含义用户权限t_admin / 管理员表username, password系统唯一管理员登录后进入个人中心供应商t_supplier / 供应商表supplier_name, contact_phone维护供货商档案员工t_employee / 员工表employee_name, department仓库操作人员管理商品档案t_goods / 商品信息表goods_name, category_id, stock商品基础信息与库存量出入库t_stock_in / t_stock_outgoods_id, quantity, time记录每次入库/出库流水供应商货物t_supplier_goodssupplier_id, goods_id供应商与商品的关联关系采购t_purchasegoods_id, quantity, status采购计划与执行状态沟通t_messagesender, receiver, content内部在线沟通记录提示对接后端接口时你会在代码里频繁看到purchase、stockIn、stockOut这类命名先在上面的表结构看一眼能少走很多弯路。4. 后端启动复盘IDEA 配置 Tomcat 7 与接口自测清单4.1 用 IDEA 导入 Maven 工程而非直接打开文件这套系统是标准的 Maven 结构正确做法是在 IDEA 里选择File - New - Project from Existing Sources定位到后端工程根目录选导入 Maven 项目IDEA 会读取pom.xml并自动下载依赖。这里有两个关键设置。第一IDEA 的 Maven 设置里要指定本地仓库路径和 Maven 路径。项目中如果用到了 Maven 3.3我建议你在 IDEA 的Build Tools - Maven里把 Maven home path 指到Maven3.3目录把User settings file指到该目录conf/settings.xmlLocal repository保持默认或自定义一个干净的目录比如D:/maven-repo。这样能避免用 IDEA 内置的 Maven 版本拉依赖时出现版本冲突。第二Java SDK 要选 1.8。在Project Structure里把 Project SDK 和 Module language level 都设为 8如果你机器上装了多个 JDK务必确认使用的是 1.8不然编译会报invalid source release: 17或类似的版本错误。!-- pom.xml 关键依赖结构示例部分版本号按原文工程为准 -- dependencies !-- Spring 全家桶或 SSM 组合依赖 -- dependency groupIdorg.springframework/groupId artifactIdspring-webmvc/artifactId version4.3.18.RELEASE/version /dependency !-- MyBatis 或 MyBatis-Plus看原文工程实际使用 -- dependency groupIdorg.mybatis/groupId artifactIdmybatis/artifactId version3.4.6/version /dependency !-- MySQL 驱动 -- dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version5.1.47/version /dependency !-- JSON 依赖用于给小程序返回数据 -- dependency groupIdcom.fasterxml.jackson.core/groupId artifactIdjackson-databind/artifactId version2.9.10/version /dependency /dependencies依赖版本与 Spring 框架版本不匹配是启动时报NoSuchMethodError的常见原因比如 Jackson 2.9 在 Spring 4.3 下相对稳换到更高版本的 Jackson 可能触发类路径冲突。因此不要盲目升级依赖版本保持工程原有的版本组合最安全。4.2 Tomcat 7 部署与启动参数后端是传统的 Servlet 容器部署方式启动前要配置一个 Tomcat Server 运行配置选好本机安装的 Tomcat 7在 Deployment 标签里把后端工程以 war 包方式添加进去。Application context 建议设置为/warehouse这样后端的访问前缀是http://localhost:8080/warehouse。启动时如果一切正常控制台会打印 Spring 容器启动日志最后出现类似INFO: Server startup in XXXX ms的字样。数据库连接池、Mapper 接口扫描、Controller 路由映射如果有问题都会在这阶段抛异常。你需要在浏览器里直接访问几个简单的接口来验证后端是否真的活着而不是只看 IDEA 输出里有没有报错。注意小程序发请求的地址不要带war包名以外的多余前缀后端接口通常符合/warehouse/login、/warehouse/stockIn/list这类风格。如果你把 context 设成了/接口路径又变了一套小程序端的 baseURL 也要对应改。# 手动验证后端是否启动成功Windows 下在 CMD 里执行 # 检查登录接口是否返回 JSON curl http://localhost:8080/warehouse/login?usernameadminpassword123456 # 期望结果是返回一个 JSON里面包含成功标记和用户信息 # 如果返回 404优先检查部署的 context 路径和 Controller 的 RequestMappingcurl 命令里的参数说明-X POST可以指定 POST 请求具体看后端接口的RequestMapping方式是 GET 还是 POST返回的内容如果是一段乱码大多是 logback 或 console 输出编码问题不影响接口功能但你要是想在浏览器里看清楚中文把 IDEA 的 console 编码设为 UTF-8 再重启一次。4.3 接口自测清单按业务流程走一遍不要等小程序写完再去测接口后端启动后先用工具把接口挨个调通。按照仓储业务的自然流程来做功能验证你会顺手把后端和数据库的坑都排除掉管理员登录验证账号密码校验与 session供应商新增、列表验证基本的 CRUD 与分页商品分类维护商品新增并设置初始库存商品入库操作传入商品 ID 和数量观察库存是否增加商品出库操作传入数量观察库存是否扣减供应商货物关系绑定采购单创建与状态流转在线沟通里的消息发送与读取。每一轮测试如果返回的是错误堆栈请先看最早的那一行 Caused by而不是盯着最后的异常描述。我在排查这类老项目时十有八九是数据库字段和实体类属性对不上比如表里字段叫goods_id实体类属性叫goodsIdMyBatis 的结果映射没配好就会报BadSqlGrammarException或Undefined column。这种情况去检查 Mapper XML 里resultMap的定义即可。5. 小程序端对接实录HBuilderX 加载工程与登录态打通5.1 用 HBuilderX 还是微信开发者工具我先说差别项目说明里写的是「HBuilderX / 微信开发者工具」两者用途不同微信开发者工具是调试小程序最终效果的标准环境HBuilderX 适合改代码、写页面它内置的 uni-app 语法和微信小程序的 WXML/wxss 有差异。这个项目的前端如果带.vue后缀文件大概率是 uni-app 工程所以你的打开方式是先用 HBuilderX 导入整个小程序前端目录等待依赖安装完成后在 HBuilderX 里选择「运行到小程序模拟器」它会自动拉起微信开发者工具加载编译后的产物。如果你发现工程里面的文件全是.wxml、.js、.json的原生小程序结构那就直接用微信开发者工具打开不需要经过 HBuilderX。判断方法很简单看根目录下有没有manifest.json或pages.json有就是 uni-app 工程只有app.json就是原生小程序工程。这个资源标题里写的是「微信小程序」且文件列表里出现.vue备份文件实际以解压后的工程目录为准。5.2 修改 request 的 baseURL 指向本地后端小程序运行后第一个要改的就是接口地址。默认代码里大概率写的是开发者的 IP 或 localhost你需要在所有wx.request或uni.request封装处把 baseURL 改成http://127.0.0.1:8080/warehouse。注意一个关键限制微信开发者工具必须勾选「不校验合法域名」否则本地调试时 request 会被拦根本发不出去。// utils/request.js 中常见的基础路径配置写法以项目实际代码为准 const BASE_URL http://127.0.0.1:8080/warehouse function request(url, method, data) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL url, method: method || GET, data: data || {}, header: { Content-Type: application/json }, success: (res) { // 后端返回的 code 为 200 时视为业务成功具体字段看后端封装 if (res.data res.data.code 200) { resolve(res.data) } else { reject(res.data) } }, fail: (err) { reject(err) } }) }) } module.exports { request, BASE_URL }代码逻辑说明这里把BASE_URL单独提出来后面所有页面调用request(/login, POST, {username, password})时都会自动拼上这个前缀。header里的Content-Type要和后端RequestBody接收方式匹配如果后端接口是用RequestParam接收表单参数这里就要改成application/x-www-form-urlencoded否则后端拿不到参数值。提示如果你用真机预览127.0.0.1指向的是手机本机不是你的电脑必须改成电脑在局域网里的 IP且 Windows 防火墙要放行 8080 端口。这是小程序联调最容易忽略的一步。5.3 登录页、个人中心与「不能只看得到页面」这个小程序的页面设计是典型的毕设结构登录入口、供应商管理、员工管理、商品分类、商品信息、商品入库、商品出库、供应商货物、货物采购、在线沟通、系统管理、个人中心。你逐一点进每个页面的时候不要只盯着 UI 是否渲染要看请求是否真的发出、后端是否真的返回。很多仓库源码存在「页面齐全、接口缺失」的情况——前端调一个接口后端根本没有对应 Controller 方法。你需要在微信开发者工具的 Network 面板里观察每个请求的状态码凡是 404 或 500直接去后端代码里搜索对应 URL。比如「商品入库管理」页预期调用 POST/stockIn/add传goodsId、quantity、userId你可以先用小程序页面操作一次然后用 Navicat 查t_stock_in表和t_goods表的库存字段是否同步变化。如果不变化说明后端逻辑有断点常见的断点是事务没有生效出库扣减库存失败但主表记录却插入成功。查看对应 Service 类上是否有Transactional注解没有的话补上并确认 Spring 配置里开启了事务管理。5.4 页面样式对不齐先找 .bak 文件项目里有多个.vue或.css的.bak文件比如IndexHeader.vue.bak、BreadCrumbs.vue.bak、main.css.bak。这些文件其实是修改前的备份内容上往往和当前生效文件有细微差别。如果你改完当前页面发现样式崩了把.bak文件内容复制回正式文件能快速回到「至少能看」的状态。这套系统的前端 UI 不是重点答辩时老师也不会盯着像素级样式挑刺所以遇到样式问题不要花大量时间调 CSS。# 以 Windows 为例回退备份文件到正式文件 copy /y 小程序目录\styles\main.css.bak 小程序目录\styles\main.css copy /y 小程序目录\components\IndexHeader.vue.bak 小程序目录\components\IndexHeader.vue命令含义copy /y表示复制且不询问是否覆盖.bak文件是同目录下的历史版本覆盖后再到微信开发者工具里点击编译如果页面恢复正常说明改之前的文件是稳定的。需要注意的是.bak文件不一定是最新可用的版本如果回退后功能报错再结合日期和文件内容判断哪一版更合适不必迷信所有.bak。6. 避坑手册三次复现失败的真实原因与补救办法6.1 端口被占用导致后端启动失败现象IDEA 里启动 Tomcat控制台报Port 8080 was already in use浏览器访问http://localhost:8080显示的是别的页面或者干脆拒绝连接。原因本机之前启动过其他 Tomcat 实例或者某个 Java 进程比如 Maven 内嵌服务器占了 8080 端口。微信开发者工具或 HBuilderX 的某些内置服务也可能占用 8080。解决先查出占用进程杀掉然后再启动后端。# 查看 8080 端口占用情况 netstat -ano | findstr 8080 # 假设查到进程 PID 为 12345强制结束该进程 taskkill /PID 12345 /F注意结束进程前确认它是安全的不要误杀系统的关键进程。6.2 小程序 request 发送后报ERR_CERT_COMMON_NAME_INVALID或直接 fail现象微信开发者工具里点登录请求发不出去Console 报证书错误或request:fail。原因开发者工具默认校验 HTTPS 域名和证书你本地用的是http://且 IP 是127.0.0.1不在合法域名列表里。解决在微信开发者工具的「详情 - 本地设置」里勾选「不校验合法域名、web-view业务域名、TLS 版本以及 HTTPS 证书」。如果你做的是真机预览则需要关闭手机端调试时将 request 请求设置为不校验合法域名或者在公众平台里把域名配置成 HTTPS 的正式地址但对于毕设演示来说工具勾选即可。6.3 数据库导入后Table doesnt exist现象后端启动时 MyBatis 映射报错提示某张表不存在但你在 Navicat 里明明能看到这个表。原因项目里多个 Mapper XML 文件中的表名大小写与数据库实际表名不一致或者后端配置的库名和导入 SQL 的库名不是同一个。MySQL 在 Windows 下表名大小写不敏感但在某些 Docker 镜像或配置了lower_case_table_names0的情况下就敏感。解决建议统一把所有表名写成小写并在 JDBC 连接串里增加lower_case_table_names1参数让 MySQL 忽略大小写差异。同时检查 Spring 配置里的mapper-locations是否正确扫到了 XML 文件漏扫会报Invalid bound statement (not found)。6.4 小程序页面渲染但数据为空现象页面跳转正常列表区域空白Network 面板里显示请求成功返回的数据里data字段是空数组。原因后端接口返回成功但 SQL 查询条件把数据过滤掉了最常见的是分页参数传递错误。小程序端传入的pageNum从 0 开始后端从 1 开始或者搜索关键字字段名对不上比如前端传name后端实体用goodsName。解决在 Network 面板中复制出实际请求 URL先在浏览器里直接访问逐个调整参数找到后端 SQL 打印日志看看实际执行的语句是什么MyBatis 开放 SQL 日志只需在配置文件里把log-impl设置为StdOutImpl# mybatis 配置文件里的日志设置 mybatis.configuration.log-implorg.apache.ibatis.logging.stdout.StdOutImpl设置后IDEA 控制台会打印每次执行的 SQL 和传入参数你一眼就能看出查询条件是不是写反了。血泪经验这个项目里「商品入库」和「商品出库」两个接口的入参结构几乎一样但字段含义完全相反复制粘贴代码时最容易把stockIn的 service 调成stockOut的 mapper导致数据进去的数量不对。遇到这种问题去 Service 层逐行比对代码即可。6.5 用户反馈登录永远提示密码错误现象无论怎么输入管理员初始密码小程序端都提示账号或密码错误但用同一个账号密码在浏览器后端接口里测却能成功。原因大多数情况下是密码在传输前做了加密而加密密钥或方法前后端不一致。这个项目的后端密码通常是 MD5 加密存储前端如果直接明文提交后端拿到的值再 MD5 一次就和库里不一致了。解决找到小程序登录页的 JS 代码看提交前是否调用了加密函数后端对比密码的地方是否相同算法。如果后端的 controller 里先MD5.encode(password)再查库那么前端就不要再加密直接传明文如果后端没有加密但数据库里存的是密文你需要用 Navicat 手动更新密码字段。-- 如果数据库里存储的是 MD5 密文手动生成对应密文更新 -- 例如把管理员密码重置为 123456 UPDATE t_admin SET password MD5(123456) WHERE username admin;注意更新数据库前先备份或者记录原始明文毕设答辩阶段密码搞丢了是常有的事这样一句 SQL 就是你的后悔药。7. 进阶一项把本地系统搬到云服务器部署并保留本地联调能力7.1 云端环境与本地环境的差异很多人答辩前想把系统部署到云服务器上用手机直接演示小程序但其实本地联调已经足够。如果你确实需要云端部署不要直接用本地的 Tomcat 和 MySQL 安装包建议在服务器上保持相同的版本CentOS 7 或 Ubuntu 18.04 JDK 1.8 MySQL 5.7 Tomcat 7。版本一旦不一致本地能跑、线上报错的现象会非常磨人。我一般会先在后端工程根目录执行打包命令生成 war 包然后把 war 丢到 Tomcat 的webapps目录下启动 Tomcat 自动解压。部署完成后先用 curl 测试后端接口能通再改小程序的 baseURL 为服务器公网 IP。# 在服务器上验证后端接口能否访问 curl http://你的服务器公网IP:8080/warehouse/login?usernameadminpassword123456如果 curl 返回 JSON说明后端和数据库都正常如果提示连接超时需要在云服务商的控制台安全组里放行 8080 端口这是第一次部署的人最容易忽略的步骤。7.2 手机连不上后端时优先排查的三件事真机调试时小程序请求不到数据我建议按顺序排查第一服务器防火墙是否放行 8080 端口第二小程序代码里的 baseURL 是否写成了localhost改成公网 IP第三小程序开发工具里是否开启了「不校验合法域名」同时真机预览的调试模式也要设置。做完这三件大多数连接问题都能解决。如果涉及到 HTTPS小程序正式上线要求所有请求必须是 HTTPS 且域名已备案那么你要在 Nginx 里配置 SSL 证书并反向代理到 Tomcat 的 8080。这一步不是毕设必需但如果你工作后继续做小程序这是必学的操作。# Nginx 反向代理配置参考路径和证书以实际为准 server { listen 443 ssl; server_name yourdomain.com; ssl_certificate /etc/nginx/ssl/yourdomain.pem; ssl_certificate_key /etc/nginx/ssl/yourdomain.key; location /warehouse/ { proxy_pass http://127.0.0.1:8080/warehouse/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }这段配置的作用是让公网用户通过 HTTPS 访问你的小程序接口Nginx 再把请求转发给本机 Tomcat。这样小程序端 baseURL 就可以写https://yourdomain.com/warehouse不必暴露 8080 端口。从那以后我每次拿到这类「已交付源码包」都强制自己先走一遍「环境核对 → 数据库导入 → 后端启动 → 小程序接口联调 → 集中排错」这个全流程项目能不能用、哪一层有坑跑一遍就彻底清楚了。这套仓储管理系统里还藏着不少可以深挖的扩展点比如把在线沟通模块优化成 WebSocket 实时聊天、把出入库流水改成定时报表都是一眼就能看出潜力的毕设升级方向。希望这篇能帮你把无头绪的源码包变成答辩时稳重落地的项目祝顺利。本文还有配套的精品资源点击获取
返回列表