JAVA微信小程序商城源码：完整后台才是核心，从部署到改造全解析

简介：这套JAVA微信小程序商城源码附带完整后台，适合具备一定Java基础、希望快速搭建微信商城小程序的开发者或初创团队。项目采用springmvc+mybatis+spring+maven+mysql架构，前端基于H5和CSS3，后台使用bootstrap-ace技术，整体结构清晰，易于二次开发。功能覆盖商品发布、物流管理、评价系统、优惠券、运费系统、在线客服、在线支付、在线退款以及微信管理等商城核心模块，能够帮助学习者理解小程序商城从商品展示到订单售后的完整业务闭环。资源包共20.5MB，文件类型主要是Java源码、前端页面、后台管理相关代码以及数据库脚本等，压缩为7z格式，解压后可直接导入开发工具进行学习或改造。该资源在CSDN已有5047人学习下载，说明其内容具备较好的参考价值，适合用来研究电商小程序的后台设计与接口调用逻辑。对于正在做毕业设计或实际项目选型的读者，这套源码能提供从数据库表设计到前后端联调的一站式参考方案。

1. 一套 JAVA 微信小程序商城源码，真正值钱的不是代码，是“完整后台”四个字

很多人在搜索“JAVA微信小程序商城源码+完整后台”的时候，其实并不是找不到代码，而是找到的代码根本跑不起来，或者跑起来之后发现小程序能看、后台是个空壳——用户管理只有一张表，订单管理没有状态流转，支付回调写了个假接口。这种半成品项目在小程序源码这个圈子里占了大多数，真正能直接二次开发的少之又少。

这套项目实际要解决的问题是：小程序端负责 C 端用户的下单和支付，服务端负责业务逻辑和接口，管理后台负责商品、订单、用户、营销、权限这些运营动作。你在找的“完整后台”，本质上是管理端能不能覆盖商城的核心经营闭环：商品上下架、库存扣减、订单状态机、退款流程、会员体系、以及多角色管理员权限控制。本文围绕“JAVA 后端 + 原生小程序前端 + 管理后台”这套最常见的组合来拆解，讲清楚选型逻辑、跑通步骤、核心代码实现和最容易让你翻车的几个隐蔽细节。

适合的人群很明确：有 Java 基础、想拿一套能用的商城项目做毕业设计或课程设计的在校生，以及手里有货、想快速搭个小程序商城试水的小团队。它不适合谁？不适合完全没有 Java 环境配置经验、想纯靠拖拽生成商城的纯业务人员。下面从技术栈和源码结构开始拆。

2. 商城源码的技术栈与工程结构：先认清这套代码由哪三端组成

2.1 后端选型：Spring Boot 为主流，但你要分清“全家桶”和“单机版”

一套在小程序生态里流通的 JAVA 商城源码，后端技术栈高度趋同：Spring Boot 2.x + MyBatis Plus + MySQL + Redis。少部分规模较大的会拆成 Spring Cloud Alibaba（Nacos + Gateway + Sentinel），但如果你下载的源码里带着 Nacos 配置中心、Sentinel 限流、Seata 分布式事务，建议先问自己一句：你当前的业务体量需要分布式事务吗？实际做商城，单体应用 Spring Boot 加好索引、做好缓存，支撑日单量几千完全没压力。分布式架构带来的复杂度——服务之间调用链追踪、配置同步、网关路由——对新手来说是灾难级别。

用 MyBatis Plus 而不是原生 MyBatis，几乎是现网商城项目的通用选择。原因很直接：单表 CRUD 不需要手写 XML 映射，BaseMapper 把 insert、update、selectPage 这些高频操作都封装好了，你只需要写业务代码里真正复杂的多表联查。这和你刷“java面试八股文”里讲的 mybatis 和 mybatis-plus 区别是一个道理：面试考原理，工程讲效率。

Redis 在商城项目里不是可选项。首页轮播图、商品分类、热销榜单这些读多写少的数据，放数据库里每次查询都是浪费。而且小程序商城的会话状态维护——用户登录后发的 token 存 Redis 并设置过期时间——是最常见的做法。至于 Elasticsearch 做商品搜索，建议第一版别碰，MySQL 的 LIKE 查询在数据量到十万级之前完全够用。

