Spring Boot + 微信小程序宠物商城：从登录到支付全流程实战解析

做了几年Spring Boot后端，最近一直在折腾微信小程序端的电商类项目，手头正好有一套宠物用品销售小程序的完整源码，编号86805。这个项目麻雀虽小五脏俱全，用户端加管理端该有的模块全都有，代码也不绕弯子，很适合刚接触前后端分离开发的初学者当活教材，同时也是个能直接用起来的毕业设计级模板。

整套东西跑起来之后，就是一个典型的“Spring Boot + 微信小程序”商城闭环。用户在小程序里浏览分类、搜索商品、加购物车、下订单、微信支付，管理员在后台维护商品、处理订单、看统计数据。下面从设计思路到具体实现，再到部署上线踩过的坑，按我的实际操作顺序完整拆一遍。

1. 项目全貌：一个宠物用品商城小程序到底有哪些功能

1.1 用户端功能拆解

小程序端的用户操作路径，说白了两条主线，一条是“逛”的链路，另一条是“买”的链路，这两条链路基本决定了用户端所有页面和接口的走向。

逛的链路包含首页、分类页、搜索、商品详情。宠物用品这个品类有个特点，用户的浏览习惯非常聚焦，要么直接搜猫粮狗粮，要么按“猫主子”“狗主子”分类翻，很少漫无目的地逛。所以首页我做了三个入口：顶部搜索框、banner轮播图、下方金刚区分类图标，这样低频决策用户能快速直达，高频复购用户也能顺着分类找到目标商品。

买的链路是加购物车、确认订单、支付、查看订单状态。宠物粮这类商品复购率很高，很多用户是定期补货，所以购物车模块做得顺手特别重要。这个小程序在购物车里做了规格记忆，同一个商品选了不同规格会分成不同的购物车条目，避免用户每次来都要重新选口味和重量。

详情页里除了常规的商品图、价格、库存、销量，还单独加了宠物适龄提示和喂养建议字段。这不是我拍脑袋加的，宠物用品行业就吃这一套，买家下单前一定会确认这个粮幼猫能不能吃、成犬合不合适，页面上直接写清楚能减少大量售前咨询。

1.2 管理端功能拆解

管理端这边没有单独做App或者复杂的PC端，直接嵌在Spring Boot项目里，用经典的管理员页面来实现，好处是部署省事，一个应用全搞定。管理端的核心模块是这几个：

商品管理是最基本也是用得最多的。录入商品时要设置分类、标题、主图、详情图、价格、库存、销量基数、上下架状态，还要处理规格，比如2kg装和10kg装是同一个SPU下的两个SKU，价格和库存都不一样。

订单管理承担了状态流转和发货操作。订单列表支持按订单号、用户、状态多维筛选，核心操作是两个：发货、退款。宠物用品这种标品为主的类目，售后率不算高，但退款流程必须走通，尤其是“已付款未发货”场景下的极速退款。

用户管理就是查看用户列表和用户详情，能看到用户的基本信息、注册时间、累计消费金额。对于个人开发者来说，用户数据量不大，没必要上太复杂的用户分层体系，但累计消费金额这个字段可以给后续做会员体系留一个扩展入口。

数据统计是管理端最有价值的部分。宠物用品销售有个明显规律，促销节点和换季期间销量波动很大。我在这套系统里做了销售额趋势、热销商品TOP10、分类占比三个维度。其中热销商品TOP10这个报表直接接在订单明细表上实时统计，上架新品后每天扫一眼这个榜，就能快速判断哪些品值得补库存，哪些品需要调整促销策略。

2. 技术选型与整体架构：为什么是Spring Boot加小程序

2.1 这套组合解决了什么问题

先说结论：Spring Boot加微信小程序这套组合，是目前个人开发者和中小团队做电商类小程序最稳、成本最低、生态最成熟的选择，没有之一。

后端选Spring Boot，核心原因是它把SSM时代那一堆繁琐的XML配置全部干掉，嵌入式的Tomcat让打包部署变成一条java -jar命令的事。这个项目涉及MySQL数据库交互、Redis缓存、微信支付对接、文件上传下载，Spring Boot的starter机制一拉即用，写起来干脆利落。

小程序端选微信原生开发，主要是为了稳。现在很多项目喜欢用uni-app这类跨端框架，一套代码多端编译。但如果你只做微信小程序，原生开发反而是最可控的，不会出现编译后样式错乱、原生组件兼容性差这类问题，而且小程序开发者工具的调试体验比跨端框架的H5调试模式顺手很多。

