用 Java 给汽车用品商城做微信小程序后端，这些坑我替你先踩了

作为一个既写过电商系统、又折腾过微信小程序的老开发，我必须说一句：汽车用品这个品类做小程序商城，比做普通服装鞋帽要麻烦得多。原因很简单——配件型号、适用车型、商品规格的组合关系太复杂了。一个机油滤芯，可能同时适配十几个车型，每个车型的年份、排量、发动机型号都得对上，这种数据模型设计不好，后面维护起来能让你怀疑人生。

这篇文章就从我在开发"基于微信小程序的汽车用品销售商城系统"（Java 后端）过程中的实际经验出发，把整体架构、核心功能拆解、技术选型思路、踩坑记录、性能优化这些内容一次性讲透。内容偏实战，代码示例尽量精简但可运行，适合有一定 Java 基础和微信小程序开发经验的读者，也适合准备做类似电商类校园项目、毕业设计或小型创业项目的人参考。

1. 为什么是"Java + 微信小程序"来做汽车用品商城

1.1 汽车用品赛道的特点决定了技术选型

汽车用品商城和普通电商最大的不同，在于它的"非标品"属性极强。以汽车脚垫为例，同一款车不同年份可能脚垫版型就不一样；以雨刮器为例，同一品牌下面分U型口、燕尾式、直插式，每种接口适配的车型天差地别。这就导致商品不能简单地用"标题 + 图片 + 价格"来承载，必须在商品详情里明确标注适配车型、年份、排量、接口类型等结构化信息。

这种场景下，小程序商城反而比 H5 有天然优势。微信小程序的生态里，用户不需要下载 App，用完即走，对于"我车缺个东西、搜一下、下单、收货"这种低频但刚需的购物行为特别契合。而 Java 后端的选择则是冲着稳定性和生态去的：Spring Boot + MyBatis Plus 这套组合在电商领域的实践案例太多太多了，支付对接、订单管理、库存扣减这些问题都有成熟的解决方案可以参考，不会你一个人在前面开路。

1.2 技术栈选型的几个关键决策

当时的选型思路可以整理成一张表，有同样需求的朋友可以直接参考：

后端我没有选择更重的 Spring Cloud 微服务体系，原因很简单：汽车用品商城的初期流量规模，单体应用完全能扛住，微服务只会增加部署和运维成本。如果你的项目后续要做多商户入驻、库存拆到多个仓库，再考虑拆分也不迟。项目起步阶段，单体架构 + 合理的模块划分，是性价比最高的选择。

1.3 项目整体架构与模块划分

这个系统的整体数据流向是这样的：微信小程序端通过 wx.request 访问后端 API，Nginx 做反向代理和控制 HTTPS 证书，请求到达 Spring Boot 服务的 Controller 层，经过拦截器做登录态校验，然后走 Service 层处理业务逻辑，DAO 层通过 MyBatis Plus 操作 MySQL，热点数据走 Redis 缓存，图片和文件上传到对象存储服务，支付和退款调用微信支付 API。

模块划分上，我建议按业务域拆分 packages，而不是按技术层拆分。也就是说，不要搞出 controller 包下面一堆类、service 包下面一堆类的老式结构，而是按"用户域、商品域、订单域、购物车域、支付域"来分包，每个域内部再分 controller/service/mapper。这样改起来思路非常清晰，找一个功能时不用在几个大包里翻半天。

2. 小程序端的核心功能拆解与实现

2.1 微信登录态处理：从 wx.login 到 session 管理

这是所有小程序项目的第一个坎，也是网上问得最多的一个问题："小程序获取登录后的微信用户失败"。说实话，这个报错 90% 的情况不是微信接口的问题，而是登录态设计得不对。

正常的登录流程应该是这样：