2.2 小程序端与后台管理端：原生小程序还是 uniapp，模板语法决定你的修改成本

看源码时先确认一件事：小程序端是原生写的还是 uniapp 写的。原生小程序的好处是 wxml、wxss、js 三件套非常直观，没有编译层，改了代码直接预览，调试起来心智负担小。缺点是你如果想同时发抖音小程序、支付宝小程序，得再维护一套代码。uniapp 用 Vue 语法，能一套代码多端发布，但它的底层是编译到各端，遇到平台差异时——比如微信小程序的蓝牙接口、虚拟支付限制——你得写条件编译。从“下载源码后最快跑通并二次开发”的角度，原生小程序更直接；从长期多端布局的角度，uniapp 更划算。

后台管理端的技术栈，老项目一般是 JSP 或者 FreeMarker 服务端渲染，新项目清一色前后端分离：Spring Boot 提供 JSON 接口，前端用 Vue 2 + Element UI 或 Vue 3 + Element Plus。这里有个坑：如果你下载的源码是老式的 JSP 后台，那么它的权限控制很可能写在服务端拦截器里，和页面强耦合，你想把后台改成前后端分离，几乎是重写。搜索“JAVA微信小程序商城源码+完整后台”时，优先找 API 接口和管理端页面分离的项目结构，后期接其他前端框架或者做移动端管理，都不用动服务端逻辑。

2.3 完整后台包含哪些核心模块

一个能叫“完整后台”的管理端，至少要有这六块：

判断源码完整度的最快方法：不看 README 写的功能列表，直接看管理端的侧边栏菜单数量。少于 15 个菜单项的管理后台，基本只能算“半成品”。另外一个判断维度是看权限管理有没有做“菜单权限”和“按钮权限”的区分，只做了菜单级权限的管理后台，在多人协作时会出现运营能进商品管理页但不能点“删除”按钮的问题——如果它根本没区分，那就是表面完整。

3. 把跑起来从“玄学”变“确定”：本地部署 JAVA 商城项目的最小步骤清单

3.1 前置环境检查：Java、Maven、MySQL、Redis 一个都不能少

接手一套未知源码时，前置环境配置是第一道坎，也是新手最常见的翻车点。我一般会先按顺序检查四个东西：JDK 版本、Maven 版本、MySQL 版本、Redis 是否启动。JAVA 商城源码对 JDK 的版本要求非常敏感：Spring Boot 2.x 用 JDK 8 或 11 都行，但 Spring Boot 3.x 强制要求 JDK 17。如果你当前源码的 pom.xml 里 parent 是 spring-boot-starter-parent 2.7.x，而你机器上装了 JDK 17，大概率编译不报错，但启动时会遇到“源发行版 17 需要目标发行版 17”这类错误。

# 检查本机 java 和 maven 版本，确认与项目要求一致 java -version mvn -version # 如果是 JDK 17 但项目是 Spring Boot 2.x，手动指定编译版本 # 在 pom.xml 的 properties 区域添加或修改以下配置 # <java.version>1.8</java.version> # <maven.compiler.source>1.8</maven.compiler.source> # <maven.compiler.target>1.8</maven.compiler.target>

参数说明：这段命令里 java -version 看的是当前终端的默认 JDK。很多刚配完“java环境变量配置”的读者会遇到一个典型问题：在 IDEA 里改了 Project SDK，但终端里 java -version 还是旧版，这是因为系统环境变量 PATH 里的顺序没有把新 JDK 的 bin 目录放在前面。mvn -version 则会直接显示 Maven 正在使用的 JDK 版本，因为 Maven 本身是用 JAVA_HOME 环境变量来定位 JDK 的。

Maven 依赖下载慢是另一个常见卡点。国内直接用中央仓库，一个 Spring Boot 项目几十个依赖，下载俩小时都有可能。解决方法是检查源码是否自带 settings.xml，如果没有，在本地 Maven 的 conf/settings.xml 里配置阿里云镜像。这一步做好了，整个项目的依赖导入时间能从半小时缩短到三分钟。

