微信小程序购物商城带Java后端：前后端分离实战骨架与避坑指南

简介：这是一套面向计算机专业学生与Java后端开发初学者的微信小程序购物商城完整项目，适合作为课程设计、毕业设计或技能实训的参考方案。项目采用微信小程序前端搭配Java后端，实现商品分类与关键字检索、购物车增减数量、订单提交与收货地址管理，以及管理员在Web端处理待发货订单、填写物流信息、管理商品与图片、回复用户评价等完整业务闭环。压缩包共1539个文件，约10.27MB，涵盖176个Java源文件、305个JavaScript脚本、385个HTML页面、219张PNG与185张GIF素材，以及WXML、WXSS、XML、SQL、JSON等配置与数据库文件，前后端与文档说明齐备。已有205人学习下载。源码均经本地编译可运行，评审分达95分以上，难度适中且经助教老师审定，读者可据此掌握小程序与Java后端联调、订单状态流转及后台管理的实现思路。

1. 微信小程序购物商城带 Java 后端：一套能跑通的前后端分离实战骨架

很多人第一次接触「微信小程序购物商城 app 设计带 Java 后端 + 源代码 + 文档说明 + 数据库」这类打包项目，第一反应是解压、导入、点运行，然后卡在登录接口 500。我当年也这样，翻车翻得挺彻底。这套东西的本质不是「一个能直接上线的商城」，而是一套前后端分离项目实战的完整骨架：小程序端负责页面渲染和交互，Java 后端负责业务逻辑和鉴权，数据库负责商品、订单、用户三类核心数据的落地。它适合两类人——想拿一个真实项目练手 Java 后端和微信小程序联调的新手，以及需要一份结构完整、能改能扩的课程设计或毕设底稿的人。真正值钱的不是那堆源代码本身，而是它把「小程序怎么调后端、后端怎么连数据库、数据库表怎么设计」这条链路完整摆在你面前。下面我按自己复现和改造这套东西的顺序，把每一步讲透。

2. 先看清这套商城骨架的四个组成部分

2.1 小程序端、Java 后端、数据库、文档各自管什么

拿到一个压缩包，别急着跑。先按目录把职责拆开看，这是避免后面瞎改的前提。常见做法是根目录下分三块：小程序源码目录、后端 Java 工程目录、数据库脚本目录，外加一份文档说明。小程序端通常用原生微信小程序语法或 uni-app 打包，页面包括首页商品列表、商品详情、购物车、订单确认、个人中心这几类。Java 后端一般是 Spring Boot 单体，对外暴露 REST 接口，对内用 MyBatis 或 JPA 操作数据库。数据库脚本是.sql文件，建库建表加初始数据。

先确认这四块能不能对上号，比直接点运行重要得多。文档里写的接口路径，经常和代码里的@RequestMapping对不上，这是打包项目最常见的坑之一。

2.2 数据库表结构决定了后端能写多顺

商城类项目的表设计基本绕不开用户、商品、分类、购物车、订单、订单明细这几张。你打开.sql文件，重点看三件事：主键是不是自增、外键关联有没有、金额字段用的什么类型。金额千万别用 float，用decimal(10,2)，这是血泪经验，用 float 算总价会出现 0.1+0.2 那种玄学误差。