另外，微信小程序自带天然的流量分发场景。用户搜索“猫粮”“宠物用品”这类关键词时，小程序能在搜索结果里直接露出，这对宠物用品这类垂直类目来说，是一个低成本获客入口。相比之下，单独做一个H5商城，用户还得先打开浏览器再输入网址，中间流失率高太多了。

2.2 关键依赖与版本选择

版本这个问题吃过亏，所以特意拿出来说一下。Spring Boot版本不是越高越好，尤其是对新手来说，版本太高反而容易踩坑。

我在这套项目里用的是Spring Boot 2.7.x，搭配JDK 1.8。为什么不用Spring Boot 3.x？因为Spring Boot 3.0强制要求JDK 17，而且底层从javax包切到了jakarta包，很多老教程和老代码直接跑不起来。对于一个小程序商城这种体量的项目，2.7和3.x在功能上几乎没有差别，但2.7的生态兼容性明显更好，遇到问题搜索解决方案时，一大半结果都是针对2.x的，照着改就行。

下面是这套项目用到的核心依赖清单：

这里多说一句为什么引入Hutool。微信支付v3的对接过程中，要生成HTTP请求、处理敏感信息加解密、计算签名，这些操作用原生代码写工程量很大而且容易出错，Hutool把很多通用逻辑封装好了，在自己的ServiceImpl里组合调用就行。

2.3 项目目录结构与分层思路

这套项目采用标准的单体分层架构，controller、service、mapper三层，目录结构很清晰，拿到源码后第一眼就能看明白。

项目顶层模块是pet-shop，下面按功能分包。config包下放全局配置类，包括WebMvc拦截器注册、Redis序列化配置、微信支付配置类。controller包按业务域拆分，有AuthController、ProductController、CartController、OrderController、AdminController。service包和service.impl包放接口和实现，这是业务逻辑集中地。mapper包放MyBatis Plus的Mapper接口，SQL注解都写在接口里。entity包里是对应数据库表的实体类，用Lombok的@Data注解省掉getter/setter的重复代码。

分层是Spring Boot项目的默认规约，但我要强调一点：不要让Controller直接操作Mapper。有些新手为了图省事，直接在Controller里注入Mapper开始写SQL，短期内页面能跑通，但后续一旦要加业务逻辑，比如下单时要扣库存、生成订单号、创建支付单，这些操作如果散落在Controller里，代码会变得完全没法维护。按规范走，Controller只做参数接收和结果封装，业务逻辑全部塞进Service层，这是这套源码最值得新手学习的地方。

3. 核心链路实操：从登录到支付全流程

3.1 微信登录与Token体系：3步完成联调

微信小程序的登录机制，和传统网页登录差别很大，核心原因是小程序没有浏览器那种天然的Cookie机制，而且不允许前端直接拿到用户的身份信息。

标准流程分三步，后端都封装好了：

第一步，小程序端调用wx.login()获取一个临时凭证code，这个code有效期只有5分钟，并且只能使用一次。

第二步，小程序把code通过请求传到后端，后端用这个code调用微信的jscode2session接口，换取openid和session_key。openid就是用户在微信生态里面对这个小程序的唯一标识。

第三步，后端拿到openid后查数据库，如果用户不存在就自动注册一个新账号；然后生成一个自定义token字符串返回给前端。前端把token存放在storage里，后续所有需要登录态的请求都在请求头里带着token。

核心代码大概是这样：

java复制@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 = HttpUtil.get(url);
    JSONObject json = JSONUtil.parseObj(result);
    String openid = json.getStr("openid");
    
    // 2. 查询或注册用户
    User user = userMapper.selectOne(new LambdaQueryWrapper<User>()
        .eq(User::getOpenid, openid));
    if (user == null) {
        user = new User();
        user.setOpenid(openid);
        user.setNickname("微信用户" + openid.substring(openid.length() - 6));
        user.setAvatar("默认头像URL");
        user.setCreateTime(LocalDateTime.now());
        userMapper.insert(user);
    }
    
    // 3. 生成token
    String token = UUID.randomUUID().toString().replace("-", "");
    redisTemplate.opsForValue().set("login:token:" + token, 
        user.getId().toString(), 7, TimeUnit.DAYS);
    
    return Result.ok(new LoginResponse(token, user));
}