3.2 数据库初始化流程：从 sql 脚本到配置文件的完整闭环

拿到源码后，在项目根目录或 doc 目录下找一个 .sql 文件，这就是你的“后悔药”。常见的坑是这个 sql 文件不完整——要么缺少初始化数据，要么表结构里外键关系混乱。实际操作建议直接用数据库管理工具新建一个数据库（比如 mall），字符集选 utf8mb4，排序规则选 utf8mb4_general_ci，然后导入 sql 脚本。为什么不直接执行项目里的初始化脚本？因为很多源码自带的脚本没有 create database 语句，你不先建库直接导入会报“No database selected”错误。

-- 检查导入是否完整：统计表数量和关键表记录数 SELECT COUNT(*) AS table_count FROM information_schema.tables WHERE table_schema = 'mall'; -- 核心三张表至少要看到数据 SELECT COUNT(*) FROM goods; -- 商品表，至少有几条测试数据 SELECT COUNT(*) FROM orders; -- 订单表，测试数据可能为空但表要存在 SELECT COUNT(*) FROM user; -- 用户表，需要至少有一条测试账号

MySQL 版本与 sql 脚本的兼容性也值得一提。很多老商城源码的 sql 脚本用了 MyISAM 引擎或者不支持 utf8mb4，如果你用的是 MySQL 8.0，可能遇到排序规则不支持的问题。最好的方式是把 sql 脚本里的 DEFAULT CHARSET 统一改成 utf8mb4，这个操作在管理工具的替换功能里一键完成。另一个隐形坑是 sql_mode 严格模式下，老脚本里“0000-00-00 00:00:00”这类日期默认值会被拒绝执行，遇到就在连接配置里加上 sqlMode=NO_ENGINE_SUBSTITUTION 或者直接修改脚本里的日期值。

3.3 修改 application.yml 关键配置项，保证一次启动成功

数据库导完，接下来是配置文件。这块我看过太多人栽跟头的场景——数据库密码和 Redis 密码没改导致启动报错，然后去网上搜“java连接池拒绝访问”越查越偏。先找到 application.yml 或 application-dev.yml，按下面清单逐项核对：

# 本地 Redis 没装或者没启动，先启动 redis-server（Mac/Linux 示例） redis-server --daemonize yes # 检查 Redis 是否正常响应 redis-cli ping # 正常返回 PONG

配置文件的优先级也是一个容易理解错的地方。Spring Boot 加载配置的顺序是 application.properties（或 yml）优先于 application-dev.yml，很多人把数据库配置改在 application.yml 里，但项目实际激活的是 dev profile，导致改动不生效。启动类或 application.yml 里明确写了 spring.profiles.active=dev 时，你要改的就应该是 application-dev.yml。这个细节看似基础，但在排查“为什么我改了配置还是报连不上数据库”时，90% 的根因都在这里。

启动项目时还有一个容易忽略的点：很多商城源码管理后台单独是一个 Spring Boot 模块，比如 admin-server 和 api-server 分开两个端口。这意味着你要启动两个 Java 进程，而不是一个。看项目根目录的 pom.xml 里 modules 标签，如果里面有两个以上子模块，每个子模块的 application.yml 都要检查一遍配置。否则你会遇到小程序接口通了但后台登录不了，或者后台进去了但商品列表空白这类半通不通的问题。

3.4 小程序端连接本地服务的路径修正

小程序端是最后一块拼图。先打开微信开发者工具，导入源码中的小程序目录。这里有一个几乎所有商城源码都会坑你的地方：小程序代码里请求后端的 baseUrl 默认写着生产环境域名，或者写的是局域网 IP。你本地跑后端，必须把 baseUrl 改成 http://localhost:8081/api 这种本地地址。但微信小程序有个限制——开发者工具里可以勾选“不校验合法域名”，真机预览时必须在微信公众平台配置 request 合法域名，而且必须是 HTTPS 域名。