1. 小程序端调用 wx.login()，获取一个临时 code。
2. 把这个 code 通过后端接口传给自己的服务器。
3. 后端拿着 code 调用微信的 jscode2session 接口，换区 openid 和 session_key。
4. 后端用 openid 查自己的用户表，如果用户不存在则自动注册一个新用户。
5. 后端生成一个自定义登录态 token（例如 UUID），存到 Redis 里，设置过期时间，返回给小程序端。
6. 小程序端拿到 token 后存到 storage 里，后续所有请求都在 header 里带上这个 token。

最容易出问题的地方在第 5 步。很多新手把 openid 直接返回给前端，让前端每次请求都把 openid 传上来，这既不安全，也容易因为 openid 获取失败导致整个登录流程崩掉。我强烈建议用 token 方案，openid 永远只存在于后端会话中。

这里给一段后端获取 openid 的核心代码，用的是 hutool 的 HttpUtil，省去一堆模板代码：

java复制public String wxLogin(String code) {
    String url = "https://api.weixin.qq.com/sns/jscode2session?appid="
            + appId + "&secret=" + appSecret
            + "&js_code=" + code + "&grant_type=authorization_code";
    String result = HttpUtil.get(url);
    JSONObject jsonObject = JSONUtil.parseObj(result);
    String openid = jsonObject.getStr("openid");
    if (StrUtil.isBlank(openid)) {
        // 记录错误码和错误信息，通常是 appid/secret 不对，或 code 过期
        throw new BizException("微信登录失败：" + jsonObject);
    }
    // 查用户表，不存在则注册
    // 生成 token，存 Redis，设置 7 天过期
    return token;
}

2.2 商品列表、分类与搜索页面的数据渲染

汽车用品的分类层级一般比较深，比如"保养配件 > 机油 > 全合成机油 > 5W-30"，所以小程序端的分类页不能做成简单的两列，我建议做成左侧一级分类、右侧二级分类和商品列表的联动布局。右侧需要用到 scroll-view 的滚动监听，每个分类项对应一组商品。

商品列表的渲染有两个值得注意的点：

第一，图片一定要用官方提供的 image 组件的 lazy-load 属性。汽车用品图片多且大，不懒加载的话页面滚动会明显卡顿。

第二，价格显示不能直接渲染数据库里的分单位整数，你得在小程序端做一次除以 100 的转换，或者后端直接返回格式化后的字符串。建议后端返回以"分"为单位的整数，前端负责展示格式化，这样避免浮点数精度问题。

分类和搜索我做了同一个接口。小程序端通过请求参数区分场景，比如 type=category 时传 categoryId，type=search 时传 keyword。后端统一走一个商品查询服务，只是多拼接一个查询条件。

java复制public PageResult<ProductVO> queryProductPage(ProductQuery query) {
    LambdaQueryWrapper<Product> wrapper = new LambdaQueryWrapper<>();
    if (StrUtil.isNotBlank(query.getKeyword())) {
        wrapper.like(Product::getName, query.getKeyword())
               .or().like(Product::getBrand, query.getKeyword());
    }
    if (query.getCategoryId() != null) {
        wrapper.eq(Product::getCategoryId, query.getCategoryId());
    }
    if (query.getMinPrice() != null) {
        wrapper.ge(Product::getPrice, query.getMinPrice());
    }
    if (query.getMaxPrice() != null) {
        wrapper.le(Product::getPrice, query.getMaxPrice());
    }
    wrapper.orderByDesc(Product::getCreateTime);
    // 分页查询，返回给前端
}

2.3 购物车与下单流程的本地状态设计

购物车这里有一个常见的设计误区：每个操作都调后端接口。加入购物车、修改数量、勾选、取消勾选，全都请求一次后端，不仅慢，而且容易产生大量无效请求。我的做法是：购物车数据在小程序本地存储（storage）中维护一份，每次变更操作都先更新本地，再异步同步到后端。

为什么可以这么做？因为购物车本身不是强一致性的数据，它只是一个"预下单"状态的容器。真正需要严格校验的是下单那一刻，包括库存检查、价格检查、商品上下架状态检查。所以购物车数据可以先放本地，下单时再一次性提交给后端计算。

