微信小程序+Java点餐系统毕设：从零跑通前后端分离项目实战

简介这份资源是面向高校计算机相关专业学生与Java初学者的一套微信点餐系统毕业设计完整方案采用微信小程序前端搭配Java后端的技术路线可用于毕业设计、课程设计或项目实战练习帮助解决从选题到落地缺少可运行参考项目的问题。压缩包共1286个文件约13.72MB涵盖小程序端的wxml、wxss、js与json配置后端123个java源文件及xml、yml、properties等配置另有vue、ts、scss等管理端页面资源以及sql数据库脚本、说明文档与bat启动脚本前后端与数据库结构相对完整。目前已有570人学习下载可作为同类选题的参考模板。读者可据此梳理小程序与Java服务端的接口对接方式、数据库表设计与页面组织思路并借助说明文档与脚本快速还原运行环境对照源码理解点餐业务的核心流程与实现细节。1. 从一份点餐系统毕设说起微信小程序加 Java 后端到底能跑多远很多做计算机毕业设计的人选题时第一反应就是「点餐系统」因为场景熟悉、需求清晰、演示直观。但真正动手才发现坑不在业务逻辑而在微信小程序和 Java 后端这两端怎么接上。我见过太多人前端页面画得漂漂亮亮后端接口也写完了结果卡在登录态、跨域、图片上传这些环节上最后只能拿一个半成品去答辩。这份「基于微信小程序Java后端的微信点餐系统毕业设计」要解决的就是把这套组合从零跑通小程序端负责顾客点餐、下单、查看订单Java 后端负责菜品管理、订单处理、数据持久化。它适合正在做毕业设计的学生也适合想练手前后端分离项目实战的开发者。你不需要一开始就追求高并发和分布式先把一条完整的「浏览菜品 → 加入购物车 → 提交订单 → 后端落库 → 小程序查单」链路跑通比什么都重要。这一篇就按这个目标把选型、建表、接口、联调、避坑一次讲透。2. 技术选型与项目骨架为什么是微信小程序加 Java 后端2.1 小程序端选原生还是框架做微信小程序项目第一个决策是前端用什么写。常见做法有三种原生小程序、uni-app、Taro。原生小程序的优势是离微信最近API 调用没有中间层调试时真机表现和开发者工具一致遇到微信小程序顶部导航栏高度、单选框样式这类细节问题直接查官方文档就能解决。uni-app 和 Taro 适合需要同时发布到多个平台的场景但会引入编译层出问题时排查链路更长。对于毕业设计我一般建议用原生小程序。原因很实际答辩老师不会因为你用了跨端框架就加分但会因为「真机跑不起来」扣分。原生小程序的页面结构就是 WXML WXSS JS JSON 四件套学习成本低社区里微信小程序项目实例也多遇到问题容易搜到答案。项目骨架大致如下miniprogram/ pages/ index/ 首页与菜品列表 cart/ 购物车 order/ 订单确认与提交 my/ 个人中心与订单列表 utils/ request.js 统一请求封装 auth.js 登录态管理 app.js app.json app.wxss这个结构不复杂但每个目录的职责要分清。utils/request.js是后面联调的关键所有对 Java 后端的请求都走它方便统一加 token、统一处理错误码。2.2 Java 后端选 Spring Boot 还是传统 SSM后端这边毕业设计常见的选择是 Spring Boot 和 SSMSpring Spring MVC MyBatis。SSM 配置量大XML 写起来繁琐但有些学校要求必须体现「三大框架整合」。Spring Boot 则是当前 Java 后端完整成长路线里的主流起点自动配置省去大量样板代码起步快。如果学校没有硬性要求 SSM我建议直接用 Spring Boot。版本上选 2.7.x 或 3.x 都行但要注意 JDK 版本匹配Spring Boot 3.x 要求 JDK 17 及以上如果本地装的是 JDK 8就老老实实用 2.7.x。数据库用 MySQL 8ORM 用 MyBatis-Plus它比原生 MyBatis 少写很多单表 CRUD 代码分页插件也现成。一个最小可用的pom.xml依赖清单dependencies !-- Web 层提供 REST 接口 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- 持久层MyBatis-Plus 简化单表操作 -- dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency !-- MySQL 驱动 -- dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency !-- Lombok减少 getter/setter 样板代码 -- dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency /dependencies参数说明mybatis-plus-boot-starter的版本要和 Spring Boot 版本兼容3.5.x 系列对 Spring Boot 2.7 和 3.x 都有对应支持选的时候看清楚。Lombok 在 IDE 里需要装插件否则编译会报「找不到符号」。2.3 前后端分离的边界怎么划前后端分离项目实战里最容易扯皮的就是「这个逻辑该谁做」。我的划分原则很简单小程序端只管展示和交互所有涉及数据计算、状态变更、权限判断的逻辑全部放后端。举个例子购物车里的总价小程序端可以实时算给用户看但提交订单时后端必须重新算一遍不能信任前端传来的金额。再比如菜品是否售罄前端根据字段显示「已售罄」没问题但下单接口必须再查一次数据库防止并发情况下超卖。接口统一用 JSON 通信路径以/api开头例如/api/dish/list、/api/order/create。返回结构统一成{ code: 200, msg: success, data: {} }code用 HTTP 状态码风格200 表示成功401 表示未登录500 表示服务端异常。这样小程序端在request.js里可以统一拦截401 就跳登录页500 就弹提示不用每个页面单独写判断。3. 数据库设计与核心表结构五张表撑起点餐主流程3.1 从点餐流程反推表结构不要先想「我要建哪些表」而是先把用户操作路径写下来打开小程序 → 浏览菜品分类 → 选菜加购物车 → 确认订单 → 提交 → 查看订单状态。每一步涉及哪些数据表就出来了。核心需要五张表用户表、菜品分类表、菜品表、订单表、订单明细表。购物车可以放小程序本地缓存也可以建表存服务端毕业设计里为了体现数据库能力建议建一张购物车表。3.2 建表 SQL 与字段说明-- 用户表存微信 openid 和基本信息 CREATE TABLE user ( id BIGINT NOT NULL AUTO_INCREMENT, openid VARCHAR(64) NOT NULL COMMENT 微信用户唯一标识, nickname VARCHAR(64) DEFAULT NULL, avatar_url VARCHAR(255) DEFAULT NULL, phone VARCHAR(20) DEFAULT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_openid (openid) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 菜品分类表 CREATE TABLE category ( id BIGINT NOT NULL AUTO_INCREMENT, name VARCHAR(32) NOT NULL, sort INT DEFAULT 0 COMMENT 排序值越小越靠前, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 菜品表 CREATE TABLE dish ( id BIGINT NOT NULL AUTO_INCREMENT, category_id BIGINT NOT NULL, name VARCHAR(64) NOT NULL, price DECIMAL(10,2) NOT NULL, image VARCHAR(255) DEFAULT NULL, description VARCHAR(255) DEFAULT NULL, status TINYINT DEFAULT 1 COMMENT 1上架 0下架, PRIMARY KEY (id), KEY idx_category (category_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 订单表 CREATE TABLE orders ( id BIGINT NOT NULL AUTO_INCREMENT, user_id BIGINT NOT NULL, order_no VARCHAR(32) NOT NULL COMMENT 业务订单号, total_amount DECIMAL(10,2) NOT NULL, status TINYINT DEFAULT 0 COMMENT 0待支付 1已支付 2已完成 3已取消, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 订单明细表 CREATE TABLE order_item ( id BIGINT NOT NULL AUTO_INCREMENT, order_id BIGINT NOT NULL, dish_id BIGINT NOT NULL, dish_name VARCHAR(64) NOT NULL COMMENT 冗余存名称防止菜品改名后订单显示错乱, price DECIMAL(10,2) NOT NULL, quantity INT NOT NULL, PRIMARY KEY (id), KEY idx_order (order_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;几个关键点user表的openid必须加唯一索引因为微信登录时同一个用户可能多次请求没有唯一约束会插入重复记录。order_item里冗余存dish_name和price这是血泪经验——菜品改价或下架后历史订单必须显示下单时的信息不能关联查当前菜品表。orders表的order_no用业务号而不是主键方便对账和排查。3.3 索引与字段类型容易翻车的地方金额字段用DECIMAL(10,2)不要用FLOAT或DOUBLE浮点数算钱会出现0.1 0.2 0.30000000000000004这种玄学问题。状态字段用TINYINT而不是VARCHAR省空间且比较快。时间字段统一DATETIME不要用TIMESTAMP后者有 2038 年上限虽然毕业设计用不到那么久但习惯要养好。外键约束在毕业设计里可以不加用应用层保证一致性。原因是加了外键后测试时删数据很麻烦而且有些云数据库默认不支持外键。但索引必须加category_id、user_id、order_id这些关联字段没索引数据量一上来查询就慢。4. 小程序端与 Java 后端联调登录、请求封装与图片上传4.1 微信登录换 token 的完整链路微信小程序的登录不是账号密码而是wx.login拿到临时code传给后端后端用code加appid、secret调微信接口换openid和session_key然后生成自己的 token 返回给小程序。小程序后续请求都带这个 token。小程序端代码// utils/auth.js export function login() { return new Promise((resolve, reject) { wx.login({ success: (res) { if (!res.code) { reject(new Error(微信登录失败)); return; } // 把 code 发给自己的 Java 后端 wx.request({ url: http://localhost:8080/api/auth/login, method: POST, data: { code: res.code }, success: (resp) { const { code, data } resp.data; if (code 200) { // token 存本地后续请求带上 wx.setStorageSync(token, data.token); resolve(data); } else { reject(new Error(resp.data.msg)); } }, fail: reject }); }, fail: reject }); }); }后端对应接口用RestTemplate或HttpClient调微信的jscode2session接口拿到openid后查库没有就插入新用户然后生成 JWT token 返回。注意secret不能写在小程序端必须放后端配置文件里。4.2 统一请求封装与跨域处理小程序端没有浏览器同源策略但开发者工具里请求localhost需要勾选「不校验合法域名」。真机上必须用 HTTPS 域名毕业设计阶段可以用内网穿透工具把本地后端暴露出去但答辩演示时建议直接用开发者工具稳定。request.js封装// utils/request.js const BASE_URL http://localhost:8080/api; export function request(options) { const token wx.getStorageSync(token); return new Promise((resolve, reject) { wx.request({ url: BASE_URL options.url, method: options.method || GET, data: options.data || {}, header: { Content-Type: application/json, Authorization: token ? Bearer ${token} : }, success: (res) { if (res.statusCode 401) { // token 过期重新登录 wx.removeStorageSync(token); wx.showToast({ title: 请重新登录, icon: none }); reject(new Error(未登录)); return; } resolve(res.data); }, fail: reject }); }); }后端跨域问题在前后端分离里很常见。Spring Boot 里加一个配置类Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }参数说明allowedOriginPatterns(*)比allowedOrigins(*)更安全后者在allowCredentials(true)时会报错。maxAge(3600)表示预检请求缓存一小时减少 OPTIONS 请求次数。4.3 菜品图片上传与静态资源映射菜品图片上传是必做功能。小程序端用wx.chooseImage选图再用wx.uploadFile上传到后端。后端接收MultipartFile存到本地磁盘或对象存储返回可访问的 URL。PostMapping(/upload) public ResultString upload(RequestParam(file) MultipartFile file) { if (file.isEmpty()) { return Result.fail(文件为空); } // 用 UUID 重命名防止同名覆盖 String fileName UUID.randomUUID() _ file.getOriginalFilename(); File dest new File(uploadDir fileName); try { file.transferTo(dest); } catch (IOException e) { return Result.fail(上传失败); } // 返回可访问的 URL return Result.success(/images/ fileName); }上传目录要通过WebMvcConfigurer映射成静态资源路径否则小程序拿到 URL 也访问不到。配置Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/images/**) .addResourceLocations(file: uploadDir); }注意uploadDir结尾要带斜杠否则拼接路径会出错。这个坑我踩过排查了半天才发现是路径少了分隔符。5. 避坑与排查订单重复提交、金额精度、登录态失效5.1 订单重复提交现象用户快速点两次「提交订单」后端生成两笔一模一样的订单。原因前端按钮没有防抖后端接口没有幂等控制。解决前端提交时把按钮置灰请求返回后再恢复。后端更关键用order_no做唯一约束或者用 Redis 锁。毕业设计里简单做法是提交前先查该用户是否有「待支付」且金额相同的订单有就直接返回原订单号。更稳妥的是前端生成一个requestId后端用这个 ID 做去重。5.2 金额计算精度丢失现象购物车总价显示19.999999而不是20.00。原因JavaScript 浮点数运算精度问题0.1 0.2 ! 0.3。解决前端计算时用「分」为单位所有价格乘以 100 转成整数再算显示时除以 100。后端用BigDecimal不要用double。数据库用DECIMAL。三层都统一才能保证金额准确。5.3 登录态失效后接口全部 401现象小程序放了一段时间再打开所有请求都返回 401页面空白。原因token 过期了但前端没有统一处理每个页面各自报错。解决在request.js里拦截 401清除本地 token跳转到登录页或重新调用wx.login。关键是所有请求都走统一封装不要有的页面用wx.request裸调否则拦截不到。5.4 真机上请求失败但开发者工具正常现象开发者工具里一切正常真机预览时接口全部失败。原因真机不支持http://localhost必须用 HTTPS 域名且域名要在微信公众平台配置白名单。解决毕业设计阶段可以在开发者工具里勾选「不校验合法域名」做演示。如果要真机调试用内网穿透工具生成 HTTPS 地址或者把后端部署到有 HTTPS 的服务器上。注意微信小程序对域名有备案要求测试阶段用工具绕过即可。5.5 图片上传后小程序显示不出来现象上传成功后端返回了 URL但小程序image标签显示空白。原因静态资源映射路径不对或者返回的 URL 是相对路径小程序无法解析。解决后端返回完整 URL或者小程序端拼接BASE_URL。检查addResourceHandlers的addResourceLocations是否以file:开头且路径正确。用浏览器直接访问返回的 URL能打开说明后端没问题打不开就是映射配置错了。6. 让毕设经得起追问接口文档、异常兜底与演示技巧答辩时老师最爱问的不是「你用了什么框架」而是「如果两个人同时下单最后一份菜怎么办」「你的接口怎么保证安全」。这一章说几个能让你的项目从「能跑」变成「经得起问」的具体做法。第一接口文档不用写得多正式但每个接口的入参、出参、错误码要列清楚。用 Swagger 或 Knife4j 自动生成省事且显得专业。Spring Boot 里加依赖和配置类注解写清楚访问/doc.html就能看到。老师翻到这一页印象分直接上去。第二异常兜底要做。全局异常处理器捕获Exception返回统一格式不要把堆栈信息直接抛给前端。同时日志要打用log.error记录关键错误方便排查。答辩演示时万一某个接口报错有兜底至少页面不会崩你能从容解释。第三演示前把数据准备好。菜品图片提前上传好分类和菜品数据插好不要现场录入。订单列表里造几条不同状态的记录展示「待支付」「已完成」「已取消」的区分。演示路径提前走一遍登录 → 浏览 → 加购 → 下单 → 查单控制在三分钟内。第四准备一个「如果重做我会怎么改」的回答。比如「购物车目前存本地缓存如果做多端同步会改成服务端存储」「支付目前是模拟的接入微信支付需要商户号和证书」。这显示你有思考边界不是只会照抄。我自己的习惯是答辩前一晚把整个流程在真机上走三遍每遍记录卡顿或报错的地方当场修掉。这个笨办法救过我两次——一次是图片路径在真机上 404一次是订单状态字段前端判断写反了。希望帮到你。本文还有配套的精品资源点击获取