这里要提醒几个容易出问题的点。第一，调用jscode2session这个接口时，千万别把appSecret放在小程序前端代码里，前端的任何代码都能被反编译，secret一旦泄露，别人就能冒充你的小程序调接口。第二，openid只能在小程序专属环境里拿到，同一个用户在你不同的小程序里openid不同，但同一个公众号下的网页应用和移动应用共享同一个openid体系，所以不要拿别的场景的openid直接往这里塞。第三，token存Redis时要设置过期时间，用户长期不活跃后token自动失效，让用户重新登录，这样能有效避免token被长期盗用。

3.2 商品浏览与搜索：数据库索引这样设计

商品浏览看起来简单，实际上有一个非常容易被忽略的问题：数据库查询性能。

这个小程序在商品列表页和搜索页共用一个商品查询接口，支持按分类筛选、按关键词模糊搜索、按价格区间过滤、按销量或价格排序、分页返回。一旦数据量上来，一个表格查得慢就会拖垮整个页面。

我一开始写的SQL是直接在商品表上做模糊查询和排序：

sql复制SELECT * FROM product 
WHERE category_id = 1 AND status = 1 
AND title LIKE '%猫粮%' 
ORDER BY sales DESC LIMIT 0, 10

数据量小的时候没问题，但商品录到几百条之后，这个查询会越来越慢。核心原因就是LIKE '%关键词%'这种写法用不上索引，只能全表扫描，而且ORDER BY sales也需要额外排序。

后来优化方案是组合索引加缓存。category_id和status建一个联合索引，让分类过滤走索引；搜索关键词这块不强行追求数据库命中，而是把搜索结果缓存到Redis，同一个关键词的搜索结果5分钟内不过期。对于宠物用品这种商品池本身就不大的场景，这个方案完全够用。如果商品量再往上走，才有必要上Elasticsearch这类搜索引擎，现阶段属于杀鸡用牛刀。

商品详情页还有一个很容易忽略的点：浏览量统计。如果一个用户反复刷新详情页，浏览量不能简单加一。我的做法是Redis里存一个商品维度的浏览集合，同一个用户对同一个商品的浏览行为5分钟内只算一次，定时任务把累计值刷回数据库。这个细节虽然小，但直接影响热销榜的准确性，热销榜数据不准，管理员就没办法做合理补货决策。

3.3 购物车与订单状态机：状态流转这样设计才不懵

购物车本身不复杂，就是一个用户维度的商品条目集合。关键决策点在于存Redis还是存MySQL。我试过两种方案，最终选择Redis做主存储，MySQL做持久化备份。

Redis方案的好处是读写快，用户在购物车页面增删改查商品时基本无感延迟，而且天然支持设置过期时间，可以做成“购物车30天自动清空”的运营策略。MySQL方案的好处是数据绝对安全，服务器重启后购物车也不丢。考虑到购物车数据属于低价值、高频率访问的数据，Redis加定时持久化的混合方案最合适。

购物车表结构核心字段包括：id、user_id、product_id、sku_id、quantity、checked、create_time、update_time。其中checked字段控制购物车条目是否被选中结算，前端购物车的全选、单选操作就是更新这个字段。

订单模块是整个系统状态最复杂的模块，我用一张状态流转表把状态机理清楚：

这个状态机在设计时，最核心的原则是：状态只能向前流转，不能回退。比如下单后进入待付款，付款后进入待发货，这个链路是单向的。如果管理员已经发货，订单就不能再取消，只能走退款流程。

订单创建过程中有两个关键的并发问题需要处理好。第一是超卖问题，下单扣库存时不能直接写死update product set stock = stock - 1 where id = 1，必须带库存条件：

java复制int updated = productMapper.updateStockByVersion(productId, quantity);
// update product set stock = stock - #{quantity} 
// where id = #{productId} and stock >= #{quantity}
if (updated == 0) {
    throw new BusinessException("库存不足");
}

第二是订单号生成，不能用数据库自增ID当订单号，否则用户能看到你的订单总量，而且容易并发冲突。我用的方案是时间戳加随机数：SimpleDateFormat格式化当前时间到秒，拼上6位随机数，再拼上用户ID后4位，保证唯一性。

3.4 微信支付对接细节：v3版本这样调才顺

微信支付是目前小程序商城绕不开的环节。这个项目用的是微信支付v3版本，相比v2，最核心的变化是API签名方式从MD5签名升级到了RSA非对称签名，安全等级更高，但对接复杂度也上了一个台阶。