这里要特别提醒：后端下单接口必须重新计算价格，绝对不能信任前端传过来的金额。 我在设计下单接口时，前端只传 skuId 列表和数量，后端自己查库计算总价，再把商品信息快照存到订单里。这样做的好处是，即使前端被篡改，或者商品价格调整了，订单金额依然准确。

小程序端购物车存储的数据结构我建议长这样：

json复制{
  "items": [
    {
      "skuId": 1001,
      "productName": "博世机油滤清器",
      "spec": "适用丰田卡罗拉 2014-2018款",
      "price": 4590,
      "count": 1,
      "checked": true,
      "imageUrl": "https://..."
    }
  ],
  "updateTime": 1700000000000
}

2.4 支付接入与订单状态流转

微信支付接入流程本身不复杂，复杂的是各种边界情况。先理清订单的状态机，我这边设计的订单状态包括：待付款（0）、待发货（1）、待收货（2）、已完成（3）、已取消（4）、退款中（5）、已退款（6）。

支付流程是这样的：小程序端先调用后端的"创建订单"接口，后端生成订单记录，状态设为待付款，同时返回一个订单号；然后后端调用微信支付的"统一下单"接口，拿到 prepay_id，再签名生成小程序端所需的支付参数，返回给前端；前端拿到参数后调用 wx.requestPayment 拉起支付。

这里有一个必须注意的细节：支付结果不能只依赖前端回调的 success，必须以微信服务器的支付回调通知为准。也就是说，后端需要提供一个 notify_url，微信支付服务器在用户支付成功后，会向这个地址发送 POST 通知。收到通知后，后端要验证签名、核对订单金额、检查订单状态，全部无误才把订单状态改为待发货，然后返回"SUCCESS"字符串给微信服务器。

我在第一次做支付回调时踩过一个挺隐蔽的坑：微信支付的回调通知可能会发送多次，如果没有做幂等处理，就会出现重复发货的情况。解决办法是在回调里先查订单状态，如果已经是"待发货"，直接返回成功，不再走一遍更新逻辑。

3. Java 后端的关键设计与编码细节

3.1 Spring Boot 工程结构与分层规范

实际开发中，工程结构我推荐按下面这种方式组织，既清晰又没有过度设计：

code复制com.carmall
├── common          // 通用工具、常量、异常、统一返回体
├── config          // 配置类：Redis、MyBatis、Swagger、拦截器注册
├── controller      // 接口层，只做参数接收和结果返回
├── service         // 业务层，核心逻辑
│   └── impl
├── mapper          // MyBatis Plus 的 Mapper 接口
├── entity          // 数据库实体
├── vo              // 视图对象，返回给前端的数据结构
├── dto             // 数据传输对象，接收前端参数
└── interceptor     // 登录拦截器

分层核心原则是：Controller 不写业务逻辑，Service 不出现 HttpServletRequest 之类的 Web 层对象。特别是登录用户的获取，我封装了一个 UserContext 工具类，通过 ThreadLocal 存储当前登录用户 ID，任何地方想拿当前用户直接调用 UserContext.getUserId() 就行。拦截器在请求进入 Controller 前解析 token，把用户信息放到 ThreadLocal 里，请求结束后必须清理，否则 Tomcat 线程池复用线程时会出现数据串号的问题——这个问题非常隐蔽，查起来能让人崩溃。

3.2 数据库表设计与商品 SKU 模型

汽车用品商城的数据表设计，最核心的是商品表、SKU 表和适配车型表这三张。

商品表（product）存的是公共信息：商品名称、品牌、主图、详情描述、是否上架、销量、创建时间等。

SKU 表（product_sku）存的是销售单元信息：规格名称、价格、库存、SKU 图片、条形码等。比如一个"全合成机油 5W-30"的商品，可能有"单瓶装"和"整箱装（6瓶）"两个 SKU，价格和库存都不同。

