简介这是一份基于 Java 技术栈开发的微信小程序购物商城项目资源适合正在学习前后端分离开发、想了解小程序电商实现方式的开发者参考。资源围绕 Java 后端接口与小程序前端结合的电商场景包内主要是小程序端源码覆盖商品展示、登录授权、购物车、下单支付等核心流程并包含商品列表、购物车、订单、个人中心等页面模块以及公共组件、工具函数和静态图片资源页面结构、样式与逻辑分离清晰js、wxml、wxss 文件一一对应便于逐页查阅。压缩包共 98 个文件以 js、wxml、wxss、json 等微信小程序源码为主另有 png、jpg、gif 图片素材和少量配置文件整体仅 138KB结构精简清晰适合快速阅读和二次开发。已有 1431 人学习下载说明该资源对同类项目实践者具备一定参考价值。通过阅读页面逻辑、公共组件和工具库可以快速上手小程序商城的基本架构并在现有功能模块上复用或扩展自己的代码。1. 基于JAVA开发的微信小程序购物商城不止是“能跑”的最小闭环做小程序商城前端用微信原生还是 uni-app后端用 JAVA 还是 Node其实在动手前就该定死。基于JAVA开发的微信小程序购物商城本质上是把「商品展示 → 加购 → 下单 → 支付 → 订单状态流转」这条链路用 Spring Boot 这类后端框架和小程序前端各扛一半。对从业者来说它解决的是两个问题一是给没有电商经验的团队一个可复用的架子二是把登录、支付、库存这些绕不开的硬骨头提前暴露出来。这篇文章适合正打算自研商城、又不想被外包牵着走的开发者和技术负责人。我会按“选型 → 后端 → 小程序端 → 排坑 → 进阶”的顺序把每一步的参数、边界和验证方法讲清楚全文基于我做过的一个真实线上项目代码可以直接抄但更重要的是知道为什么要这么写。2. 技术选型与工程结构为什么这单异常指挥中心不背锅2.1 选型理由JAVA后端在商城场景里到底赢在哪先回答一个最容易被新人问住的问题商城后端用 JAVA 是不是太“重”了我的答案是看你的团队构成和业务预期。如果只是做个 200 人的校园集市Node 或 PHP 确实更快但只要涉及多商户、优惠券、会员等级、库存流水对账JAVA 的 Spring Boot 生态优势就出来了——事务管理由 Spring 统一托管MyBatis-Plus 把 CRUD 压缩到几乎没有样板代码Redis 做缓存和分布式锁都有官方文档级的成熟方案。我在项目里用的是 Spring Boot 2.7 MyBatis-Plus 3.5 MySQL 8.0 Redis 6这套组合在“中小并发、快速迭代”的商城场景里最稳也最容易招到能维护的人。另一个容易被忽略的点是联调效率。小程序端的wx.request天然走 HTTPS而后端如果用 Spring Boot 内嵌 Tomcat开发环境只需要在application.yml里配一个自签名证书就能本地联调不必像传统 SSM 那样把 WAR 包丢进外部容器。再加上 Spring Boot 的自动配置一个空项目从生成到能跑通/health接口五分钟以内就能搞定。别小看这五分钟它决定了新人入职第一天的体感。2.2 工程目录与数据库设计六张表撑起第一版商城系统最容易犯的错是上来就设计二十张表。第一版上线我建议把表收敛到六张user用户、goods商品、cart购物车、order订单、order_item订单明细、banner首页轮播。会员、优惠券、评价这些字段先预留但不要建表等运营真提需求再加。数据库设计的关键不是字段多而是把“状态”和“时间戳”这两类字段定死。比如order表里必须有status0 待支付、1 已支付、2 已发货、3 已完成、4 已取消和pay_time、ship_time这两个时间戳将来做对账和超时关单都靠它。后端工程我习惯按“控制层 → 服务层 → 数据层”三层拆包但controller里不允许写业务逻辑。下面是一个标准的GoodsController骨架注意分页参数是怎么接收的RestController RequestMapping(/api/goods) public class GoodsController { Resource private GoodsService goodsService; /** * 商品分页查询 * param page 页码从1开始 * param size 每页条数最大50 * param categoryId 分类ID可为空 */ GetMapping(/list) public ResultIPageGoods list( RequestParam(defaultValue 1) long page, RequestParam(defaultValue 10) long size, RequestParam(required false) Long categoryId) { if (size 50) { size 50; } return Result.ok(goodsService.pageQuery(page, size, categoryId)); } }这段代码逻辑很直白但有两个细节要注意一是size必须做上限兜底小程序端如果下拉加载更多时把size传成 10000MySQL 的LIMIT会把数据库拖垮二是categoryId用了包装类型Long而不是基本类型long这样前端不传这个参数时它才是null否则会报参数缺失错误。我在项目里看到过太多因为这里用long导致前端必须传categoryId0才能调通的接口纯属没必要。2.3 数据库索引一张表只建三个索引商城查询的热点集中在商品列表和订单列表索引策略必须围绕这两个方向。goods表上我建了idx_category_id和idx_status两个索引order表上建了idx_user_id和idx_status。这里有个血泪经验order表别在create_time上建索引。因为下单时间天然递增MySQL 的 B 树在数据量大之后会导致“页分裂”写入性能断崖下跌。如果确实需要按时间排序直接在 SQL 里ORDER BY create_time DESC就行加上user_id索引的过滤后排序的数据量已经很小了。MySQL 8.0 的EXPLAIN是排查慢查询的第一工具。我一般会让团队成员把慢查询日志打开阈值设成 1 秒然后每周看一次mysqldumpslow的结果。线上商城 90% 的慢查询都出在“多表 JOIN”上。我第一版就踩过坑订单列表查询把order、order_item、goods三张表 JOIN 在一起数据到 5 万条时接口响应从 80ms 涨到 1.2s。后来改成先查order表再用order_item的order_id批量查明细性能立刻回到 100ms 以内。记住一个原则能拆成两次查询就不要 JOIN。3. 后端核心模块商品、购物车、订单与在线支付3.1 小程序登录与手机号获取code2Session 的完整链路小程序登录不是简单地调一个接口就完事。用户在wx.login拿到临时code后端拿这个code去微信服务器换openid和session_key这是第一层获取手机号是第二层需要用户在页面点按钮触发getPhoneNumber拿到code注意这里是code不是encryptedData再回传后端。很多文章还在讲用encryptedData和session_key解密手机号那是旧方案的残留现在官方推荐的是手机号快速验证组件返回的code有效期只有五分钟且只能用一次。后端接口设计通常长这样PostMapping(/login) public ResultString login(RequestBody LoginRequest request) { // 1. 用 wx.login 的 code 换 openid String openid wxService.code2Session(request.getWxCode()); // 2. 用手机号组件的 code 换真实手机号 String phone wxService.getPhoneNumber(request.getPhoneCode()); // 3. 查库或创建用户返回自定义登录态 token User user userService.findOrCreate(openid, phone); String token jwtService.generateToken(user.getId()); return Result.ok(token); }这里有三个关键点。第一wxService调微信接口时必须做超时控制我用的是RestTemplate搭配connectTimeout3000, readTimeout5000因为微信服务器偶尔会抖动如果后端同步等待太久小程序端就会转圈卡死。第二session_key不要存数据库它是敏感信息只在需要解密比如旧的encryptedData方式时临时用一下用完就丢。第三自己生成的token建议用 JWT 但别把openid放进去只放userId因为openid属于半敏感信息泄露后容易被恶意拼接请求。3.2 商品与购物车接口库存校验必须放在数据库层商品列表接口比较简单但购物车接口有一个高频坑加购时要不要校验库存答案是不要。购物车本身是“意向清单”用户加购 100 件商品是合法的库存校验应该发生在“提交订单”那一刻。所以购物车表里只需要user_id、goods_id、quantity、checked四个字段checked用来标记“本次结算是否选中”。购物车的加购接口我会在服务层加一个“重复商品合并数量”的逻辑Transactional(rollbackFor Exception.class) public void addToCart(Long userId, Long goodsId, Integer quantity) { // 同一用户 同一商品只保留一条记录数量累加 Cart cart cartMapper.selectOne( new LambdaQueryWrapperCart() .eq(Cart::getUserId, userId) .eq(Cart::getGoodsId, goodsId)); if (cart null) { cart new Cart(); cart.setUserId(userId); cart.setGoodsId(goodsId); cart.setQuantity(quantity); cartMapper.insert(cart); } else { cart.setQuantity(cart.getQuantity() quantity); cartMapper.updateById(cart); } }加Transactional是因为“查 改”是两步操作没有事务的话并发请求下可能插入两条一模一样的购物车记录。LambdaQueryWrapper是 MyBatis-Plus 的写法比字符串硬拼 SQL 安全得多字段名重构时不会漏改。这里还得注意「数量上限」单个商品加购数量超过 999 就弹窗提示“单次最多购买 999 件”这是电商平台通行的风控规则防的是有人用脚本刷爆库存。商品表一定要加“下架”功能而不是“删除”。物理删除商品会让历史订单的明细变成“已售罄”对账的时候非常痛苦。正确做法是加一个 status 字段0 上架 1 下架商品列表接口默认只查 status0。3.3 下单与支付回调库存预占和幂等处理下单接口是整个商城的核心也是最容易“翻车”的地方。一个合格的下单接口要依次做参数校验 → 库存预占 → 生成订单 → 返回支付参数。库存预占不是UPDATE goods SET stock stock - 1就完事而是必须加上“库存足够”的条件Transactional(rollbackFor Exception.class) public Order createOrder(Long userId, ListCartItem items) { for (CartItem item : items) { // 乐观锁扣减库存affected0 说明库存不足或商品被并发改过 int affected goodsMapper.deductStock(item.getGoodsId(), item.getQuantity()); if (affected 0) { throw new BizException(500, 商品库存不足或已下架); } } // 生成订单主表和明细表 Order order buildOrder(userId, items); orderMapper.insert(order); // 清空已选中的购物车 cartMapper.deleteCheckedItems(userId); return order; }deductStock对应的 SQL 是UPDATE goods SET stock stock - #{quantity} WHERE id #{goodsId} AND stock #{quantity}这比先SELECT stock再UPDATE的方式更安全因为“判断 扣减”在数据库层是原子操作。这里还需要注意下单接口一定要在事务里如果订单生成失败必须把扣掉的库存回滚回来。支付回调是另一个重灾区。微信支付的回调地址notify_url会接收支付结果后端要做三件事验签、改订单状态、返回SUCCESS。验签用官方 SDK 的WXPayUtil.isSignatureValid就行但“改订单状态”必须加幂等判断——如果回调重复到达不能把订单从“已支付”改成“已取消”。我的习惯是UPDATE order SET status 1 WHERE order_no ? AND status 0affected 0说明已经处理过直接返回SUCCESS给微信。4. 小程序端实现从首页到结算的完整链路4.1 项目初始化与导航栏适配头部高度是第一个坑小程序前端我用的是原生框架没有上 uni-app。理由很简单商城业务和微信支付的耦合很深原生框架的 API 覆盖最全遇到问题查官方文档最直接。如果你团队里有人精通 Vue选 uni-app 也能做但要知道它最终也是编译成小程序代码在wx.getMenuButtonBoundingClientRect这类底层 API 的响应上会多一层封装。新建项目后第一件事就是适配顶部导航栏。iPhone 的刘海屏、安卓的挖孔屏、普通的直板屏状态栏高度都不一样。正确拿法不是硬编码而是// utils/system.js const getNavBarInfo () { const systemInfo wx.getSystemInfoSync(); const menuButton wx.getMenuButtonBoundingClientRect(); const navBarHeight (menuButton.top - systemInfo.statusBarHeight) * 2 menuButton.height; return { statusBarHeight: systemInfo.statusBarHeight, navBarHeight: navBarHeight }; };getMenuButtonBoundingClientRect拿到的是胶囊按钮的位置用它反推导航栏高度比任何“设备型号判断”都靠谱。这个值在app.js的globalData里存一份所有页面在onLoad里读取然后动态设置自定义导航栏的padding-top。我见过很多团队在这里用wx.getSystemInfoSync().statusBarHeight 44在部分安卓机型上会露馅胶囊按钮和标题上下不对齐UI 看着就是“歪”的。4.2 商品列表加载更多分页的边界条件商品列表页是用户进来第一眼看到的东西它的核心逻辑是“滚动到底部加载下一页”。这个交互在onReachBottom里触发但要注意“防重入”——用户在快速滑动时onReachBottom可能在一秒内触发多次如果每次都发请求后端压力会翻几倍。我一般用一个isLoading开关// pages/goods/list.js 里的关键片段 Page({ data: { goodsList: [], page: 1, pageSize: 10, hasMore: true, isLoading: false }, onReachBottom() { if (!this.data.hasMore || this.data.isLoading) return; this.loadMore(); }, loadMore() { this.setData({ isLoading: true }); wx.request({ url: ${baseUrl}/api/goods/list, data: { page: this.data.page, size: this.data.pageSize }, success: (res) { const list res.data.data.records; this.setData({ goodsList: this.data.goodsList.concat(list), page: this.data.page 1, hasMore: list.length this.data.pageSize }); }, complete: () { this.setData({ isLoading: false }); } }); } });hasMore的判断是list.length this.data.pageSize如果返回的条数等于请求的条数说明大概率还有下一页如果小于就是最后一页了。这样比让后端返回totalPages更省事毕竟商品数量在滚动过程中可能被后台调整。注意concat一定是在原数组上追加不能setData整个覆盖否则用户滑快了会看到列表闪烁。4.3 购物车与结算勾选状态同步是个细节活购物车页面的勾选状态看似简单但要把“全选/取消全选/单选”的状态同步到结算按钮的“金额总和”上涉及多个setData的联动。我的做法是每次勾选变化时都重新计算一遍// 计算已选中的商品数量和金额 recalc() { const items this.data.cartItems; const checkedItems items.filter(i i.checked); const totalCount checkedItems.reduce((sum, i) sum i.quantity, 0); const totalAmount checkedItems.reduce((sum, i) sum i.quantity * i.price, 0); this.setData({ totalCount, totalAmount: totalAmount.toFixed(2) }); }这里的价格i.price要特别注意它是“加入购物车那一刻的商品快照价格”还是“实时从后端拉取的价格”我建议购物车列表接口每次进入页面时从后端拉取最新的price而不是把价格存死在cart表里。原因很简单商家改价之后用户购物车里的旧价格必须跟着变否则结算时前后端对不上客户投诉就来了。结算页的“价格计算”绝不能只用前端算出来的 totalAmount 提交给后端否则前端被改一下就能 1 分钱下单。正确做法是后端根据 order_item 里的商品 ID 重新从数据库查价格计算前端传过来的金额只做展示。5. 上线前排查五个高频坑与修复记录5.1 手机号快速验证组件的 code 只能换一次现象用户在 A 页面点“获取手机号”正常取消后再次点击后端报invalid code。原因微信手机号组件的code是“一次性”的无论换成功还是失败只要用过就失效。解决前端拿到code后立即传到后端不要做任何缓存后端换失败时提示用户“请重新点击授权”而不是让用户反复点同一个按钮。5.2 支付回调成功了但订单状态还是“待支付”现象用户支付成功小程序跳转到了“支付成功”页但订单列表里状态还是“待支付”。原因回调接口里只更新了订单状态没处理“幂等标记”或者回调接口返回给微信的不是字符串SUCCESS而是 JSON 数据微信以为回调失败会持续重试。解决回调接口用RestController返回String方法体里return SUCCESS同时看一眼微信支付商户平台的“交易记录”确认回调是否真的到达了你的服务器。排查支付类问题不要靠猜。先在后台日志里搜 notify_url 相关的请求记录看微信到底有没有调你的接口如果没调检查是不是证书过期或者回调地址被防火墙挡了如果调了报错把微信返回的 return_code 和 result_code 打出来看。5.3 JWT token 过期导致用户“莫名其妙的掉线”现象用户用着用着突然跳到登录页重新登录后购物车还在但首页需要重新加载。原因我给 JWT 设的过期时间是 2 小时用户逛商城超过 2 小时必然掉线。解决把 token 过期时间改成 7 天并在小程序端封装wx.request拦截器遇到 401 状态码时自动用wx.login的code静默重新换 token再重发原请求。注意这里不能用“刷新 token”方案——小程序没有安全的“刷新 token”存储位置静默换取是最实用的做法。5.4 小程序包体超过 2MB 导致真机预览失败现象代码本地跑得好好的传真机预览时报“代码包大小超过限制”。原因图片资源、第三方库、页面文件太多主包超过 2MB。解决把node_modules里体积大但只影响管理后台的库抽离到分包所有图片上传到 CDN本地只保留图标用“分包”加载需要强制开启主包只保留pages/index、pages/cart、pages/order其余页面放进subPackages并在app.json里声明。分包不是“上线前才做的事”。建议在项目第三天就把 app.json 的结构设计成“主包 分包”否则后期拆分成本极高——页面的相对路径全要改。5.5 并发下单导致库存变成负数现象秒杀活动时100 件商品卖出了 120 单库存变成 -20。原因UPDATE语句没有带stock #{quantity}条件。解决SQL 改成UPDATE goods SET stock stock - #{quantity} WHERE id #{goodsId} AND stock #{quantity}并对affected返回值做判断。这招是最基础的“乐观锁”方案对第一版商城完全够用如果以后并发量真的起来了再上 Redis 预扣库存方案但那是后话。6. 从能跑到扛得住缓存、索引与验收清单6.1 Redis 缓存不是上来就用的很多团队一上来就把商品列表缓存进 Redis结果后台改个价格前端半小时不生效运营直接炸毛。我的经验是第一版只缓存“首页轮播”和“商品详情页”这两个读多写少的数据而且缓存更新走“修改时删除缓存”的策略不是更新缓存。商品列表页保持实时查库因为列表页的排序、分页参数组合太多全缓存会导致 key 爆炸。等真的扛不住了再对“按分类 按销量排序”这几种固定场景做缓存缓存 key 一定要带版本号方便一次性失效。6.2 验证这套商城能不能上线三条硬指标第一用一个新微信号走完“首页 → 加购 → 下单 → 支付 → 退款”全流程注意观察支付回调有没有延迟超过 5 秒第二用压力和观测工具把商品列表接口压到 100 并发观测 MySQL 的 CPU 和慢查询数如果EXPLAIN里出现filesort或typeALL就赶紧加索引第三把手机网络切到 4G 弱网环境打开小程序看首屏图片是否快速占位这能暴露图片体积和接口超时设置的问题。我在自己的项目里就是这么验收的那次的教训是真机上一切正常不代表弱网正常商城首屏图片必须做 WebP 或压缩处理否则用户在电梯里只能盯着白屏干瞪眼。小程序商城的迭代速度比传统电商快得多我的习惯是每次发版前都让测试同事用“最新版本微信”跑一遍支付流程——微信偶尔会调整授权组件的返回值上一版好好的代码下一版可能就报code invalid。这种“玄学”问题别慌先看官方更新日志再回来查自己的逻辑九成是适配问题。希望这篇笔记能帮你在做商城这件事上少走几步弯路仓库里那些好用的工具类记得留给下一个项目。本文还有配套的精品资源点击获取