改完 baseUrl 之后，用测试账号登录一次。如果登录接口返回成功但 token 校验失败，去排查后端代码里有没有对 referer 或 token 做二次校验。小程序自带的 wx.request 会带上 referer 头，有些源码后端针对这个做了防盗链判断。这个现象很隐蔽，报错会显示跨域或者 403。另外，小程序端的 appid 配置也要检查，源码里大概率写的是作者自己的 appid，你需要替换成自己的，否则会出现无法登录微信开发者工具或者接口调用鉴权失败的问题。把“java后端实现微信小程序登录”的链路打通，本地这套项目就算完整跑起来了。

4. 解密后端核心链路：从登录鉴权到订单支付，代码照着改就能用

4.1 微信小程序登录换 openid 与自定义登录态

小程序商城的第一步是解决“用户是谁”的问题。原理是：小程序端调用 wx.login() 拿到临时凭证 code，把 code 发给你的后端；后端用 appid + secret + code 去微信的接口换取 openid 和 session_key，然后生成自己的登录态 token 返回给小程序。这里最关键的一点：openid 是用户在你这个小程序里的唯一标识，但你不能把 openid 直接当登录凭证暴露给前端——上过线的程序员都知道，openid 被截获等于账号被盗。

// 典型的小程序登录接口代码（省略了参数校验和异常处理） @PostMapping("/login") public Result login(@RequestBody LoginRequest request) { // 1. 拿着 code 向微信服务器换 openid String url = "https://api.weixin.qq.com/sns/jscode2session" + "?appid=" + appId + "&secret=" + appSecret + "&js_code=" + request.getCode() + "&grant_type=authorization_code"; String result = restTemplate.getForObject(url, String.class); JSONObject json = JSONObject.parseObject(result); String openid = json.getString("openid"); // 2. 查用户表，不存在则注册（记录 unionid 与否取决于项目需求） User user = userMapper.selectOne( new LambdaQueryWrapper<User>().eq(User::getOpenid, openid)); if (user == null) { user = new User(); user.setOpenid(openid); user.setCreateTime(LocalDateTime.now()); userMapper.insert(user); } // 3. 生成自定义 token，存 Redis，设置 7 天过期 String token = UUID.randomUUID().toString().replace("-", ""); redisTemplate.opsForValue().set( "mall:token:" + token, user.getId().toString(), 7, TimeUnit.DAYS); return Result.success(new LoginResponse(token, user)); }

逻辑说明：这段代码完成了登录认证的核心流程。第一步向微信接口发起请求时，restTemplate 是 Spring 框架的 HTTP 客户端，实际上新项目用 Hutool 的 HttpUtil 更简洁，性能和可读性都更好。第二步的 LambdaQueryWrapper 是 MyBatis Plus 的查询构造器，把原来的字符串列名改成方法引用，编译期就能发现字段名拼写错误，后续“java策略模式”做多端登录时可以在这里扩展，比如增加手机号验证码登录时只需要在 UserType 上打标。第三步的 token 策略很关键，把 token 存 Redis 而不存数据库，因为登录态是高频率读写的数据，数据库扛不住这个读写量，而且 Redis 自带过期清理机制。

4.2 商品列表的缓存策略：首页响应时间从 200ms 降到 30ms 的做法

商城首页的接口并发是最大的，轮播图、分类导航、推荐商品这三个数据几乎是所有用户打开小程序第一眼就要加载的。一种常见的粗暴实现是每次都查数据库，在数据量小的时候没感觉，运营后台一上活动，首页接口就变慢。合理的设计是通过 Redis 缓存加一个手工清理机制。