适配车型表（product_vehicle）存的是商品适用的车型信息：品牌、车系、年款、排量、发动机型号等。一张表和商品是多对多关系，一个商品适配多个车型，一个车型对应多个商品。

我当时踩过的坑是：把车型信息直接塞在商品表的备注字段里，导致用户搜索"卡罗拉"时完全匹配不到商品。后来单独拆了这张表，并在车型名称字段上建立了全文索引，搜索问题才解决。如果你是用 MySQL 8.0，可以直接用内置的全文索引，效果比 LIKE '%keyword%' 好太多。

3.3 拦截器、统一返回体与异常处理

一个健康的后端项目，必须从一开始就建立统一返回体。我定义的返回结构是：

json复制{
  "code": 200,
  "message": "success",
  "data": {}
}

前端拿到响应后，先判断 code 是否等于 200，再决定是否读取 data。这样做的好处是，不管接口是正常返回还是业务异常，前端处理逻辑都是统一的，不用每次写一堆 try-catch。

拦截器部分，需要区分哪些接口需要登录、哪些接口可以匿名访问。我的做法是给不需要登录的接口单独维护一个白名单列表，比如登录接口、商品分类接口、商品列表接口、首页 banner 接口。拦截器在 preHandle 里判断请求路径是否在白名单里，不在的话就解析 token；token 解析失败直接返回 401 响应。

这里给出一段核心的拦截器逻辑示意：

java复制public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
    if (isWhiteList(request.getRequestURI())) {
        return true;
    }
    String token = request.getHeader("Authorization");
    if (StrUtil.isBlank(token)) {
        writeUnauthorized(response);
        return false;
    }
    Long userId = redisUtil.get("login:token:" + token);
    if (userId == null) {
        writeUnauthorized(response);
        return false;
    }
    UserContext.set(userId);
    return true;
}

public void afterCompletion(...) {
    UserContext.clear();
}

所有异常不要直接让 Spring Boot 默认的报错页面返回给前端，应该用 @RestControllerAdvice 做全局异常处理。业务异常（BizException）返回 code 500 + 错误信息；参数校验异常返回 code 400 + 具体字段错误；未预期的异常则统一返回"系统繁忙"并打印完整堆栈到日志里。

3.4 会话保持：Redis 缓存与 Token 方案

前面提到了 token 方案，这里把细节讲透。

token 的生成我用的不是简单的 UUID，而是 UUID + 用户ID + 时间戳的组合，再做一次不可逆的哈希处理。虽然 UUID 本身已经很难碰撞，但在日志里如果打印了 token，恶意用户拿到 UUID 后也无法直接关联到用户。Redis 的 key 设计为 login:token:{token}，value 存 userId，过期时间设置为 7 天，小程序端每次请求如果距过期时间不足 1 天就自动续期，用户就不用频繁重新登录。

商品详情页的数据也做了 Redis 缓存。商品信息变化频率低、读取频率高，非常适合缓存。我采用的策略是 cache-aside 模式：请求商品详情时先查 Redis，查不到再去查 MySQL，同时把数据写入 Redis 并设置过期时间；后台修改商品时，先更新数据库，再删除 Redis 里的对应缓存。这种模式实现简单，也没有缓存雪崩的风险。需要注意，不能只设置缓存不设置过期时间，否则商品数据永久停留在第一次缓存的状态，后台改价后前端永远看到旧价格。

4. 开发和部署中踩过的坑

4.1 登录失败：开发者工具正常、真机却报错

这个问题的场景非常典型：开发者工具里一切正常，一点"预览"，手机打开小程序后登录直接就失败了，报错往往是"获取登录后的微信用户失败"。

排查链路的第一次检查，应该是 request 合法域名。微信小程序真机环境对网络请求的域名有严格限制：必须在小程序管理后台配置 request 合法域名，且域名必须为 HTTPS、已备案。开发者工具默认勾选了"不校验合法域名"，所以工具里能跑通，真机就跑不通。

