张云雷宝宝做了几年Spring Boot后端，最近一直在折腾微信小程序端的电商类项目，手头正好有一套宠物用品销售小程序的完整源码，编号86805。这个项目麻雀虽小五脏俱全，用户端加管理端该有的模块全都有，代码也不绕弯子，很适合刚接触前后端分离开发的初学者当活教材，同时也是个能直接用起来的毕业设计级模板。
整套东西跑起来之后，就是一个典型的“Spring Boot + 微信小程序”商城闭环。用户在小程序里浏览分类、搜索商品、加购物车、下订单、微信支付，管理员在后台维护商品、处理订单、看统计数据。下面从设计思路到具体实现，再到部署上线踩过的坑，按我的实际操作顺序完整拆一遍。
1. 项目全貌：一个宠物用品商城小程序到底有哪些功能
1.1 用户端功能拆解
小程序端的用户操作路径，说白了两条主线，一条是“逛”的链路，另一条是“买”的链路，这两条链路基本决定了用户端所有页面和接口的走向。
逛的链路包含首页、分类页、搜索、商品详情。宠物用品这个品类有个特点，用户的浏览习惯非常聚焦，要么直接搜猫粮狗粮，要么按“猫主子”“狗主子”分类翻，很少漫无目的地逛。所以首页我做了三个入口：顶部搜索框、banner轮播图、下方金刚区分类图标，这样低频决策用户能快速直达，高频复购用户也能顺着分类找到目标商品。
买的链路是加购物车、确认订单、支付、查看订单状态。宠物粮这类商品复购率很高，很多用户是定期补货，所以购物车模块做得顺手特别重要。这个小程序在购物车里做了规格记忆，同一个商品选了不同规格会分成不同的购物车条目，避免用户每次来都要重新选口味和重量。
详情页里除了常规的商品图、价格、库存、销量，还单独加了宠物适龄提示和喂养建议字段。这不是我拍脑袋加的，宠物用品行业就吃这一套，买家下单前一定会确认这个粮幼猫能不能吃、成犬合不合适，页面上直接写清楚能减少大量售前咨询。
1.2 管理端功能拆解
管理端这边没有单独做App或者复杂的PC端，直接嵌在Spring Boot项目里，用经典的管理员页面来实现，好处是部署省事，一个应用全搞定。管理端的核心模块是这几个：
商品管理是最基本也是用得最多的。录入商品时要设置分类、标题、主图、详情图、价格、库存、销量基数、上下架状态，还要处理规格，比如2kg装和10kg装是同一个SPU下的两个SKU，价格和库存都不一样。
订单管理承担了状态流转和发货操作。订单列表支持按订单号、用户、状态多维筛选，核心操作是两个：发货、退款。宠物用品这种标品为主的类目，售后率不算高，但退款流程必须走通，尤其是“已付款未发货”场景下的极速退款。
用户管理就是查看用户列表和用户详情，能看到用户的基本信息、注册时间、累计消费金额。对于个人开发者来说，用户数据量不大，没必要上太复杂的用户分层体系，但累计消费金额这个字段可以给后续做会员体系留一个扩展入口。
数据统计是管理端最有价值的部分。宠物用品销售有个明显规律，促销节点和换季期间销量波动很大。我在这套系统里做了销售额趋势、热销商品TOP10、分类占比三个维度。其中热销商品TOP10这个报表直接接在订单明细表上实时统计，上架新品后每天扫一眼这个榜，就能快速判断哪些品值得补库存，哪些品需要调整促销策略。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
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的，照着改就行。
下面是这套项目用到的核心依赖清单：
| 依赖 | 版本 | 用途 |
|---|---|---|
| Spring Boot | 2.7.18 | 核心框架 |
| MyBatis Plus | 3.5.3 | ORM框架，简化单表CRUD |
| MySQL | 8.0 | 关系型数据库 |
| Redis | 6.x | 缓存购物车、token、热点数据 |
| Lombok | 1.18.30 | 简化实体类代码 |
| Hutool | 5.8.18 | 工具类库，处理HTTP请求、生成签名 |
| 微信支付SDK | 0.2.10 | 对接微信支付v3 |
这里多说一句为什么引入Hutool。微信支付v3的对接过程中，要生成HTTP请求、处理敏感信息加解密、计算签名，这些操作用原生代码写工程量很大而且容易出错，Hutool把很多通用逻辑封装好了，在自己的ServiceImpl里组合调用就行。
2.3 项目目录结构与分层思路
这套项目采用标准的单体分层架构，controller、service、mapper三层，目录结构很清晰，拿到源码后第一眼就能看明白。
项目顶层模块是pet-shop，下面按功能分包。config包下放全局配置类，包括WebMvc拦截器注册、Redis序列化配置、微信支付配置类。controller包按业务域拆分，有AuthController、P