-- 商品表核心字段示例 CREATE TABLE `product` ( `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '主键', `category_id` BIGINT NOT NULL COMMENT '分类ID', `name` VARCHAR(128) NOT NULL COMMENT '商品名', `price` DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT '单价，禁用float', `stock` INT NOT NULL DEFAULT 0 COMMENT '库存', `cover_url` VARCHAR(255) DEFAULT NULL COMMENT '封面图', `status` TINYINT NOT NULL DEFAULT 1 COMMENT '1上架 0下架', PRIMARY KEY (`id`), KEY `idx_category` (`category_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这段建表语句里，DECIMAL(10,2)保证金额精确到分，utf8mb4保证商品名里的 emoji 和生僻字不乱码，idx_category让按分类查商品不至于全表扫描。参数上，stock用 INT 而不是无符号，是为了后面做库存扣减时能出现负数报警而不是直接溢出。你如果拿到的是别人写好的脚本，先跑一遍看有没有报错，再决定要不要改字段类型。

2.3 后端接口清单要先跑通再谈改功能

后端能不能起来，取决于三处配置：数据库连接、端口、以及接口前缀。打开application.yml或application.properties，把数据库地址、账号密码改成你本地的，然后启动。启动成功后，别急着连小程序，先用浏览器或接口工具测一个最简单的接口，比如商品列表。

# 启动后端（Maven 项目常见方式） mvn spring-boot:run # 另开终端，测商品列表接口 curl "http://localhost:8080/api/product/list?page=1&size=10"

mvn spring-boot:run会按pom.xml拉依赖并启动内嵌 Tomcat，默认端口看配置文件。curl那条命令里的page和size是分页参数，商城列表几乎都要分页，这也是热搜里「微信小程序页面列表加载更多」对应的后端能力。如果返回一堆 JSON 数据，说明后端和数据库通了；如果报 500，先看控制台异常栈，八成是数据库连不上或表不存在。这一步跑通，后面小程序联调才有意义。

3. 把小程序端和后端接起来的最小闭环

3.1 改 baseURL 和配置合法域名

小程序调后端，第一步是把请求地址指到你自己的后端。原生小程序一般在utils/request.js或app.js里封装了请求方法，找到里面的 baseURL 改成你后端的地址。本地开发时，微信开发者工具里要勾选「不校验合法域名」，否则localhost会被拦。

// utils/request.js 常见封装 const BASE_URL = 'http://localhost:8080/api'; function request(options) { return new Promise((resolve, reject) => { wx.request({ url: BASE_URL + options.url, // 拼接完整接口路径 method: options.method || 'GET', data: options.data || {}, header: { 'content-type': 'application/json' }, success: (res) => { if (res.statusCode === 200) { resolve(res.data); } else { reject(res); // 非200统一走失败分支 } }, fail: reject }); }); } module.exports = { request };

这段封装把wx.request包成 Promise，方便页面里用 async/await。BASE_URL是唯一需要改的地址，header里声明 JSON 格式，后端才能正确解析。注意statusCode === 200这个判断，很多打包项目后端返回的是{code:200, data:...}这种业务码，那就要改成判断res.data.code，别照抄。改完在首页调一次商品列表，能在控制台看到数据，闭环就成了一半。

3.2 列表加载更多怎么接后端分页

热搜里「微信小程序页面列表加载更多」是高频需求，商城首页、订单列表都要用。核心是维护一个页码，触底时页码加一，再请求下一页，把新数据拼到旧数组后面。

Page({ data: { list: [], page: 1, size: 10, hasMore: true }, onLoad() { this.loadList(); }, loadList() { if (!this.data.hasMore) return; // 没有更多就不再请求 request({ url: '/product/list', data: { page: this.data.page, size: this.data.size } }).then(res => { const newList = res.data.records || []; this.setData({ list: this.data.list.concat(newList), // 拼接而非覆盖 page: this.data.page + 1, hasMore: newList.length === this.data.size // 满页说明可能还有 }); }); }, onReachBottom() { this.loadList(); } // 触底加载 });

concat而不是直接赋值，是为了保留已加载的数据。hasMore用「本页数量是否等于 size」判断，是常见简化做法，更严谨的应该用后端返回的总条数。onReachBottom是小程序页面触底的生命周期，不用自己监听滚动。参数上size别设太大，10 到 20 比较稳，太大首屏慢，太小请求频繁。

3.3 登录态和购物车数据怎么串起来

商城离不开登录。常见做法是小程序端调wx.login拿 code，传给后端换 openid，后端生成 token 返回，之后请求带 token。购物车数据可以存后端，也可以先存本地缓存，登录后再合并。

// 登录并保存 token wx.login({ success: (res) => { request({ url: '/user/login', method: 'POST', data: { code: res.code } }).then(r => { wx.setStorageSync('token', r.data.token); // 本地存token }); } });

wx.login的 code 只能用一次，后端拿它去换 openid。wx.setStorageSync把 token 存本地，后续请求在 header 里带上。这里要注意，token 别写死在代码里，也别放全局变量，页面刷新就丢。购物车如果存本地，用wx.setStorageSync('cart', ...)，登录后调一个合并接口把本地购物车推到后端，这是比较顺的路径。

4. 避坑与排查：这套打包项目最容易翻车的地方

4.1 后端启动报数据库连接失败

现象：启动就抛Communications link failure或Access denied。原因通常是配置文件里的数据库地址、端口、账号密码和你本地不一致，或者 MySQL 没启动。解决：先确认 MySQL 服务在跑，再用命令行mysql -u root -p登一次，然后逐项核对application.yml里的url、username、password。注意 url 里的时区和字符集参数，serverTimezone=Asia/Shanghai和characterEncoding=utf8建议都带上，否则时间字段和中文容易出问题。

4.2 小程序请求全部失败但后端日志没反应

现象：小程序控制台报请求失败，后端一条日志都没有。原因基本是请求根本没发出去，被域名校验拦了，或者 baseURL 写错。解决：开发者工具里勾选「不校验合法域名」，确认 baseURL 的端口和后端一致，确认后端确实在监听那个端口。如果用了真机调试，localhost 要换成电脑局域网 IP，手机和电脑得在同一网络下。

4.3 商品图片不显示

现象：列表有数据但图片是空白。原因通常是数据库里存的是相对路径或本地路径，小程序加载不到。解决：把图片路径改成完整 URL，或者把图片放到后端静态资源目录并通过后端地址访问。检查cover_url字段里存的值，如果是D:\images\1.jpg这种，肯定不行。常见做法是后端提供一个静态资源映射，图片走http://后端地址/images/xxx.jpg。

4.4 下单后库存没扣或扣成负数

现象：下单成功但库存不变，或者并发下库存变负。原因是没有做库存扣减，或者扣减语句没加条件。解决：扣库存时用带条件的更新，UPDATE product SET stock = stock - 1 WHERE id = ? AND stock > 0，根据影响行数判断是否成功。别先查再改，那样并发下必出问题。这是商城类项目最典型的坑，打包项目里经常只写了查询没写扣减。

4.5 文档里的接口和代码对不上

现象：照着文档调接口一直 404。原因：打包项目文档往往是早期版本，代码改过但文档没更新。解决：以后端代码为准，全局搜@RequestMapping和@GetMapping，把真实路径列出来。别死磕文档，文档只能当参考。我一般会先把所有 Controller 扫一遍，自己整理一份真实接口清单再动手。

5. 把这套骨架改成能拿得出手的作品

5.1 先做减法再做加法

这套打包项目功能往往堆得很全，但代码质量参差。我的习惯是先做减法：把用不到的功能模块注释掉或删掉，只留商品、购物车、订单这条主链路，跑通之后再逐个加回。这样出问题时排查范围小。加法阶段优先补三样：接口统一返回格式、全局异常处理、参数校验。这三样加上去，代码立刻像个正经项目。

// 统一返回格式示例 public class Result<T> { private int code; private String msg; private T data; public static <T> Result<T> ok(T data) { Result<T> r = new Result<>(); r.code = 200; r.msg = "success"; r.data = data; return r; } public static <T> Result<T> fail(String msg) { Result<T> r = new Result<>(); r.code = 500; r.msg = msg; return r; } }

统一返回格式的好处是小程序端只用判断一个code字段，不用每个接口写一套解析逻辑。ok和fail两个静态方法覆盖绝大多数场景。加上@RestControllerAdvice做全局异常捕获，后端抛异常时也能返回统一格式，而不是一坨 HTML 错误页。

5.2 用接口文档工具替代手写文档

手写文档一定会过期。常见做法是引入 Swagger 或 Knife4j，在代码里加注解，启动后自动生成接口文档。这样接口改了文档自动更新，小程序端同学也能直接在线调试。加依赖、加配置类、加注解三步，网上例子很多，这里不展开。重点是养成「代码即文档」的习惯，比维护一份 Word 靠谱得多。

5.3 数据库改动要留脚本

改表结构时别直接在数据库里点，要写成.sql脚本存起来。比如加一个字段，就写一个alter table脚本，按日期命名。这样换台机器或者交给别人，跑一遍脚本就能还原。我吃过亏，本地改完没记录，换电脑后死活想不起来改了啥。数据库同步软件可以用，但脚本才是后悔药。

5.4 验证这套东西值不值得投入

判断标准很简单：你能不能在不看文档的情况下，自己把「小程序点商品 → 后端查数据库 → 返回 JSON → 页面渲染」这条链路讲清楚并复现。能，说明这套骨架已经被你吃透，可以往上加功能或者写进简历；不能，说明还停在「能跑但不懂」的阶段，建议把请求封装、Controller、Service、Mapper 四层各挑一个接口逐行读一遍。这套东西的价值不在代码本身，而在于它给了你一条完整链路去练手。我现在的习惯是，拿到任何打包项目，先跑通主链路，再画一张请求流转图，画不出来就说明没懂。希望帮到你。

本文还有配套的精品资源，点击获取