如果你已经配置了合法域名，但依然失败，那就要检查 Nginx 的配置了。我当时遇到的情况是证书配置给了主域名，但接口请求用的是带端口的 URL（比如 https://api.example.com:8080），部分手机和微信版本的网络请求库对带端口的 HTTPS 请求支持不友好。解决办法很简单：Nginx 监听 443 端口，把 /api 路径反向代理到后端的 8080 服务，小程序请求统一用不带端口的地址。

还有一种情况，就是 code2session 接口不稳定，或者你把 code 错误地进行了二次使用。微信的 code 是一次性的，用过后立即失效。如果因为网络超时，前端自动重试时又把同一个 code 发了一遍，后端第二次拿着旧 code 去换 openid，微信会返回错误码 40029。所以前端一定要避免重复发送同一个 code。

4.2 Java 17 编译警告与 Lombok 兼容问题

如果你像我一样用的是新版 JDK 17，大概率会遇到两个问题。第一个是 Maven 或 Gradle 编译时报"源发行版 17 需要目标发行版 17"，这个是说编译器检测到源代码使用了 Java 17 的语法特性，但 maven-compiler-plugin 的 source/target 没有设置为 17。解决方式是在 pom.xml 里统一配置：

xml复制<properties>
    <java.version>17</java.version>
    <maven.compiler.source>17</maven.compiler.source>
    <maven.compiler.target>17</maven.compiler.target>
</properties>

第二个是 Lombok 的问题。旧版 Lombok 依赖库对 Java 17 的兼容性不好，启动项目时会直接报错"you aren't using a compiler supported by lombok, so lombok will not work"。我一开始以为是 IDE 的注解处理器配置问题，折腾了半天，最后发现是 Lombok 版本太老。将 Lombok 依赖升级到 1.18.30 以上就正常了。

这里也提醒一句：能用 record 或者普通构造器解决的数据类，别为了省事强上 Lombok。在 Java 17 项目里，Lombok 的注解处理机制和现代的编译流程配合起来偶尔会有延迟问题，尤其多人协作时，每个人的 IDE 配置不一致，Lombok 生成的 getter/setter 偶尔会出现找不到的诡异报错，重启一下 IDE 又好，但很打断节奏。

4.3 内存溢出：图片上传导致的 OutOfMemoryError

项目的商品管理后台支持管理员上传商品图片，我第一次实现时用的是 Spring Boot 默认的 MultipartFile 接收文件，然后直接 bytes 数组转存。结果运营同事一次上传了十几张高清图，后端直接报了 java.lang.OutOfMemoryError: Insufficient memory，这是典型的堆内存被大文件撑爆了。

排查思路其实很清楚：先看一下上传接口，Spring Boot 的默认单次请求大小上限是 1MB，通过配置文件可以调大，但不管你调多大，直接把整个文件读入内存的处理方式就是有风险的。大文件或者多文件并发上传时，堆内存必然扛不住。

正确解法是先把文件存到临时目录，再以流式方式从临时目录上传到对象存储。同时在前端限制图片大小和格式，我在小程序端和后台管理页面都做了压缩处理：图片宽度超过 1200px 就等比压缩，质量压缩到 80% 以下，体积通常能压缩到原来的三分之一。这样不仅后端不会 OOM，用户浏览商品列表时的加载速度也会快很多。

4.4 真机测试 net::ERR_CONNECTION_RESET 的排查链路

小程序真机测试时遇到 net::ERR_CONNECTION_RESET，这绝对是新手最容易懵的报错之一。它的特点是：开发者工具一切正常，手机上偶尔能打开、偶尔打不开，或者图片加载一半就失败。

我先说结论：这个报错 80% 是后端因为某种原因主动断开了连接，最常见的有三种情况。