微信支付v3的对接流程，重点就四个环节：

第一，准备商户参数。你需要商户号mchid、商户API私钥、商户证书序列号、APIv3密钥。这些参数在微信商户平台的后台都能申请到，其中APIv3密钥是你在商户平台自己设置的32位字符串，用于回调数据的解密。

第二，小程序端发起支付。前端拿到后端返回的支付参数后调用wx.requestPayment：

javascript复制wx.requestPayment({
  timeStamp: res.data.timeStamp,
  nonceStr: res.data.nonceStr,
  package: res.data.package,
  signType: 'RSA',
  paySign: res.data.paySign,
  success: (payRes) => {
    // 支付成功，跳转到订单详情页
  },
  fail: (err) => {
    // 用户取消支付或支付失败
  }
});

第三，后端创建预支付订单。后端调用微信支付的统一下单接口，把订单号、金额、回调地址传过去，微信返回一个prepay_id。注意金额单位要换算成“分”，宠物粮如果售价是128元，传给微信的金额就是12800。

第四，回调通知处理。用户支付成功后，微信服务器会调用你配置的回调地址，通知你支付结果。回调地址必须是HTTPS域名，这是小程序上线时微信的硬性要求。

回调处理里最容易出问题的是验签和解密。微信回调的密文要用APIv3密钥做AES-256-GCM解密，解密后拿到订单号和支付状态，再更新数据库里的订单状态。一定要做幂等处理，同一个支付回调可能因为网络重试被发送多次，第二次收到时订单已经是已支付状态，直接返回success就行，不能重复处理。

4. 管理端与数据统计：把后台做到能直接用的程度

4.1 商品管理的核心字段设计

商品模块是管理端的重头戏。宠物用品这个品类的商品有一个显著特点：同一个商品通常有多个规格，猫粮有2kg和10kg装，狗零食有牛肉味和鸡肉味，驱虫药有不同体重适配规格。这就要求商品表必须支持SPU和SKU两层结构。

SPU是商品单位，描述“这是什么商品”，比如“某品牌全价猫粮”；SKU是库存单位，描述“这个商品的具体版本”，比如“某品牌全价猫粮 2kg 鸡肉味”。

在数据库设计上，product表存SPU维度信息，字段包括：product_id、title、subtitle、category_id、main_image、detail_images、description、status、create_time。sku表存SKU维度信息，字段包括：sku_id、product_id、sku_name、price、stock、sales、image、spec_values。

管理端录入商品时，先填SPU基础信息，再添加多个SKU。价格和库存都挂在SKU上，小程序端商品详情页展示时要显示SKU的价格区间，比如“¥89-¥299”，用户选择具体规格后展示对应SKU的价格和库存。

这里要特别注意图片处理。宠物用品的主图质量直接影响转化率，管理端上传图片时要做好压缩和格式校验。图片上传的“坑”在于小程序端上传图片时，wx.uploadFile的name字段要和后端接口接收的MultipartFile参数名保持一致，否则会报“Required request part 'file' is not present”的错误。

4.2 订单管理与出库流程

订单模块在管理端承担的核心职责是处理状态流转，尤其是发货和退款两个操作。

发货操作流程是：管理员在待发货列表里点击发货，填写物流公司和物流单号，系统更新订单状态为待收货，并通过订阅消息通知用户。这里要提一下，小程序的消息推送和公众号不一样，小程序不能随便给用户发模板消息，必须用户主动订阅后才能推送，而且一次性订阅只能推送一次。所以设计通知方案时，要让用户在下单时主动勾选“订阅发货通知”，这样发货后系统才能把物流信息推给用户。

退款流程分两种情况。第一种是用户付款后、管理员发货前申请退款，这种直接原路退回，操作简单。第二种是用户收到货后申请退货退款，这种需要管理员审核，审核通过后用户寄回商品，管理员收到货后再执行退款操作。系统里我用一个refund表记录退款申请，字段包括：refund_id、order_id、user_id、refund_reason、refund_amount、status、refuse_reason、create_time。

退款操作对接微信支付v3的退款接口，传订单号和退款金额，微信异步通知退款结果。退款到账一般需要1到3个工作日，所以退款状态字段要区分“退款中”和“退款成功”，用户端展示时要准确显示。

4.3 数据看板怎么做才不是花架子

数据统计是管理端最容易做烂的模块。很多初学项目管理端的数据看板就是摆几张静态图表，数字不带任何操作含义，管理员看了也不知道该干什么。