public List<IndexData> getIndexData() { // 先查缓存 String cacheKey = "mall:index:data"; String cached = redisTemplate.opsForValue().get(cacheKey); if (StringUtils.isNotBlank(cached)) { return JSONObject.parseArray(cached, IndexData.class); } // 缓存没命中，查数据库并回填缓存 List<IndexData> data = new ArrayList<>(); data.add(getBannerList()); data.add(getCategoryList()); data.add(getHotGoods()); // 缓存 10 分钟，运营调整首页后手工删缓存 redisTemplate.opsForValue().set( cacheKey, JSONObject.toJSONString(data), 10, TimeUnit.MINUTES); return data; }

这里要注意两个工程习惯：第一，缓存里存的是拼接好的整个首页 JSON 而非单个商品数据，是为了减少小程序端多次请求的延迟，但代价是缓存粒度粗，任何一个商品改名或改价都要清理整块缓存。第二，添加 @CacheEvict 注解让你在后台编辑商品时自动清理缓存，避免运营改了商品但线上不生效的问题。缓存穿透的问题也值得设计时考虑——如果 Redis 和数据库都没有这个 key，恶意请求会直接打到数据库上，这种场景可以用空值缓存或者布隆过滤器兜底。

4.3 订单状态机设计：“待付款→已付款→已发货→已完成”中间的细节

订单模块是最考验代码功底的部分，因为订单状态永远不是一条线走到底。代码里出现最多的逻辑分支是退款和取消：待付款状态可以取消，已付款状态可以申请退款，已发货状态只能退货。如果源码里的 order 表只有一个 status 字段而没有状态流转记录，那这个源码基本不具备生产可用性——运营在处理客诉时需要知道订单从哪个状态变成了哪个状态，这就是“操作日志”存在的意义。

-- 订单表必备的状态字段和日志表的关联查询 CREATE TABLE order_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT '订单号，全局唯一', user_id BIGINT NOT NULL COMMENT '用户 id', total_amount DECIMAL(10,2) NOT NULL COMMENT '总金额，单位：元', status TINYINT NOT NULL COMMENT '10待付款 20已付款 30已发货 40已完成 50已取消 60退款中 70已退款', create_time DATETIME NOT NULL, update_time DATETIME NOT NULL ); -- 每一步状态变更都要落一条日志 CREATE TABLE order_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL, from_status TINYINT, to_status TINYINT NOT NULL, operator VARCHAR(64) NOT NULL COMMENT '操作人标识', remark VARCHAR(255), create_time DATETIME NOT NULL );

订单号生成规则的坑在这里一并说清。很多新写的商城代码直接用数据库自增 ID 当订单号，问题在于小程序端的“订单列表”和“订单详情”页面如果通过订单号做查询，自增 ID 会让竞对知道你的日单量。常见做法是用 Redis 生成每天自增的序号，拼上日期形成类似 20250101120001 的流水号。代码里的状态流转建议用状态机模式管理，而不是在每次业务操作里写 if 判断，否则后面加一个“仅退款”分支时会让你改得想骂人。

4.4 支付回调的幂等处理与对账思路

支付环节是“微信小程序虚拟支付”相关限制之外最头疼的部分。微信支付的回调接口要求你的处理逻辑必须做到“即使回调重复通知多次，也只处理一次”。很多源码实现不到位：回调后直接改订单状态为已付款，但如果网络抖动导致回调重复发送了两次，第二回调会让订单状态被更新两次，同时给用户账户余额加了两次。真正可靠的实现是在回调处理器里做“先查询再更新”并加上状态条件。

// 支付回调处理（简化版） @PostMapping("/pay/notify") public String payNotify(@RequestBody String xmlData) { // 1. 解析微信回调报文并验签（关键步骤，不能省略） Map<String, String> params = WxPayUtil.xmlToMap(xmlData); if (!WxPayUtil.verifySign(params, apiV3Key)) { return "FAIL"; } String orderNo = params.get("out_trade_no"); String transactionId = params.get("transaction_id"); // 2. 使用数据库乐观锁：只有当前状态是“待付款”才允许改成“已付款” int updated = orderInfoMapper.updateStatus( orderNo, 10, // 待付款 20, // 已付款 transactionId); if (updated > 0) { // 3. 只有真正更新成功了才给用户加积分、减库存 userService.addPointsByOrder(orderNo); goodsService.deductStock(orderNo); return "<xml><return_code><![CDATA[SUCCESS]]></return_code></xml>"; } else { // 状态不是待付款，说明已经处理过，直接返回成功 return "<xml><return_code><![CDATA[SUCCESS]]></return_code></xml>"; } }

