简介JAVA微信小程序商城源码及完整后台是一套面向Java开发者的电商小程序前后端解决方案基于SpringMVC、MyBatis、Spring、Maven和MySQL构建前端采用H5与CSS3后台管理界面基于Bootstrap-ACE框架。资源覆盖商品发布、物流管理、评价系统、优惠券、运费规则、在线客服、微信支付、在线退款及微信管理等核心电商业务模块流程完整可直接运行部署也可作为二次开发或课程设计、毕业设计的参考起点。源码按照前端页面、后端业务与后台管理进行分层组织目录结构清晰便于按需定位和修改代码。压缩包采用7z格式大小约20.5MB体量适中适合个人开发者快速下载学习。目前已有5047人浏览学习适合具备一定Java Web基础、希望快速上手微信小程序商城开发的学习者。1. 从一套「JAVA微信小程序商城源码完整后台」说起这套东西到底能给你什么这套 JAVA微信小程序商城源码完整后台在电商外包和私活市场里一直是最热的关键词背后是个真实需求用最低成本做完“小程序端选品下单 后台管商品订单”的完整闭环。常见做法是后端用 Spring Boot 搭好的接口前端是微信原生小程序再加上一份 MySQL 建表脚本和一个能录入商品、处理订单的 Web 后台。你拿着它能省下从零搭建的时间但也别指望直接双击就能上线——我见过太多人卡在数据库导入、微信登录配置和图片上传这三件事上。适合谁呢一是想快速上线自营微信小店的团队二是刚把 Java 基础学完、想拿完整项目练手的同学三是接外包需要一套可交付底盘的工程师。2. 先看后台骨架再下手Spring Boot MyBatis的商城系统是怎么组织的2.1 为什么主流源码都压Spring Boot MyBatis而不是SSH/SSM现在的 JAVA 微信小程序商城源码后台十有八九是 Spring Boot MyBatis。很多人刚学 Java 时还在背 SSHSpring MVC Spring Hibernate的配置项到了开源商城源码里你会发现那套已经属于考古范围。Spring Boot 用 starter 和自动配置把粘合逻辑收走内嵌 Tomcat 让部署变成一条java -jar命令MyBatis 又保留了 SQL 的手写自由电商后台那些多表 join、分组统计、动态条件查询用 Hibernate 的 HQL 写起来反而不直观。要是去翻 java 面试题Spring Boot MyBatis 的出现频率也远高于 SSH团队招人不用重新培训。从再造一个后台的成本看这套组合有四个实际好处第一微信支付、阿里云 OSS 这些常用 SDK 都有对应的 spring-boot-starter能省掉大量样板代码第二MyBatis 的热门框架 PageHelper 做分页方便详情页、列表页的查询条件再复杂也能用动态 SQL 扛住第三Spring Boot 的 actuator 能直接暴露健康检查接口部署在服务器上方便监控进程是死是活第四市面上你能搜到的大多数 Spring Boot mybatis 的 java 开源多商户跨境商城源码下载都是同一套骨架二次开发的资料好找。这套源码也不例外我一般会先花十分钟把包结构扫描一遍确认它是不是标准的 controller-service-mapper 三层再决定从哪开始改。为了让你判断手里源码的底子这里有一个简单的选型对比如果你是第一次接触这类项目直接用 Spring Boot 2.x MyBatis 的骨架就够了。有些老源码还标着 SSM 甚至更古老的 Spring Struts看到 Struts 可以直接放弃因为微信支付对接、文件上传那些依赖在老旧框架里处理起来全是坑不值得为省一点迁移时间搭上排错精力。2.2 小程序端和后台的鉴权链路wx.login到底换了什么小程序和传统 Web 登录最大的区别是没有 cookie也没有 session 容器所有请求都靠一个自定义 token 来认人。所以源码里有一整套隐藏链路理解它你后面改任何需要登录的接口才不会懵。链路是这样的小程序调用wx.login()拿到一个一次性 code然后用wx.request把这个 code 发给后台的登录接口后台拿到 code 后拿 appid、secret、code 去调微信的jscode2session接口换回 openid 和 session_key接着后台用 openid 查用户表查不到就自动注册一条新用户最后生成一个随机的 token 存进 Redis设置 7 天过期返回给小程序。从此刻起小程序每个请求都把这个 token 放在 header 里后台通过拦截器校验。在一套完整后台里这段代码一般长这样// AuthService.java 里最核心的三个动作 public String wxLogin(String code) { // 1. 用 code 换 openid这一步叫 jscode2session MapString, String params new HashMap(); params.put(appid, wxProperties.getAppid()); params.put(secret, wxProperties.getSecret()); params.put(js_code, code); params.put(grant_type, authorization_code); String result restTemplate.getForObject( https://api.weixin.qq.com/sns/jscode2session?appid{appid}secret{secret}js_code{js_code}grant_type{grant_type}, String.class, params); // 2. 解析 openid查表或建新用户 JSONObject json JSON.parseObject(result); String openid json.getString(openid); if (openid null) { throw new BusinessException(微信登录失败: json.getString(errmsg)); } User user userMapper.findByOpenid(openid); if (user null) { user new User(); user.setOpenid(openid); user.setAvatar(default.jpg); userMapper.insert(user); } // 3. 生成 token 放 Rediskey 里带前缀方便诊断 String token UUID.randomUUID().toString().replaceAll(-, ); redisTemplate.opsForValue().set(wxmall:token: token, user.getId(), 7, TimeUnit.DAYS); return token; }这段代码里最容易出问题的是第一步。微信接口返回的 openid 只在 code 有效期内有效code 一次性的用第二次就会报 10002还有像appid和secret这两个参数不要写死在小程序前端因为 secret 一旦暴露别人就能冒充你的用户登录。正确的做法是让小程序只传 code所有换 openid 的逻辑都留在后台。第二步的findByOpenid必须走索引openid 字段长度一般是 28 位左右建表时要给唯一索引否则流量上来后按 openid 查用户的 SQL 全表扫描接口撑不住。第三步把 token 存 Redis 而不是放 JWT 里是为了之后想在后台踢人下线时直接删掉这条 key 就能生效如果你拿到的源码用的是 JWT那就要额外维护黑名单这是另一个话题。检查你手上的小程序端代码如果看到它把 appid 和 secret 直接写在某个 js 文件里那说明这份源码的安全意识不太行。正常源码应该在小程序端只配置 appidsecret 永远只出现在后台的配置文件中。改法也简单把小程序端写死 secret 的代码删掉改成只传 code 给后台后台自己拼参数调微信接口即可。2.3 数据库设计商品、订单、用户三张主表的字段边界源码的完整后台一般会给你一张数据库设计文档没有文档的话就自己看 SQL 建表脚本。商城业务再复杂核心逃不开用户、商品、订单这三大块。我习惯把表分成三类用户相关user、user_address、member_point_log、商品相关product、sku、product_category、brand、订单相关cart、order、order_item、payment_log。如果这套源码还要做营销还会有 coupon、seckill 这类表但先不管那些基础核心是先分清楚这几张主表之间的关联。看一套开源商城源码值不值重点看它的 sku 表设计。土办法是把 product 和 sku 混在一张表里用一行记录一个颜色、一个尺码的库存价格做得好的是 product 表只放商品基础信息具体到“红色、XL、价格 199、库存 50”这种粒度全放 sku 表。后者在面对多规格商品时改价格、补库存、锁定库存都方便而且以后对接仓储系统每个 sku 就是最小的库存单位。给你一个简化结构参考-- 商品主表 CREATE TABLE product ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, title VARCHAR(200) NOT NULL COMMENT 商品标题, category_id INT UNSIGNED NOT NULL, default_image VARCHAR(500) NOT NULL, detail_html MEDIUMTEXT COMMENT 富文本详情, sales INT UNSIGNED DEFAULT 0, status TINYINT DEFAULT 1 COMMENT 1上架 0下架, create_time DATETIME NOT NULL ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品主表; -- SKU 表 CREATE TABLE sku ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, product_id INT UNSIGNED NOT NULL, specs_json JSON NOT NULL COMMENT 规格组合如 [{颜色:红},{尺码:L}], price DECIMAL(10,2) NOT NULL, stock INT UNSIGNED NOT NULL, sku_code VARCHAR(64) DEFAULT NULL COMMENT 用于对接物流/ERP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT最小库存单位表;这里有一个关键参数specs_json用 JSON 类型而不是拼接字符串。很多老源码是 “红,L” 这种逗号拼接一旦规格值里出现中文逗号或用户乱填匹配就崩。MySQL 5.7 以上原生支持 JSON查起来能用JSON_CONTAINS不过商城场景里更推荐把 specs_json 取出来在 Java 层做精确匹配性能不会差代码还好读。库存字段用INT UNSIGNED注意做好乐观锁扣库存时 SQL 带上WHERE stock #{count}避免超卖。order 表同理下单时要冗余商品标题、规格快照和成交单价防止商品之后改价或删除订单历史仍然能还原当时的交易现场。3. 本地跑通这套源码数据库初始化、配置档位、开发者工具联调三连3.1 导入MySQL数据库字符集和时区是第一步拿到源码压缩包先别急着解压运行第一步是建库导表。源码包里的 SQL 文件一般是shop.sql或者db/shop.sql而且常常只包含表结构和一部分测试数据没有建库语句。你需要在 MySQL 里手动建库再导入。我习惯在命令行里操作比 Navicat 导入大 SQL 更不容易卡死。# 创建一个专门给商城的库字符集直接定成 utf8mb4 mysql -uroot -p -e CREATE DATABASE shopmall DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; # 导入表结构和基础数据 mysql -uroot -p shopmall shop.sql这里有几个参数必须确认字符集别用默认的 utf8因为商品名、收货人姓名里一旦有 emojiutf8 会报错或者存成问号utf8mb4才能完整存下四个字节的字符。COLLATE用utf8mb4_general_ci就够了排序规则对商城业务影响不大。如果导入时报 1273 错误说明 SQL 脚本里指定了更高版本的字符集排序你当前的 MySQL 不支持可以把脚本里的COLLATE utf8mb4_0900_ai_ci全局替换成utf8mb4_general_ci再导入。导入完成后用SHOW TABLES;至少能看到 user、product、sku、order 这几张核心表如果连 order 表都没有那这份源码连半成品都算不上建议换一套。3.2 修改application.yml端口、数据源、Redis三个必调项数据库就位后就要让后台代码连上去。打开源码里的application.yml也有可能是application.properties前 30 行就会被三个配置块堵住server、datasource、redis。常见做法是把这三项一次性改完再启动不然你会反复看到连接超时和 Redis 连接拒绝的报错。下面是典型配置和必改项server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/shopmall?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379 password: database: 0 # 自定义微信配置源码里一般叫 wx 或 wechat wx: appid: 你的小程序appid secret: 你的小程序secret先看 datasource 的 url。serverTimezoneAsia/Shanghai必须加否则控制台时间字段会差 8 小时characterEncodingutf8要和数据库里建库时的utf8mb4区分——这里的 utf8 是 JDBC 编码参数一般写成 utf8 没问题但如果你遇到乱码改成characterEncodingutf8mb4反而会让某些版本的驱动报错推荐保持utf8依靠库表级别的utf8mb4来兜底。useSSLfalse也是必须的本地 MySQL 没配证书true 会启动告警甚至连不上。再看端口号8080是 Spring Boot 默认但如果你的电脑上有别的 Java 程序占了这个端口可以改成 8081对应后面小程序端 baseUrl 里的端口也要同步改。Redis 配置里password留空表示本地 Redis 没设密码。如果你本地 Redis 设过密码这里填错的话后台启动会直接报Unable to connect to Redis; no password而且控制台会不断重连刷日志。这时候先去 Redis 配置文件里把requirepass注释掉或者把正确的密码填进来。wx.appid 和 wx.secret 现在可以不急着换本地先用源码自带的测试值跑通登录但要心里有数不换的话微信登录接口拿不到真实 openid后面小程序登录一定失败。把这三块改完后在项目根目录执行mvn spring-boot:run # 或者先打包再启动二选一 mvn clean package -DskipTests java -jar target/shop-admin.jar看到控制台出现Started Application in xx seconds并且没有初始化异常就说明后台已经起来了。此时你可以用浏览器或 curl 试一下http://localhost:8080/api/health或随便一个公开接口能返回 JSON 就继续做小程序端联动。3.3 微信开发者工具里改request地址让小程序找到后台后台接口活着小程序却不一定能打通问题基本出在小程序端配置的 baseUrl 上。打开小程序前端源码原生小程序一般直接是miniapp/目录如果你拿到的是 uniapp 工程目录结构会多一层src找到config.js或utils/request.js里面有一段类似这样的配置// 小程序全局请求地址本地开发时写电脑的局域网IP module.exports { baseUrl: http://192.168.31.115:8080, timeout: 10000 }这里重点说一句不要在小程序里写http://localhost:8080。开发者工具里localhost 指向的是你的开发电脑看起来能通但一旦换成真机预览手机上的 localhost 指向手机自己请求必挂。真机调试的常见做法是让手机和电脑连同一个 Wi-Fi把 baseUrl 改成电脑的局域网 IP。怎么查 IP命令行里ipconfigWindows或ifconfigmacOS/Linux都能看到。改完之后在微信开发者工具右上角点“详情-本地设置”勾选“不校验合法域名、web-view业务域名、TLS 版本以及 HTTPS 证书”这个开发选项因为后台本地是 http 协议域名校验会拦下所有请求。还有一个和页面显示强相关的坑微信小程序顶部导航栏高度。很多源码把页面标题写死在app.json里你改了后发现 iPhone 刘海屏和安卓状态栏高度不一样导航栏把页面顶上去一块。源码里如果有自定义导航栏组件记得去读它的getSystemInfoSync()相关代码确认是否用了statusBarHeight做偏移。如果源码连这个都没处理那大概率是套很早期的模板要么接受它的样式要么自己补一个navigationStyle: custom的页面重写头部。这几个配置都搞定后你在开发者工具里登录、点进商品列表能看到真实数据从后台返回这套源码就真正算跑通了。4. 完整后台怎么扩展商品SKU、订单状态机、会员积分的改法4.1 商品模块规格与SKU是一对多的树别用逗号拼接很多后台的“商品管理”页面只给你填一个“商品名称”和一个“商品价格”这对卖标品还行卖服饰水果就废了。完整的商城后台必须要支持多规格颜色、尺寸、套餐任意组合生成一个独立 SKU有自己的价格、库存、编码。这套源码如果连规格功能都没有扩展点就要从这里补起。我在第 2 章给过 sku 表的结构这里说具体实现时最容易错的点——后台管理端编辑商品时规格怎么保存。常见做法是前端把规格选项收集成一个数组后端基于这些选项做笛卡尔积生成 SKU。比如颜色有“黑、白”尺码有“L、XL”笛卡尔积就是“黑L、黑XL、白L、白XL”四条记录。后端代码大致是这个套路// 生成 SKU 组合的后端方法省略了异常和事务 public ListSkuVO generateSkus(Long productId, ListSpecOption specs) { // specs 例如 [{name:颜色, values:[黑,白]}, {name:尺码, values:[L,XL]}] ListListString matrix new ArrayList(); ListMapString, String skuSpecsList cartesianProduct(specs); // 递归排列组合 ListSkuVO result new ArrayList(); for (MapString, String skuSpecs : skuSpecsList) { Sku sku new Sku(); sku.setProductId(productId); sku.setSpecsJson(JSON.toJSONString(skuSpecs)); // 价格和库存由运营在弹窗里逐个填写也可以按默认值初始化 sku.setPrice(0.00); sku.setStock(0); skuMapper.insert(sku); result.add(convertToVO(sku)); } return result; }这里有两个关键参数specsJson一定要按固定 key 的 Map 存储不要直接存前端传来的数组否则前后端字段顺序一变同一条 SKU 的规格匹配就乱套。另外后台一般还要支持“保存时全删再插入”的简化逻辑编辑商品规格后把旧 sku 记录逻辑删除再按新组合重新生成虽然粗暴但对中小型商城来说不容易留下脏数据。别用逗号拼接的原因再强调一遍规格值里只要出现一个中文逗号你所谓的 “黑,L” 和 “黑L” 就会变成两个 SKU库存和价格完全对不上。至于商品主图还是直接用默认图片可以给每个 SKU 单独设置一个skuImage字段但大多数源码只在 product 层管图先不做复杂化能跑通列表加载更多就够第二步再优化。4.2 订单模块状态机与支付回调处理订单模块是整个商城的命门也是后台管理里最容易改出 bug 的地方。“完整后台”如果订单管理只有一张表格和一个删除按钮那交付出去客户肯定会崩。最核心的是把订单状态机理清楚。一个最基础的订单状态流是这样下单时创建订单状态为 0待支付用户支付成功后回调通知状态变为 1待发货商家后台点击发货状态变为 2待收货用户确认收货状态变为 3已完成如果超过支付时限或用户主动取消状态变为 4已取消。此外还有退款中的状态但先看主流程。在 Java 代码里我建议把状态定义成枚举而不是魔法数字至少让别人读代码时不用猜public enum OrderStatus { UNPAID(0, 待支付), PAID(1, 待发货), SHIPPED(2, 待收货), COMPLETED(3, 已完成), CANCELLED(4, 已取消); private final int code; private final String desc; // 构造函数和 getter 省略 }状态流转不要写在小程序端更不能让小程序端直接猜后台状态。后台一定要做两件事一是每个状态变更接口都要校验前置状态比如已取消的订单不能发货二是支付回调这种被动通知必须做幂等。微信支付回调会发多次第一次回调处理成功后第二次回调再进来如果代码没判断状态就直接改单会导致发货时间被覆盖甚至重复发放积分。处理回调的伪代码大致是Transactional(rollbackFor Exception.class) public void handlePaidNotify(String orderNo, String transactionId) { Order order orderMapper.selectByOrderNoForUpdate(orderNo); // 行锁 if (order null || order.getStatus() ! OrderStatus.UNPAID.getCode()) { // 关键状态不是待支付直接返回成功让微信停止回调 return; } order.setStatus(OrderStatus.PAID.getCode()); order.setPayTransactionId(transactionId); order.setPayTime(new Date()); orderMapper.updateById(order); }这里的selectByOrderNoForUpdate是专门用来控制并发的行锁会锁住这一条订单避免两个线程同时读到 UNPAID 状态导致重复处理这就是 java 怎么保证数据一致性的最直接例子。很多人以为只要加了Transactional就安全实际上事务不解决并发读同一行的覆盖问题必须配合锁或乐观锁字段。支付回调里还有一个同样明显的坑回调路径必须公网可访问本地环境测不了。建议先在后台日志里把回调查询打出来看到异常就能快速定位而不是直接去改支付接口。4.3 会员模块积分流水与等级阈值商城后台的会员功能基础要求是会员列表、会员等级、积分余额。如果源码只有一个user表加一个points字段那积分变动就没有追溯用户一投诉送积分不存在的纠纷你什么证据都拿不出来。正确做法是单独建一张积分流水表任何一次积分变动都记录一条流水余额用累计求和或者单独字段缓存但流水是硬账。表结构可以参考CREATE TABLE member_point_log ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, user_id INT UNSIGNED NOT NULL, change_amount INT NOT NULL COMMENT 正数增加负数扣减, balance_after INT NOT NULL COMMENT 本次变动后的积分余额, type TINYINT NOT NULL COMMENT 1下单赠送 2退款扣回 3签到 4后台调整, order_id INT UNSIGNED DEFAULT NULL, remark VARCHAR(255) DEFAULT NULL, create_time DATETIME NOT NULL, INDEX idx_user_id (user_id), INDEX idx_order_id (order_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT积分流水表;关键参数是balance_after一定不能省。有的源码只记录 change_amount用户查到积分总数对不上时要拿着流水一行行加减运维成本极高。有了 balance_after每一行都是当时账本快照对账直接查最后一条流水就能对齐。会员等级则建议用一张 threshold 表存“累计积分达到多少就是几级会员享受几折优惠”后台运营能自己调不用发版本。如果源码把等级写死在 switch 里改成读取配置表即可成本很低。等级打折要在下单时计算这里注意别在订单表里存“折扣率”而要把“实际成交价”写进 order_item。因为你后台等级调整后历史订单的折扣率可能变但已成交订单的金额不能变。积分赠送最好也做成异步或者放在支付回调之后别在下单校验库存时就送否则用户取消订单积分还没扣回账目就乱了。基于微信小程序的社区团购系统这类旁支需求其实就是在订单里加一个“团长 id”和“自提点 id”核心表不动也可以加字段硬扩但积分账模型不能乱。5. 避坑与排查本地能跑不代表线上稳五个常见翻车点5.1 小程序请求404request合法域名和端口匹配不上现象开发者工具里点登录、点商品列表网络面板一堆 404后台控制台没有任何请求日志进入。原因要么是小程序端 baseUrl 还是localhost要么端口和后台实际端口不一致要么上线后 request 域名没加到微信公众平台的“request 合法域名”白名单里。微信开发者工具里勾了“不校验合法域名”只是开发期的豁免真机预览时该拦还是拦。解决先在开发者工具的 Network 面板看请求 URL 到底是什么。如果是https://localhost:8080改成电脑的局域网 IP如果后台端口是 8081baseUrl 也要跟着改。上线前把你购买或备案的域名加到mp.weixin.qq.com后台的“开发-开发管理-服务器域名”里而且接口必须走 HTTPS不能带端口除非 443。这套源码支持多个接入环境的话还要检查小程序端是否按wx.getSystemInfoSync().platform区分了开发版和正式版请求地址没有就自己加一份环境判断。5.2 微信支付回调验签失败notify_url要外网可访问现象用户微信支付成功钱已经扣了但后台订单状态一直不变后台日志里出现“验签失败”或“回调处理异常”。原因支付回调notify_url配置成了内网地址或者写的是localhost。微信服务器从公网发起回调连不上你的内网机器就会一直重试重试几次失败后就不再通知订单卡在待支付。解决开发阶段可以使用支持公网访问的临时调试域名这个就不展开工具了生产环境一定要把notify_url配成公网 HTTPS 域名。然后在商户平台检查 API 证书序列号和 APIv3 密钥是否都填对了源码里如果用的是旧版本 SDK还要注意回调地址路径是否和 Controller 里的 mapping 完全一致少一个斜杠都验签失败。最后在回调接口里第一行就打印收到的报文和签名用真实报文对一遍能省下半天猜测时间。5.3 MySQL时间差了8小时时区参数没配现象后台管理订单列表里创建时间是上午 10 点实际用户是下午 6 点下单小程序端商品上架时间显示也不对。原因JDBC 连接串没加serverTimezoneAsia/ShanghaiMySQL 默认时区是 UTC而服务器时间又是东八区两边一减正好 8 小时。解决在application.yml的 datasource url 末尾加上serverTimezoneAsia/Shanghai同时重启确认。如果还不对进 MySQL 执行show variables like %time_zone%;看 global time_zone 是不是SYSTEM系统时区如果不是东八区就改成SET GLOBAL time_zone 08:00;。注意改完数据库后连接池要重连改配置后重启 Java 进程是最稳定的。还有一个冷门情况如果用了LocalDateTimeJDBC 驱动版本低也可能导致时区转换出问题把 MySQL 驱动升到 8.x 基本能解决。5.4 图片上传后回显裂图静态资源映射被拦截现象后台管理上传商品图片提示成功但前端小程序的图片地址直接裂开浏览器单独打开图片 URL 返回 404。原因后台把图片保存到本地磁盘的/upload/目录但没有告诉 Spring Boot 如何映射这个目录到 URL。Spring Boot 默认只映射classpath:/static/你写http://localhost:8080/upload/xxx.jpg自然是 404。如果上线后有 Nginx也可能是 Nginx 没有把/upload/转发到后台服务。解决在 Java 端补一个资源映射。注意路径最后面的斜杠Linux 下/home/shop/upload/少了结尾斜杠会映射失败。代码块我放在避坑章节里Configuration public class WebMvcConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file:/home/shop/upload/); } }配置完成后重启后台访问一次图片 URL 确认能打开。如果放在 Nginx 后面还应在 location 里加一条location /upload/ { proxy_pass http://127.0.0.1:8080; }不然请求到不了 Java 进程。再有就是本地 Windows 环境file:D:/shop/upload/的写法里盘符后的冒号和反斜杠也很容易写错看到一个 D 盘路径映射一直 404基本是路径格式问题。5.5 后台启动报端口占用别急着杀进程先看是哪个服务现象java -jar启动后台控制台抛出Web server failed to start. Port 8080 was already in use.进程直接退出。这是 java 启动失败怎么解决里最频繁的报错。原因之前一次启动没有彻底关闭或者电脑上另一个程序占用了 8080。有些源码还会默认用 8080 再带一个 Redis listener两个端口都是一个道理。解决先看端口到底被谁占用。Linux 用netstat -anp | grep 8080Windows 用netstat -ano | findstr 8080拿到 PID 后Windows 用taskkill /PID pid /FLinux 用kill -9 pid。如果是你自己之前跑的后台这条命令很安全但如果 PID 对应的是别的业务服务就换个端口更省事。在application.yml里把server.port改成 8081然后小程序端 baseUrl 同步改端口完美绕开。顺带一提别为了找端口占用直接重启机器那才是运维上的翻车。6. 别把源码当黑匣子两个能放进简历的进阶改造点这套源码跑通、能下单、后台能发货之后你和它之间就过了蜜月期。接下来最值得做的事不是继续堆功能而是验证它到底能在多大数据量、多高并发下站住同时把后台审计能力补上。我做的第一件事是加上操作日志——管理员改了商品价格、手动取消订单、调整用户积分这些都是高危动作没有日志等于穿着溜冰鞋走钢丝。要做得干净可以用注解 Spring AOP 统一埋点Target({ElementType.METHOD}) Retention(RetentionPolicy.RUNTIME) public interface OpLog { String module(); // 例如 商品 订单 String action(); // 例如 改价 发货 }在需要记录的 Controller 或 Service 方法上标一下然后用 AOP 拦截写日志包含操作人、IP、请求参数、耗时落库或打到日志文件都行。这个小功能在简历上可以写“基于 AOP 实现后台操作审计和用户行为追踪”面试官看到这种描述比看到“会用 CRUD”值钱得多。第二个值得做的是接口压测用 JMeter 对商品列表接口和一个下单接口分别跑 50 并发看看吞吐量和错误率。如果你发现线程调优后内存占用暴增就回头检查是不是某些查询没有分页、有没有索引缺失而不是对着源码抱怨。老实说我早期拿到源码就急着改页面没有先做压测和日志后来上线被瞬时流量打挂花了整晚才定位到一条没有索引的订单查询。先跑通、再补日志、最后压测这三步是这套源码最稳的升级路径。希望帮到你。本文还有配套的精品资源点击获取 Java微信小程序商城源码+完整后台：Spring Boot电商项目实战与避坑指南
简介JAVA微信小程序商城源码及完整后台是一套面向Java开发者的电商小程序前后端解决方案基于SpringMVC、MyBatis、Spring、Maven和MySQL构建前端采用H5与CSS3后台管理界面基于Bootstrap-ACE框架。资源覆盖商品发布、物流管理、评价系统、优惠券、运费规则、在线客服、微信支付、在线退款及微信管理等核心电商业务模块流程完整可直接运行部署也可作为二次开发或课程设计、毕业设计的参考起点。源码按照前端页面、后端业务与后台管理进行分层组织目录结构清晰便于按需定位和修改代码。压缩包采用7z格式大小约20.5MB体量适中适合个人开发者快速下载学习。目前已有5047人浏览学习适合具备一定Java Web基础、希望快速上手微信小程序商城开发的学习者。1. 从一套「JAVA微信小程序商城源码完整后台」说起这套东西到底能给你什么这套 JAVA微信小程序商城源码完整后台在电商外包和私活市场里一直是最热的关键词背后是个真实需求用最低成本做完“小程序端选品下单 后台管商品订单”的完整闭环。常见做法是后端用 Spring Boot 搭好的接口前端是微信原生小程序再加上一份 MySQL 建表脚本和一个能录入商品、处理订单的 Web 后台。你拿着它能省下从零搭建的时间但也别指望直接双击就能上线——我见过太多人卡在数据库导入、微信登录配置和图片上传这三件事上。适合谁呢一是想快速上线自营微信小店的团队二是刚把 Java 基础学完、想拿完整项目练手的同学三是接外包需要一套可交付底盘的工程师。2. 先看后台骨架再下手Spring Boot MyBatis的商城系统是怎么组织的2.1 为什么主流源码都压Spring Boot MyBatis而不是SSH/SSM现在的 JAVA 微信小程序商城源码后台十有八九是 Spring Boot MyBatis。很多人刚学 Java 时还在背 SSHSpring MVC Spring Hibernate的配置项到了开源商城源码里你会发现那套已经属于考古范围。Spring Boot 用 starter 和自动配置把粘合逻辑收走内嵌 Tomcat 让部署变成一条java -jar命令MyBatis 又保留了 SQL 的手写自由电商后台那些多表 join、分组统计、动态条件查询用 Hibernate 的 HQL 写起来反而不直观。要是去翻 java 面试题Spring Boot MyBatis 的出现频率也远高于 SSH团队招人不用重新培训。从再造一个后台的成本看这套组合有四个实际好处第一微信支付、阿里云 OSS 这些常用 SDK 都有对应的 spring-boot-starter能省掉大量样板代码第二MyBatis 的热门框架 PageHelper 做分页方便详情页、列表页的查询条件再复杂也能用动态 SQL 扛住第三Spring Boot 的 actuator 能直接暴露健康检查接口部署在服务器上方便监控进程是死是活第四市面上你能搜到的大多数 Spring Boot mybatis 的 java 开源多商户跨境商城源码下载都是同一套骨架二次开发的资料好找。这套源码也不例外我一般会先花十分钟把包结构扫描一遍确认它是不是标准的 controller-service-mapper 三层再决定从哪开始改。为了让你判断手里源码的底子这里有一个简单的选型对比如果你是第一次接触这类项目直接用 Spring Boot 2.x MyBatis 的骨架就够了。有些老源码还标着 SSM 甚至更古老的 Spring Struts看到 Struts 可以直接放弃因为微信支付对接、文件上传那些依赖在老旧框架里处理起来全是坑不值得为省一点迁移时间搭上排错精力。2.2 小程序端和后台的鉴权链路wx.login到底换了什么小程序和传统 Web 登录最大的区别是没有 cookie也没有 session 容器所有请求都靠一个自定义 token 来认人。所以源码里有一整套隐藏链路理解它你后面改任何需要登录的接口才不会懵。链路是这样的小程序调用wx.login()拿到一个一次性 code然后用wx.request把这个 code 发给后台的登录接口后台拿到 code 后拿 appid、secret、code 去调微信的jscode2session接口换回 openid 和 session_key接着后台用 openid 查用户表查不到就自动注册一条新用户最后生成一个随机的 token 存进 Redis设置 7 天过期返回给小程序。从此刻起小程序每个请求都把这个 token 放在 header 里后台通过拦截器校验。在一套完整后台里这段代码一般长这样// AuthService.java 里最核心的三个动作 public String wxLogin(String code) { // 1. 用 code 换 openid这一步叫 jscode2session MapString, String params new HashMap(); params.put(appid, wxProperties.getAppid()); params.put(secret, wxProperties.getSecret()); params.put(js_code, code); params.put(grant_type, authorization_code); String result restTemplate.getForObject( https://api.weixin.qq.com/sns/jscode2session?appid{appid}secret{secret}js_code{js_code}grant_type{grant_type}, String.class, params); // 2. 解析 openid查表或建新用户 JSONObject json JSON.parseObject(result); String openid json.getString(openid); if (openid null) { throw new BusinessException(微信登录失败: json.getString(errmsg)); } User user userMapper.findByOpenid(openid); if (user null) { user new User(); user.setOpenid(openid); user.setAvatar(default.jpg); userMapper.insert(user); } // 3. 生成 token 放 Rediskey 里带前缀方便诊断 String token UUID.randomUUID().toString().replaceAll(-, ); redisTemplate.opsForValue().set(wxmall:token: token, user.getId(), 7, TimeUnit.DAYS); return token; }这段代码里最容易出问题的是第一步。微信接口返回的 openid 只在 code 有效期内有效code 一次性的用第二次就会报 10002还有像appid和secret这两个参数不要写死在小程序前端因为 secret 一旦暴露别人就能冒充你的用户登录。正确的做法是让小程序只传 code所有换 openid 的逻辑都留在后台。第二步的findByOpenid必须走索引openid 字段长度一般是 28 位左右建表时要给唯一索引否则流量上来后按 openid 查用户的 SQL 全表扫描接口撑不住。第三步把 token 存 Redis 而不是放 JWT 里是为了之后想在后台踢人下线时直接删掉这条 key 就能生效如果你拿到的源码用的是 JWT那就要额外维护黑名单这是另一个话题。检查你手上的小程序端代码如果看到它把 appid 和 secret 直接写在某个 js 文件里那说明这份源码的安全意识不太行。正常源码应该在小程序端只配置 appidsecret 永远只出现在后台的配置文件中。改法也简单把小程序端写死 secret 的代码删掉改成只传 code 给后台后台自己拼参数调微信接口即可。2.3 数据库设计商品、订单、用户三张主表的字段边界源码的完整后台一般会给你一张数据库设计文档没有文档的话就自己看 SQL 建表脚本。商城业务再复杂核心逃不开用户、商品、订单这三大块。我习惯把表分成三类用户相关user、user_address、member_point_log、商品相关product、sku、product_category、brand、订单相关cart、order、order_item、payment_log。如果这套源码还要做营销还会有 coupon、seckill 这类表但先不管那些基础核心是先分清楚这几张主表之间的关联。看一套开源商城源码值不值重点看它的 sku 表设计。土办法是把 product 和 sku 混在一张表里用一行记录一个颜色、一个尺码的库存价格做得好的是 product 表只放商品基础信息具体到“红色、XL、价格 199、库存 50”这种粒度全放 sku 表。后者在面对多规格商品时改价格、补库存、锁定库存都方便而且以后对接仓储系统每个 sku 就是最小的库存单位。给你一个简化结构参考-- 商品主表 CREATE TABLE product ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, title VARCHAR(200) NOT NULL COMMENT 商品标题, category_id INT UNSIGNED NOT NULL, default_image VARCHAR(500) NOT NULL, detail_html MEDIUMTEXT COMMENT 富文本详情, sales INT UNSIGNED DEFAULT 0, status TINYINT DEFAULT 1 COMMENT 1上架 0下架, create_time DATETIME NOT NULL ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品主表; -- SKU 表 CREATE TABLE sku ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, product_id INT UNSIGNED NOT NULL, specs_json JSON NOT NULL COMMENT 规格组合如 [{颜色:红},{尺码:L}], price DECIMAL(10,2) NOT NULL, stock INT UNSIGNED NOT NULL, sku_code VARCHAR(64) DEFAULT NULL COMMENT 用于对接物流/ERP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT最小库存单位表;这里有一个关键参数specs_json用 JSON 类型而不是拼接字符串。很多老源码是 “红,L” 这种逗号拼接一旦规格值里出现中文逗号或用户乱填匹配就崩。MySQL 5.7 以上原生支持 JSON查起来能用JSON_CONTAINS不过商城场景里更推荐把 specs_json 取出来在 Java 层做精确匹配性能不会差代码还好读。库存字段用INT UNSIGNED注意做好乐观锁扣库存时 SQL 带上WHERE stock #{count}避免超卖。order 表同理下单时要冗余商品标题、规格快照和成交单价防止商品之后改价或删除订单历史仍然能还原当时的交易现场。3. 本地跑通这套源码数据库初始化、配置档位、开发者工具联调三连3.1 导入MySQL数据库字符集和时区是第一步拿到源码压缩包先别急着解压运行第一步是建库导表。源码包里的 SQL 文件一般是shop.sql或者db/shop.sql而且常常只包含表结构和一部分测试数据没有建库语句。你需要在 MySQL 里手动建库再导入。我习惯在命令行里操作比 Navicat 导入大 SQL 更不容易卡死。# 创建一个专门给商城的库字符集直接定成 utf8mb4 mysql -uroot -p -e CREATE DATABASE shopmall DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; # 导入表结构和基础数据 mysql -uroot -p shopmall shop.sql这里有几个参数必须确认字符集别用默认的 utf8因为商品名、收货人姓名里一旦有 emojiutf8 会报错或者存成问号utf8mb4才能完整存下四个字节的字符。COLLATE用utf8mb4_general_ci就够了排序规则对商城业务影响不大。如果导入时报 1273 错误说明 SQL 脚本里指定了更高版本的字符集排序你当前的 MySQL 不支持可以把脚本里的COLLATE utf8mb4_0900_ai_ci全局替换成utf8mb4_general_ci再导入。导入完成后用SHOW TABLES;至少能看到 user、product、sku、order 这几张核心表如果连 order 表都没有那这份源码连半成品都算不上建议换一套。3.2 修改application.yml端口、数据源、Redis三个必调项数据库就位后就要让后台代码连上去。打开源码里的application.yml也有可能是application.properties前 30 行就会被三个配置块堵住server、datasource、redis。常见做法是把这三项一次性改完再启动不然你会反复看到连接超时和 Redis 连接拒绝的报错。下面是典型配置和必改项server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/shopmall?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379 password: database: 0 # 自定义微信配置源码里一般叫 wx 或 wechat wx: appid: 你的小程序appid secret: 你的小程序secret先看 datasource 的 url。serverTimezoneAsia/Shanghai必须加否则控制台时间字段会差 8 小时characterEncodingutf8要和数据库里建库时的utf8mb4区分——这里的 utf8 是 JDBC 编码参数一般写成 utf8 没问题但如果你遇到乱码改成characterEncodingutf8mb4反而会让某些版本的驱动报错推荐保持utf8依靠库表级别的utf8mb4来兜底。useSSLfalse也是必须的本地 MySQL 没配证书true 会启动告警甚至连不上。再看端口号8080是 Spring Boot 默认但如果你的电脑上有别的 Java 程序占了这个端口可以改成 8081对应后面小程序端 baseUrl 里的端口也要同步改。Redis 配置里password留空表示本地 Redis 没设密码。如果你本地 Redis 设过密码这里填错的话后台启动会直接报Unable to connect to Redis; no password而且控制台会不断重连刷日志。这时候先去 Redis 配置文件里把requirepass注释掉或者把正确的密码填进来。wx.appid 和 wx.secret 现在可以不急着换本地先用源码自带的测试值跑通登录但要心里有数不换的话微信登录接口拿不到真实 openid后面小程序登录一定失败。把这三块改完后在项目根目录执行mvn spring-boot:run # 或者先打包再启动二选一 mvn clean package -DskipTests java -jar target/shop-admin.jar看到控制台出现Started Application in xx seconds并且没有初始化异常就说明后台已经起来了。此时你可以用浏览器或 curl 试一下http://localhost:8080/api/health或随便一个公开接口能返回 JSON 就继续做小程序端联动。3.3 微信开发者工具里改request地址让小程序找到后台后台接口活着小程序却不一定能打通问题基本出在小程序端配置的 baseUrl 上。打开小程序前端源码原生小程序一般直接是miniapp/目录如果你拿到的是 uniapp 工程目录结构会多一层src找到config.js或utils/request.js里面有一段类似这样的配置// 小程序全局请求地址本地开发时写电脑的局域网IP module.exports { baseUrl: http://192.168.31.115:8080, timeout: 10000 }这里重点说一句不要在小程序里写http://localhost:8080。开发者工具里localhost 指向的是你的开发电脑看起来能通但一旦换成真机预览手机上的 localhost 指向手机自己请求必挂。真机调试的常见做法是让手机和电脑连同一个 Wi-Fi把 baseUrl 改成电脑的局域网 IP。怎么查 IP命令行里ipconfigWindows或ifconfigmacOS/Linux都能看到。改完之后在微信开发者工具右上角点“详情-本地设置”勾选“不校验合法域名、web-view业务域名、TLS 版本以及 HTTPS 证书”这个开发选项因为后台本地是 http 协议域名校验会拦下所有请求。还有一个和页面显示强相关的坑微信小程序顶部导航栏高度。很多源码把页面标题写死在app.json里你改了后发现 iPhone 刘海屏和安卓状态栏高度不一样导航栏把页面顶上去一块。源码里如果有自定义导航栏组件记得去读它的getSystemInfoSync()相关代码确认是否用了statusBarHeight做偏移。如果源码连这个都没处理那大概率是套很早期的模板要么接受它的样式要么自己补一个navigationStyle: custom的页面重写头部。这几个配置都搞定后你在开发者工具里登录、点进商品列表能看到真实数据从后台返回这套源码就真正算跑通了。4. 完整后台怎么扩展商品SKU、订单状态机、会员积分的改法4.1 商品模块规格与SKU是一对多的树别用逗号拼接很多后台的“商品管理”页面只给你填一个“商品名称”和一个“商品价格”这对卖标品还行卖服饰水果就废了。完整的商城后台必须要支持多规格颜色、尺寸、套餐任意组合生成一个独立 SKU有自己的价格、库存、编码。这套源码如果连规格功能都没有扩展点就要从这里补起。我在第 2 章给过 sku 表的结构这里说具体实现时最容易错的点——后台管理端编辑商品时规格怎么保存。常见做法是前端把规格选项收集成一个数组后端基于这些选项做笛卡尔积生成 SKU。比如颜色有“黑、白”尺码有“L、XL”笛卡尔积就是“黑L、黑XL、白L、白XL”四条记录。后端代码大致是这个套路// 生成 SKU 组合的后端方法省略了异常和事务 public ListSkuVO generateSkus(Long productId, ListSpecOption specs) { // specs 例如 [{name:颜色, values:[黑,白]}, {name:尺码, values:[L,XL]}] ListListString matrix new ArrayList(); ListMapString, String skuSpecsList cartesianProduct(specs); // 递归排列组合 ListSkuVO result new ArrayList(); for (MapString, String skuSpecs : skuSpecsList) { Sku sku new Sku(); sku.setProductId(productId); sku.setSpecsJson(JSON.toJSONString(skuSpecs)); // 价格和库存由运营在弹窗里逐个填写也可以按默认值初始化 sku.setPrice(0.00); sku.setStock(0); skuMapper.insert(sku); result.add(convertToVO(sku)); } return result; }这里有两个关键参数specsJson一定要按固定 key 的 Map 存储不要直接存前端传来的数组否则前后端字段顺序一变同一条 SKU 的规格匹配就乱套。另外后台一般还要支持“保存时全删再插入”的简化逻辑编辑商品规格后把旧 sku 记录逻辑删除再按新组合重新生成虽然粗暴但对中小型商城来说不容易留下脏数据。别用逗号拼接的原因再强调一遍规格值里只要出现一个中文逗号你所谓的 “黑,L” 和 “黑L” 就会变成两个 SKU库存和价格完全对不上。至于商品主图还是直接用默认图片可以给每个 SKU 单独设置一个skuImage字段但大多数源码只在 product 层管图先不做复杂化能跑通列表加载更多就够第二步再优化。4.2 订单模块状态机与支付回调处理订单模块是整个商城的命门也是后台管理里最容易改出 bug 的地方。“完整后台”如果订单管理只有一张表格和一个删除按钮那交付出去客户肯定会崩。最核心的是把订单状态机理清楚。一个最基础的订单状态流是这样下单时创建订单状态为 0待支付用户支付成功后回调通知状态变为 1待发货商家后台点击发货状态变为 2待收货用户确认收货状态变为 3已完成如果超过支付时限或用户主动取消状态变为 4已取消。此外还有退款中的状态但先看主流程。在 Java 代码里我建议把状态定义成枚举而不是魔法数字至少让别人读代码时不用猜public enum OrderStatus { UNPAID(0, 待支付), PAID(1, 待发货), SHIPPED(2, 待收货), COMPLETED(3, 已完成), CANCELLED(4, 已取消); private final int code; private final String desc; // 构造函数和 getter 省略 }状态流转不要写在小程序端更不能让小程序端直接猜后台状态。后台一定要做两件事一是每个状态变更接口都要校验前置状态比如已取消的订单不能发货二是支付回调这种被动通知必须做幂等。微信支付回调会发多次第一次回调处理成功后第二次回调再进来如果代码没判断状态就直接改单会导致发货时间被覆盖甚至重复发放积分。处理回调的伪代码大致是Transactional(rollbackFor Exception.class) public void handlePaidNotify(String orderNo, String transactionId) { Order order orderMapper.selectByOrderNoForUpdate(orderNo); // 行锁 if (order null || order.getStatus() ! OrderStatus.UNPAID.getCode()) { // 关键状态不是待支付直接返回成功让微信停止回调 return; } order.setStatus(OrderStatus.PAID.getCode()); order.setPayTransactionId(transactionId); order.setPayTime(new Date()); orderMapper.updateById(order); }这里的selectByOrderNoForUpdate是专门用来控制并发的行锁会锁住这一条订单避免两个线程同时读到 UNPAID 状态导致重复处理这就是 java 怎么保证数据一致性的最直接例子。很多人以为只要加了Transactional就安全实际上事务不解决并发读同一行的覆盖问题必须配合锁或乐观锁字段。支付回调里还有一个同样明显的坑回调路径必须公网可访问本地环境测不了。建议先在后台日志里把回调查询打出来看到异常就能快速定位而不是直接去改支付接口。4.3 会员模块积分流水与等级阈值商城后台的会员功能基础要求是会员列表、会员等级、积分余额。如果源码只有一个user表加一个points字段那积分变动就没有追溯用户一投诉送积分不存在的纠纷你什么证据都拿不出来。正确做法是单独建一张积分流水表任何一次积分变动都记录一条流水余额用累计求和或者单独字段缓存但流水是硬账。表结构可以参考CREATE TABLE member_point_log ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, user_id INT UNSIGNED NOT NULL, change_amount INT NOT NULL COMMENT 正数增加负数扣减, balance_after INT NOT NULL COMMENT 本次变动后的积分余额, type TINYINT NOT NULL COMMENT 1下单赠送 2退款扣回 3签到 4后台调整, order_id INT UNSIGNED DEFAULT NULL, remark VARCHAR(255) DEFAULT NULL, create_time DATETIME NOT NULL, INDEX idx_user_id (user_id), INDEX idx_order_id (order_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT积分流水表;关键参数是balance_after一定不能省。有的源码只记录 change_amount用户查到积分总数对不上时要拿着流水一行行加减运维成本极高。有了 balance_after每一行都是当时账本快照对账直接查最后一条流水就能对齐。会员等级则建议用一张 threshold 表存“累计积分达到多少就是几级会员享受几折优惠”后台运营能自己调不用发版本。如果源码把等级写死在 switch 里改成读取配置表即可成本很低。等级打折要在下单时计算这里注意别在订单表里存“折扣率”而要把“实际成交价”写进 order_item。因为你后台等级调整后历史订单的折扣率可能变但已成交订单的金额不能变。积分赠送最好也做成异步或者放在支付回调之后别在下单校验库存时就送否则用户取消订单积分还没扣回账目就乱了。基于微信小程序的社区团购系统这类旁支需求其实就是在订单里加一个“团长 id”和“自提点 id”核心表不动也可以加字段硬扩但积分账模型不能乱。5. 避坑与排查本地能跑不代表线上稳五个常见翻车点5.1 小程序请求404request合法域名和端口匹配不上现象开发者工具里点登录、点商品列表网络面板一堆 404后台控制台没有任何请求日志进入。原因要么是小程序端 baseUrl 还是localhost要么端口和后台实际端口不一致要么上线后 request 域名没加到微信公众平台的“request 合法域名”白名单里。微信开发者工具里勾了“不校验合法域名”只是开发期的豁免真机预览时该拦还是拦。解决先在开发者工具的 Network 面板看请求 URL 到底是什么。如果是https://localhost:8080改成电脑的局域网 IP如果后台端口是 8081baseUrl 也要跟着改。上线前把你购买或备案的域名加到mp.weixin.qq.com后台的“开发-开发管理-服务器域名”里而且接口必须走 HTTPS不能带端口除非 443。这套源码支持多个接入环境的话还要检查小程序端是否按wx.getSystemInfoSync().platform区分了开发版和正式版请求地址没有就自己加一份环境判断。5.2 微信支付回调验签失败notify_url要外网可访问现象用户微信支付成功钱已经扣了但后台订单状态一直不变后台日志里出现“验签失败”或“回调处理异常”。原因支付回调notify_url配置成了内网地址或者写的是localhost。微信服务器从公网发起回调连不上你的内网机器就会一直重试重试几次失败后就不再通知订单卡在待支付。解决开发阶段可以使用支持公网访问的临时调试域名这个就不展开工具了生产环境一定要把notify_url配成公网 HTTPS 域名。然后在商户平台检查 API 证书序列号和 APIv3 密钥是否都填对了源码里如果用的是旧版本 SDK还要注意回调地址路径是否和 Controller 里的 mapping 完全一致少一个斜杠都验签失败。最后在回调接口里第一行就打印收到的报文和签名用真实报文对一遍能省下半天猜测时间。5.3 MySQL时间差了8小时时区参数没配现象后台管理订单列表里创建时间是上午 10 点实际用户是下午 6 点下单小程序端商品上架时间显示也不对。原因JDBC 连接串没加serverTimezoneAsia/ShanghaiMySQL 默认时区是 UTC而服务器时间又是东八区两边一减正好 8 小时。解决在application.yml的 datasource url 末尾加上serverTimezoneAsia/Shanghai同时重启确认。如果还不对进 MySQL 执行show variables like %time_zone%;看 global time_zone 是不是SYSTEM系统时区如果不是东八区就改成SET GLOBAL time_zone 08:00;。注意改完数据库后连接池要重连改配置后重启 Java 进程是最稳定的。还有一个冷门情况如果用了LocalDateTimeJDBC 驱动版本低也可能导致时区转换出问题把 MySQL 驱动升到 8.x 基本能解决。5.4 图片上传后回显裂图静态资源映射被拦截现象后台管理上传商品图片提示成功但前端小程序的图片地址直接裂开浏览器单独打开图片 URL 返回 404。原因后台把图片保存到本地磁盘的/upload/目录但没有告诉 Spring Boot 如何映射这个目录到 URL。Spring Boot 默认只映射classpath:/static/你写http://localhost:8080/upload/xxx.jpg自然是 404。如果上线后有 Nginx也可能是 Nginx 没有把/upload/转发到后台服务。解决在 Java 端补一个资源映射。注意路径最后面的斜杠Linux 下/home/shop/upload/少了结尾斜杠会映射失败。代码块我放在避坑章节里Configuration public class WebMvcConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file:/home/shop/upload/); } }配置完成后重启后台访问一次图片 URL 确认能打开。如果放在 Nginx 后面还应在 location 里加一条location /upload/ { proxy_pass http://127.0.0.1:8080; }不然请求到不了 Java 进程。再有就是本地 Windows 环境file:D:/shop/upload/的写法里盘符后的冒号和反斜杠也很容易写错看到一个 D 盘路径映射一直 404基本是路径格式问题。5.5 后台启动报端口占用别急着杀进程先看是哪个服务现象java -jar启动后台控制台抛出Web server failed to start. Port 8080 was already in use.进程直接退出。这是 java 启动失败怎么解决里最频繁的报错。原因之前一次启动没有彻底关闭或者电脑上另一个程序占用了 8080。有些源码还会默认用 8080 再带一个 Redis listener两个端口都是一个道理。解决先看端口到底被谁占用。Linux 用netstat -anp | grep 8080Windows 用netstat -ano | findstr 8080拿到 PID 后Windows 用taskkill /PID pid /FLinux 用kill -9 pid。如果是你自己之前跑的后台这条命令很安全但如果 PID 对应的是别的业务服务就换个端口更省事。在application.yml里把server.port改成 8081然后小程序端 baseUrl 同步改端口完美绕开。顺带一提别为了找端口占用直接重启机器那才是运维上的翻车。6. 别把源码当黑匣子两个能放进简历的进阶改造点这套源码跑通、能下单、后台能发货之后你和它之间就过了蜜月期。接下来最值得做的事不是继续堆功能而是验证它到底能在多大数据量、多高并发下站住同时把后台审计能力补上。我做的第一件事是加上操作日志——管理员改了商品价格、手动取消订单、调整用户积分这些都是高危动作没有日志等于穿着溜冰鞋走钢丝。要做得干净可以用注解 Spring AOP 统一埋点Target({ElementType.METHOD}) Retention(RetentionPolicy.RUNTIME) public interface OpLog { String module(); // 例如 商品 订单 String action(); // 例如 改价 发货 }在需要记录的 Controller 或 Service 方法上标一下然后用 AOP 拦截写日志包含操作人、IP、请求参数、耗时落库或打到日志文件都行。这个小功能在简历上可以写“基于 AOP 实现后台操作审计和用户行为追踪”面试官看到这种描述比看到“会用 CRUD”值钱得多。第二个值得做的是接口压测用 JMeter 对商品列表接口和一个下单接口分别跑 50 并发看看吞吐量和错误率。如果你发现线程调优后内存占用暴增就回头检查是不是某些查询没有分页、有没有索引缺失而不是对着源码抱怨。老实说我早期拿到源码就急着改页面没有先做压测和日志后来上线被瞬时流量打挂花了整晚才定位到一条没有索引的订单查询。先跑通、再补日志、最后压测这三步是这套源码最稳的升级路径。希望帮到你。本文还有配套的精品资源点击获取