我这套系统里做了三个真正能指导决策的报表：

热销商品TOP10这个报表的实现，是直接从订单明细表里按商品ID分组，统计销量总和然后排序。宠物用品销售有明显的长尾效应，前10个爆款商品可能贡献了超过一半的销售额，运营每天看这个榜单就知道哪些品要继续推广、哪些品要优化详情页。

销售额趋势报表按天汇总订单实付金额，时间范围支持7天、30天、90天切换。宠物用品有两个明显趋势，一是换季期间销量波动大，二是促销活动前后销量起伏明显。有了趋势图，运营人员可以在活动结束后复盘ROI，精确到每一天的销售额变化。

分类占比报表统计每个一级分类下的商品销量占比，用饼图展示。这个数据能告诉你店铺的商品结构是否合理，比如如果“猫粮”一个分类占了80%的销量，那就说明店里的品类结构严重失衡，需要考虑引入更多狗粮、零食、玩具等类目的商品，避免鸡蛋全放在一个篮子里。

5. 部署上线与常见问题排查实录

5.1 小程序服务器域名与HTTPS配置

小程序上线前的服务器配置是新手最容易卡住的地方，而且这个坑一旦踩了，排查起来非常耗时间。

小程序要求所有请求的接口域名必须满足三个条件：第一，域名必须备案；第二，域名必须配置HTTPS证书，协议必须是wss或https，不能是http；第三，域名必须在微信公众平台后台配置为request合法域名。

如果你的后端接口地址是http://localhost:8080或者在IP地址上，小程序开发者工具里可以正常请求（因为开发者工具默认勾选了“不校验合法域名”），但真机预览时会直接报“url not in domain list”。解决方式是先把后端部署到服务器上，配置好域名和HTTPS证书，然后到微信公众平台的小程序后台，在“开发管理→开发设置→服务器域名”里添加request合法域名和downloadFile合法域名。

这里介绍一个省钱技巧：初期开发和测试阶段，可以先不买云服务器，用natapp这类内网穿透工具把本地服务映射成一个HTTPS域名，然后在开发者工具里临时启用“不校验合法域名”选项，就能在真机上调试。但这只是权宜之计，正式上线必须用备案域名和正规HTTPS证书。

5.2 常见报错与环境问题速查

实际开发过程中，几乎每个模块都踩过坑。我把这些坑整理成一个速查表，方便读者排查：

其中有两个问题想重点展开说。第一个是“invalid code”的问题，这个错误的排查思路是：微信的code只能使用一次，如果你的前端因为页面跳转或重复点击导致wx.login被调用了两次，第一个code就会被第二个code顶掉。还有就是请求发到后端后，如果微信接口因为网络原因超时，不要直接重试，应该重新调用wx.login获取新code再发起请求。

第二个是支付回调解密失败的问题，这也是排查时间最长的一个坑。微信支付v3回调的resource对象里包含ciphertext、nonce、associated_data三个字段，解密时需要组合使用。很多人以为是AES-128-CBC加密，实际上v3用的是AES-256-GCM，算法不同，解密结果自然不对。用下面这段代码就能正确解密：

java复制public String decryptWechatPayNotify(String ciphertext, String nonce, String associatedData) {
    try {
        // APIv3密钥，32字节
        SecretKeySpec key = new SecretKeySpec(apiV3Key.getBytes(StandardCharsets.UTF_8), "AES");
        // 初始化AES-GCM解密器
        Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
        GCMParameterSpec spec = new GCMParameterSpec(128, nonce.getBytes(StandardCharsets.UTF_8));
        cipher.init(Cipher.DECRYPT_MODE, key, spec);
        cipher.updateAAD(associatedData.getBytes(StandardCharsets.UTF_8));
        byte[] plaintext = cipher.doFinal(Base64.getDecoder().decode(ciphertext));
        return new String(plaintext, StandardCharsets.UTF_8);
    } catch (Exception e) {
        log.error("微信回调解密失败", e);
        return null;
    }
}

5.3 上线前必须检查的清单

结合几次项目上线的经验，我整理了一个上线前检查清单，照着走一遍能避开八成以上的低级事故。

第一，版本兼容性。Spring Boot 2.7.x搭配JDK 1.8，MySQL 8.0，Redis 6.x，这个组合是经过验证比较稳的组合。如果你的开发环境是JDK 17或更新版本，建议先在pom.xml里把Java版本改为1.8，确认编译通过后再部署。