这里的代码逻辑避开了幂等问题的绝大多数坑：update 语句里带上了“status = 10”的条件，数据库层面的行锁保证并发安全，后到重复回调因为条件不满足而影响零行，直接返回成功不再处理。接口幂等是“微信小程序设置缓存时间”这类日常运维问题之外，真正考验后端水平的地方。如果你在自己写项目，也优先用这个模式，而不是在代码里加分布式锁——前者简单、不会有锁超时的烦恼，代价只是多写一条状态条件的 SQL。

5. 后台管理源码如何改造：从能用升级到好用的四五个关键改造点

5.1 权限管理细化：从“菜单可见”到“按钮可点”

大多数商城源码的权限管理只做到菜单级——你给运营分配一个“商品管理”菜单，他能看到整个商品管理页面，包括“删除”和“批量下架”这种高危按钮。生产环境运营误删商品的事件，十有八九就是因为按钮级权限没控制。改造思路是在后端接口层面加上注解权限判断，前端根据权限标识隐藏按钮。

// 自定义权限注解和一个简单的拦截器实现按钮级权限控制（伪代码） @Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface RequiresPermission { String value(); } // 商品删除接口 @RequiresPermission("goods:delete") @DeleteMapping("/goods/{id}") public Result deleteGoods(@PathVariable Long id) { goodsService.deleteGoods(id); return Result.success(); }

拦截器里通过反射获取方法上的 @RequiresPermission 注解，拿到 value 后与当前登录用户的权限列表比对。不匹配直接返回 403，而不是等业务代码执行到一半再报错。这个改动量大概是每个 Controller 方法加一行注解、加一个全局拦截器类，两个小时内能完成，但换来的运营安全性提升非常明显。更重要的是，这套设计为后续加“管理员操作日志”打了底子——在拦截器里记录谁的什么操作被拒绝，对安全生产来说比“动态路由前端按钮隐藏”这种花活实用得多。

5.2 商品模块的 SKU 与库存扣减实战改造

商品模块是后台管理里最复杂的部分，因为牵扯 SPU（标准化产品单元）和 SKU（库存量单位）的概念。一个商品“iPhone 15 Pro”是 SPU，它有“黑色/256G”“蓝色/512G”这些具体的销售规格，每个规格是一个 SKU。如果源码里的商品表只有一张表，字段直接是价格和库存，说明作者没打算让你做真正意义上的规格化商品销售。

-- 常规的 SPU/SKU 两张表设计 CREATE TABLE goods_spu ( id BIGINT PRIMARY KEY AUTO_INCREMENT, goods_name VARCHAR(100) NOT NULL, category_id BIGINT NOT NULL, main_image VARCHAR(255), detail_html TEXT, status TINYINT DEFAULT 0 COMMENT '0下架 1上架' ); CREATE TABLE goods_sku ( id BIGINT PRIMARY KEY AUTO_INCREMENT, spu_id BIGINT NOT NULL, spec_name VARCHAR(100) NOT NULL COMMENT '例如：黑色/256G', price DECIMAL(10,2) NOT NULL, stock INT NOT NULL DEFAULT 0 );

库存扣减的正确做法是在创建订单事务里执行带条件扣减的 SQL：UPDATE goods_sku SET stock = stock - #{count} WHERE id = #{skuId} AND stock >= #{count}，影响行数为 0 则说明库存不足，直接回滚事务。很多源码里是先查一遍库存再 update，这在高并发下会出问题——两个用户同时买最后一个库存，都查到了现存 1 件，然后都走到扣减，导致超卖。“先查后改”是新手最容易犯的并发错误，改造务必按“条件更新”的标准去做。

5.3 后台接口返回体统一与全局异常处理

看一套源码的工程质量，最快捷的入口是它的返回体是否统一。成熟项目的返回体是Result.success()和Result.error()，Data 字段塞具体数据；粗糙项目则每个接口返回 Map 或者裸 List，导致小程序端每个请求都要自己判断成功失败。改造方案是定义全局 ResponseBodyAdvice 和 @RestControllerAdvice。前者拦截 Controller 的返回结果自动包一层 Result，后者统一捕获业务异常和系统异常，避免异常堆栈直接吐给前端造成信息泄露。

