企业官网建设流程全解析

简介：这是一份基于 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表里必须有status（0 待支付、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 Result<IPage<Goods>> 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传成 10000，MySQL 的LIMIT会把数据库拖垮；二是categoryId用了包装类型Long，而不是基本类型long，这样前端不传这个参数时它才是null，否则会报参数缺失错误。我在项目里看到过太多因为这里用long导致前端必须传categoryId=0才能调通的接口，纯属没必要。

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 Result<String> 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搭配connectTimeout=3000, readTimeout=5000，因为微信服务器偶尔会抖动，如果后端同步等待太久，小程序端就会转圈卡死。第二，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 LambdaQueryWrapper<Cart>() .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 下架，商品列表接口默认只查 `status=0`。

3.3 下单与支付回调：库存预占和幂等处理

下单接口是整个商城的核心，也是最容易“翻车”的地方。一个合格的下单接口要依次做：参数校验 → 库存预占 → 生成订单 → 返回支付参数。库存预占不是UPDATE goods SET stock = stock - 1就完事，而是必须加上“库存足够”的条件：

@Transactional(rollbackFor = Exception.class) public Order createOrder(Long userId, List<CartItem> items) { for (CartItem item : items) { // 乐观锁扣减库存：affected=0 说明库存不足或商品被并发改过 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 = 0，affected == 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或type=ALL就赶紧加索引；第三，把手机网络切到 4G 弱网环境，打开小程序看首屏图片是否快速占位，这能暴露图片体积和接口超时设置的问题。我在自己的项目里就是这么验收的，那次的教训是：真机上一切正常不代表弱网正常，商城首屏图片必须做 WebP 或压缩处理，否则用户在电梯里只能盯着白屏干瞪眼。

小程序商城的迭代速度比传统电商快得多，我的习惯是每次发版前，都让测试同事用“最新版本微信”跑一遍支付流程——微信偶尔会调整授权组件的返回值，上一版好好的代码，下一版可能就报code invalid。这种“玄学”问题别慌，先看官方更新日志，再回来查自己的逻辑，九成是适配问题。希望这篇笔记能帮你在做商城这件事上少走几步弯路，仓库里那些好用的工具类，记得留给下一个项目。

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