第二，application.yml里的配置项，包括数据库连接、Redis连接、微信小程序appId和secret、微信支付商户号、回调地址等，都要检查一遍。尤其注意不要把真实的appSecret和商户私钥直接写在代码里，推荐用环境变量或者配置中心管理，能避免不小心的泄露。

第三，小程序端域名配置。登录微信公众平台，确认request合法域名、uploadFile合法域名、downloadFile合法域名都配置齐全，注意每个合法域名最大支持配置20个，不需要的全部移除。

第四，数据库备份策略。宠物品类的订单数据和商品数据非常重要，建议配置每天凌晨全量备份，保留最近7天备份文件。命令行执行mysqldump就能实现：

bash复制mysqldump -u root -p pet_shop > /data/backup/pet_shop_$(date +%Y%m%d).sql

第五，nginx反向代理配置。如果后端部署在多台服务器上，建议在前面加一层nginx做负载均衡和HTTPS证书管理。nginx配置转发到Spring Boot默认端口8080，SSL证书用Let’s Encrypt的免费证书即可生效。

5.4 一些小众但实用的优化技巧

除了上面那些必踩的坑，还有几个小众优化点，属于开发中偶然发现但不试不知道的技巧。

小程序端图片加载慢的问题，本质上是因为宠物用品详情页的图片数量多且体积大。我做了两个优化：第一，管理端上传图片后用压缩工具统一处理，把超过500KB的图压到200KB以内，保持清晰度的同时减少加载时间；第二，在详情页用懒加载，只有用户滚动到对应位置时才加载图片，首屏加载速度明显更快。

关于Spring Boot启动时的banner，很多人觉得无所谓，但它其实能帮助团队快速识别环境。我在application.yml里配置了不同环境的banner文字，比如dev环境的Banner上显示“开发环境，请勿用真实数据”，生产环境显示“生产环境，操作谨慎”。这样多人协作时，谁连错环境一眼就能看出来。

宠物用品这个类目有一个特殊要求：商品类目字段要区分适用宠物类型，比如狗粮适用于狗狗、猫粮适用于猫咪。这个字段在数据库里设计成category_id关联分类表，但在管理端录入商品时，做了一个联动逻辑，选择“狗狗”分类后，下一步只能选择狗粮、狗零食、狗玩具等子分类，避免录错类目导致用户搜索不准确。

6. 源码使用指南与二次开发方向

这套源码拿到手之后，导入和启动的路径很直接。后端是标准的Maven项目，用IntelliJ IDEA打开，等Maven依赖下载完成后，修改application.yml里的数据库连接信息，执行项目下的pet_shop.sql脚本初始化数据库，然后运行Application主类就能启动，默认端口8080。

小程序端用微信开发者工具导入项目根目录下的mini-program文件夹，修改app.js里的接口请求地址为你的后端地址，编译运行即可。如果后端跑在本机，小程序请求地址填局域网IP，但真机调试时手机必须和电脑在同一个局域网，否则连不上。

接下来有几个值得做的二次开发方向，按性价比排序：

对接上门配送服务。宠物用品和普通电商最大的不同是，猫粮狗粮这类重物用户往往希望线下门店直送。微信小程序里有“同城配送”的开放能力，可以对接闪送、达达这类第三方配送平台，实现从下单到配送的全流程追踪。

增加会员积分体系。宠物食品是高频复购类目，积分体系能显著提升用户粘性。可以在用户表加一个points字段，下单按金额累计积分，积分可抵扣现金或兑换宠物零食，配合小程序的订阅消息做积分到期提醒，能明显拉高复购频次。

接入宠物档案功能。这是宠物用品小程序独有的差异化功能，用户在小程序里创建自家宠物的档案（品种、生日、体重、绝育状态），系统根据档案自动推荐合适的粮和用品，并在驱虫、疫苗到期时主动提醒。这个功能虽然开发工作量不小，但一旦用户建了档案，迁移成本会非常高，是留住用户的好手段。

我这套源码打包后的压缩包里有完整的数据库脚本、后端源码、小程序端源码、部署文档，拿到就可以开始跑。如果你主要目的是学习Spring Boot和小程序联调，建议按模块逐步读代码，而不是一次性把所有东西都看完，先从登录流程入手，然后走一边商品浏览和下单流程，把核心链路的代码都过一遍，收获会大得多。