这套统一处理的价值在联调阶段尤其显著。小程序开发者不需要在每次请求里重复写错误码判断逻辑，后台管理员也不需要看到一串看不懂的英文异常。配合自定义的 BizException 类，业务代码里要表达“库存不足”“支付超时”这类业务错误时，只需要throw new BizException(5001, "库存不足")，异常处理器自动把错误码和信息序列化返回给前端。这个改造对二手源码来说性价比极高，一次改动全局生效。

5.4 管理后台的仪表盘和报表查询优化

后台首页会有“今日订单量”“今日销售额”“新增用户数”这几个统计卡片，看源码里这块是现成实现的还是留了 TODO。常见的低效写法是每次加载首页时执行四个 COUNT(*) 全表扫描，如果订单表数据到了几十万条，后台首页会卡到怀疑人生。改造方式有两条路：数据量小时用 Redis 记录当天的累计值，每次下单在业务代码里累加；数据量大了走定时任务每小时把统计数据刷入一张统计表，后台首页直接查统计表。

对于后一条路，用 Spring 的 @Scheduled 注解是常见做法，但由于很多商城源码部署在单机环境，简单用注解没问题；如果你放在集群里跑定时任务就要加分布式锁了，否则每个节点都会执行一遍统计。这一节很适合对比对比参考“java后端完整成长路线”里的知识体系——从单体到集群，每个阶段的改造点是不一样的。

6. 避坑指南：本地跑通之后，这些隐蔽问题够你排查一整天

6.1 现象：小程序端请求接口报“http://localhost 不在以下 request 合法域名列表中”

这是新接触小程序开发的人遇到的最频繁的问题。原因是微信开发者工具默认开启了“校验合法域名”选项，而你本地访问的地址是 http://localhost:8081，既不是 HTTPS 也不是合法域名。解决方式比较直接：在微信开发者工具的“详情 - 本地设置”里勾选“不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书”。但要注意，这个选项只在开发调试时有效。等你上线生产，必须要把后端接口域名和小程序后台填写的 request 合法域名保持一致，并且一定是备案过的 HTTPS 域名。很多团队在联调阶段用 IP 访问正常，一上线就发现手机打不开，问题就出在这。

6.2 现象：登录接口返回“code 无效”错误

微信小程序的 code 是一次性的，且有效期只有五分钟。源码里的登录接口如果是先调用了一次 jscode2session，之后在另一个地方又用同一个 code 调用了一次，第二次必现“invalid code”。这个坑多出现在老项目里：登录操作被拆成“获取 openid”和“注册/登录”两个接口，小程序端先请求第一个再请求第二个，但微信只允许 code 兑换一次。解决方式是合并接口或者在后端对 code 做一次使用即焚的标记，业务层别依赖 code 做重复处理。如果你在改造后还遇到“code 无效”，去小程序端检查一下有没有别的请求也在调用 wx.login 生成了新 code，导致旧 code 被顶掉。

6.3 现象：后台管理系统能登录，但菜单和按钮不显示

这种情况十有八九不是代码问题，而是你的管理员账号权限没有关联角色。源码自带的初始化 SQL 里通常只有超级管理员的账号和角色的绑定关系，你新建的管理员如果没有绑定角色，登录进来就是一个空菜单页面。去数据库检查admin_user、role、admin_user_role三张表的关联数据，确认新建用户的时候有没有写角色绑定逻辑。如果源码里没有一键分配角色的功能，八成是在编辑管理员的弹窗里漏看了“选择角色”的下拉项。看过太多人在这个问题上卡了两三个小时，还以为是前端路由问题去 debug 半天，实际上就是一张关联表没数据。

6.4 现象：本地启动后端报“端口被占用”