第一种是后端接口响应时间过长，超过了 Nginx 的 proxy_read_timeout。我遇到过商品详情页有个接口要查商品信息、SKU 列表、适配车型列表、评价列表，在数据量大的时候拼装耗时超过 60 秒，Nginx 等不及直接断连。解决方式是优化 SQL、加缓存、拆接口，前端改为并行请求后再合并数据。

第二种是服务器安全组或防火墙封禁了异常行为。比如小程序真机在短时间内频繁请求接口，触发了服务器的 fail2ban 规则，把客户端 IP 临时封了。这种排查方法是在服务器上查看 Nginx 的错误日志和系统安全日志，如果看到 banned 关键词，基本可以确认就是这个问题。

第三种是微信小程序的网络环境切换导致的。用户的手机在 Wi-Fi 和 4G/5G 之间切换时，TCP 长连接会断掉，但如果前端没有正确处理这个错误，页面就会一直卡在加载状态。解决办法是在小程序的网络请求封装里统一监听网络状态变化，重发失败请求，同时给用户一个友好的重试提示。

4.5 小程序分包与导航栏高度适配

汽车用品商城的商品详情页往往包含大量图片，加上首页、分类页、购物车、结算页、个人中心这些页面，首次加载的包体很容易超过微信小程序 2MB 的限制。

解决办法就是使用分包加载。我把结算流程相关的页面（订单确认页、支付结果页、订单列表页、订单详情页）放到了 orderPackage 分包里，把商品评价相关页面放到了 reviewPackage 分包里。用户只有真正进入这些页面时，微信才会加载对应分包的代码。

分包还有一个异步化的特性——在其它分包中的插件、自定义组件、图片资源，可以通过分包异步化按需加载，避免主包体积膨胀。我当时用这个特性把一些非首屏需要的组件（比如优惠券弹窗组件）放到了分包里，主包体积明显减下去了。

导航栏高度适配则是所有小程序开发者都会遇到的基础问题：iPhone 的刘海屏、状态栏高度和 Android 手机完全不同。不要写死导航栏高度，应该用 wx.getWindowInfo() 获取 statusBarHeight，再根据胶囊按钮的位置动态计算导航栏高度。我封装了一个工具方法，在 App.onLaunch 时获取一次，放在全局数据里，所有页面直接引用。

javascript复制const { statusBarHeight } = wx.getWindowInfo();
const menuButtonInfo = wx.getMenuButtonBoundingClientRect();
const navBarHeight = (menuButtonInfo.top - statusBarHeight) * 2 + menuButtonInfo.height;

5. 上线前的细节打磨与性能优化

5.1 支付回调的幂等处理

前面提到了支付回调的幂等，这里再展开讲讲。微信支付官方文档明确说明：同一条支付通知可能多次发送，并且通知频率会递增（15s/15s/30s/180s/180s/300s/600s...）。

如果不做幂等，可能出现的问题不仅仅是重复发货，更严重的还有重复发优惠券、重复加积分。我的做法是：在订单表上加一个 payment_notify_id 字段，回调处理时先通过这个字段判断是否已经处理过；同时用 Redis 的 SETNX 命令做分布式锁，确保并发场景下同一个订单不会被两个线程同时处理。

java复制boolean locked = redisUtil.setIfAbsent("pay:notify:" + orderNo, "1", 60);
if (!locked) {
    return "SUCCESS";
}

5.2 首页加载速度优化

首页是用户进入小程序后的第一个页面，加载速度直接影响跳出率。汽车用品商城的首页通常会包含 banner 轮播、热销商品、新品上市、品牌专区等模块，每个模块都需要不同的数据。如果按顺序逐个请求接口，用户会明显感觉到白屏时间。

我的优化方案是后端做了聚合接口：首页数据一次性从 Redis 缓存中读取，Redis 中没有或缓存过期，才去数据库查询各模块数据并组装。聚合接口的数据结构如下：

json复制{
  "banners": [],
  "hotProducts": [],
  "newProducts": [],
  "recommendCategories": []
}