Spring Boot 默认 8080 端口是很多应用的默认选择，你本机很可能跑了别的 Java 进程，或者是 IDEA 自己占用了 8080。换个端口是最快的解法，但要注意改动的位置是 application.yml 里的 server.port，同时小程序端的 baseUrl 也要同步改，两个不同步会导致接口全部连接失败。这里的连带影响经常被忽略：很多商城源码的后台管理端和后端 API 不在同一个端口，你改了 API 的端口，后台管理端的代理配置（比如 Nginx 或前端 webpack devServer）也要跟着改。排查思路理顺之后就不慌了：要么杀掉占用进程，要么把商城项目的 API 端口和管理端的端口都换到一组没冲突的组合上。

6.5 现象：数据库导入报错“Unknown collation: utf8mb4_0900_ai_ci”

这个报错很有代表性，是 MySQL 版本不对导致的。utf8mb4_0900_ai_ci 是 MySQL 8.0 默认的排序规则，但如果你的 sql 脚本是在 MySQL 5.7 环境生成的，可能用的是 utf8mb4_general_ci；反过来，如果脚本是 MySQL 8.0 导出的，而你的本地数据库是 5.7，导入就会因为不认识 0900 排序规则而失败。解决方法有两个：一个是你把本地数据库换到和源码一致的版本（看 README 里有没有写环境要求），另一个是全局替换 sql 脚本里的排序规则为 utf8mb4_general_ci。如果脚本里没有显式写 COLLATE，只是写了 DEFAULT CHARSET=utf8mb4，那在 5.7 导入不会出这个问题，但 8.0 导入就没有问题。

7. 上线前的改造验证：用三个只看细节的方法确认这套源码能扛住

全套跑通只是起点，真正投入生产前要做三件事。

第一件：写一个简单的接口压测脚本或直接用压测工具，对准商品列表和订单提交这两个核心接口，并发调 50 个线程各跑 200 次，观察成功率是否在 99.9% 以上、平均响应时间有没有超过 800ms。这一步很容易暴露数据库连接池配置不合理、SQL 缺少索引、缓存没生效等底层问题。用压测工具跑出来的结果表要有“订单创建成功率”“库存超卖数量”两个指标，超卖数量大于零说明你的库存扣减代码还没改到位。

第二件：检查服务端日志里有没有大量 ERROR 级日志被打出来。生产级别的要求是：业务异常应该被全局异常处理器捕获并转换，而不是打印一整页堆栈。如果源码里到处是 try-catch 里 printStackTrace()，说明代码风格比较随意，你接手后要逐步替换为日志框架统一输出。另外通过“java最新网站更新入口”这类方式去关注 Spring Boot 和 MyBatis Plus 的漏洞公告，老源码容易有依赖漏洞，至少要把已知的高危漏洞依赖版本升上去。

第三件：做一次完整的订单全链路演练。用户注册、浏览商品、加购物车、下单、模拟支付回调、查看订单状态、申请退款、后台发货、确认收货，这九个环节连贯走完不加一个断点。大多数源码在单点功能测试时表现正常，但一到“退款后库存是否回补”这种交叉场景就露馅。这类问题没法靠阅读代码全部发现，只能用业务测试路径一步步踩过去。我见过一套源码在“用户取消订单”后没有把冻结的库存解冻，商家运营了一周之后发现系统提示可售库存变成了负数——这个事故要是发生在你的项目里，比跑通慢一点严重得多。

再聊一件工具层面的习惯：在微信开发者工具里调试的时候，把 Network 面板打开，观察每个接口的耗时和数据包大小。小程序端对包体积有 2MB 总限制，图片别直接存 base64 塞在接口返回值里。很多商城首屏慢的问题不是后端性能不行，而是接口把商品详情 HTML 原样返回导致传输数据量动辄几百 KB。如果源码有这个问题，把详情改为图片懒加载或者拆成独立接口，首屏速度立刻就会有体感提升。

我这几年帮人看过的商城源码不下二十套，坦白说每一套都有“能跑”和“能上线”之间的差距，而差距基本都集中在上面这些容易被忽略的细节上。找一个周末，按这套流程把源码从检查到改造完整走一遍，你会把大半的坑都踩平。希望帮到你。

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