Redis 缓存时间设置为 5 分钟，后台运营修改首页展示内容后，可以一键刷新缓存。小程序端用骨架屏组件代替 loading 动画，让用户在数据加载完成前就看到页面布局，体验提升非常明显。

5.3 消息推送：订阅消息 vs 客服消息

商场系统需要给用户发消息的场景不少：订单发货通知、物流状态更新、优惠活动提醒。小程序的消息推送有两个方案，我的实践结论是：正式业务通知用订阅消息，营销内容用客服消息或模板消息（注意模板消息已于 2020 年下线，现在是订阅消息一统天下）。

订阅消息有一个关键限制：用户主动订阅后才能推送，且一次性订阅消息，用户每授权一次，只能推送一条。这意味着你不能在用户下单后偷偷给他连续推三个消息。我的做法是：在关键节点（比如下单成功后）弹出订阅授权请求，让用户一次勾选"订单发货提醒"和"活动通知"两项，这样就能合法地发送两条订阅消息。

后端推送消息时，需要先获取 access_token，再调用 subscribe/send 接口。access_token 的有效期是 7200 秒，注意做缓存，别每次都重新获取。这些逻辑通常在 Spring Boot 里通过定时任务 + 消息队列实现，比如订单发货后，推送任务进入 MQ 队列，消费者消费后调用微信接口推送。

5.4 UpdateManager 版本更新管理

小程序发布新版本后，用户端不会立即更新，如果后端配合新版本上线了不兼容的接口，老版本用户会白屏。这时候就需要用 UpdateManager 主动检查版本并提示用户重启小程序。

在 app.js 的 onLaunch 里加入这段逻辑，是每个小程序项目的标配：

javascript复制const updateManager = wx.getUpdateManager();
updateManager.onUpdateReady(function () {
  wx.showModal({
    title: '更新提示',
    content: '新版本已经准备好，是否重启应用？',
    success(res) {
      if (res.confirm) {
        updateManager.applyUpdate();
      }
    }
  });
});

我还做了灰度发布策略：后端接口保持向前兼容，新接口上线后旧接口保留一段时间，等新版小程序覆盖率达到一定程度再下线旧接口。在微信公众平台后台可以看到小程序的版本覆盖率数据，这个数据能帮你判断下线旧接口的时机。

实际操作中的几点体会

整个项目从零开发到上线，前前后后花了大约两个月时间，其中大约三分之一的时间花在支付对接和真机调试上。如果你也在做类似的项目，我有几条建议送给你们。

第一，先跑通最小闭环再完善功能。不要一开始就想着把商品评价、优惠券、积分系统全部做完。先把"浏览商品 → 加入购物车 → 提交订单 → 微信支付 → 发货 → 确认收货"这条主链路跑通，再往上面加花活。主链路通了，项目的核心价值就立住了。

第二，一定要用真机做全流程测试。开发者工具和真机的差异远比想象的大，包括网络请求、缓存机制、登录态、地图组件、支付流程。我在开发过程中遇到的绝大多数坑，都是真机测试时暴露出来的。

第三，日志系统要提前设计好。我用的 logback + 按天滚动文件，同时也接了一部分日志到腾讯云日志服务，但哪怕是简单的文件日志，只要格式规范、包含请求路径、耗时、用户ID、异常堆栈，排查问题就足够用了。最怕的是日志里有吞掉的异常，排查线上问题时两眼一抹黑。

第四，数据库字段的注释一定要写清楚。汽车用品的 SKU 模型很复杂，不要指望你自己三个月后还能记得 status 字段的 0、1、2 分别代表什么。现在偷的懒，都是后面干活时流的泪。

做商城系统的过程，本质上就是在"复杂业务"和"用户体验"之间找平衡。Java 后端给了你足够的稳定性和生态支持，微信小程序给了你最低的触达成本，两者结合，做一个小而美的汽车用品垂直商城，是完全可行且值得投入的方向。希望这篇实战分享能给你省下一些本该踩的坑。