这次我们来看一个很典型的全栈电商实战项目基于 SpringBoot Vue3 微信小程序实现的运动户外交易小程序商城。这类项目在课程设计、毕业设计和接私活场景里出现频率很高原因很简单它同时覆盖了后端接口服务、Vue3 管理后台和微信小程序 C 端三个端一条链路下来正好把 Java 全栈开发的完整流程走了一遍而且业务领域是运动户外商品交易贴近真实电商场景不是那种只有增删改查的演示项目。先说这个项目最值得关注的重点后端采用的是 SpringBoot 体系按项目命名对应到较新的 SpringBoot4 大版本如果之前用过 SpringBoot2/3迁移到新版本时最直观的感受是自动配置方式、起步依赖和配置文件的组织习惯有变化管理后台用了 Vue3小程序端则是原生微信小程序开发。也就是说一个项目同时覆盖“用户端小程序商城 商家后台商品订单管理 SpringBoot 后端服务”对于想系统学习前后端分离、小程序上线流程和电商订单闭环的同学来说它的参考价值比单体 CRUD 项目高很多。下面这篇内容我会直接按可复现的思路来拆解项目核心功能是什么、技术栈怎么组织、本地环境怎么准备、三个端分别怎么启动、数据库表怎么设计、核心交易流程怎么跑通、常见部署问题怎么排查。全程没有虚拟机的花活所有步骤都按普通 Windows/Mac 开发机来给。1. 核心能力速览先把项目最核心的信息放在前面方便快速判断它适不适合你。能力项说明项目类型运动户外电商平台 / 微信小程序商城技术栈SpringBoot Vue3 微信小程序后端架构前后端分离SpringBoot 提供 REST API管理后台Vue3 Element Plus 风格后台管理界面用户端微信小程序覆盖商品浏览、购物车、下单、支付流程商城核心功能运动户外商品展示、分类检索、商品详情、购物车、订单、支付、收货地址、个人中心后台管理功能商品管理、分类管理、订单管理、用户管理、轮播图管理、销售数据统计方向数据库MySQL核心表覆盖用户、商品、分类、订单、订单明细、购物车、收货地址、轮播等方向适合场景毕业设计、课程设计、Java 全栈学习、小程序电商项目二次开发启动复杂度三个端分别启动SpringBoot 后端 Vue3 管理后台 微信开发者工具是否支持 API支持SpringBoot 天然提供 REST API 给管理后台和小程序消费需要说明的是显存、GPU 这类参数在这里不存在这个项目吃的是 JDK、MySQL、Node 和微信开发者工具属于“本地开发机就能跑”的传统 Web 全栈项目。2. 适用场景与使用边界在动手部署之前先明确这个项目的适用范围避免很多人装到一半发现和自己想的不一样。这个项目适合这几类人正在做毕业设计或课程设计需要一个功能完整、页面量够、有真实业务闭环的电商系统。想系统学习 SpringBoot Vue3 小程序三端协作的开发方式尤其是搞清楚管理后台和小程序如何共用同一套后端接口。需要快速搭建运动户外类小程序商城原型验证商品展示、购物车、订单流程的可行性。想基于一套现成代码做二次开发替换成自己的运动品牌、骑行装备、露营用品等垂直场景。它不适合的场景也要提前说清楚如果只是想做一个“能发朋友圈展示页面”的静态商城不需要后端和数据库这个项目偏重没必要上 SpringBoot。如果没有微信小程序 AppID也不打算注册测试号小程序端只能体验部分静态页面登录、支付等真实微信能力会受限。如果完全没接触过 Java 和 Maven启动后端时要先补一下 SpringBoot 基础否则配置文件、依赖下载、端口占用这三个问题会轮番出现。使用边界这块必须重点提醒商城项目一旦涉及真实商品、用户手机号、微信授权、订单数据和支付接口就属于真实业务系统。测试阶段建议把支付切换为模拟支付或沙箱等需要上线时微信小程序类目、微信支付商户号、隐私保护协议等都必须按平台要求走。不要拿测试代码直接跑真实交易也不要采集用户信息后随意存储。另外项目代码中的图片素材、品牌 Logo、商品描述若来自网络仅可用于学习演示商用前替换为自有版权素材或者确认过授权的素材。3. 项目架构与技术栈分析从整体架构来看这个项目是标准的前后端分离单体应用结构由一个 SpringBoot 后端同时支撑 Vue3 管理后台和微信小程序两个前端。这里我建议先建立一个全局心智模型管理后台和小程序之间不直接通信都通过 HTTP 调用 SpringBoot 暴露的 REST 接口。管理后台主要负责商品、订单、用户等内容管理运行在浏览器。小程序是 C 端用户真正接触的商城页面运行在微信里。数据库统一使用 MySQLRedis 这类缓存组件如果项目里没引入可以先不装避免环境准备阶段多一个变量。3.1 后端SpringBoot后端是整个项目的核心服务端按项目标题内的技术命名对应 SpringBoot4 方向实际使用中请以项目 pom.xml 里的 spring-boot-starter-parent 版本为准。如果之前写过 SpringBoot迁移到新版本后需要注意几个变化点配置文件方面SpringBoot 新版本依旧支持application.yml但配置项的组织方式更推荐分模块管理。起步依赖的命名习惯保持为spring-boot-starter-*。Java 基础版本建议直接使用 JDK 17如果本机还停留在 JDK 8很可能因为版本兼容问题启动失败。后端在电商项目里最核心的职责是维护商品、SKU、购物车、订单的数据一致性提供小程序端所需的列表、详情、下单接口以及提供管理后台所需的统计、编辑接口。典型的分层结构是Controller 层接收 HTTP 请求、参数校验、返回统一响应结构。Service 层处理业务逻辑比如下单时校验库存、计算金额、生成订单号。Mapper 层操作 MySQL 数据库取决于项目用的是 MyBatis、MyBatis-Plus 还是 Spring Data JPA。Entity / DTO对应的数据实体和传输对象。3.2 管理后台Vue3 Vite管理后台使用 Vue3 构建这一个小节里值得关注的是工程化体验。Vue3 项目现在多数基于 Vite 启动开发模式下热更新非常快。管理后台通常包含的页面方向登录页管理员身份认证。仪表盘商品数量、订单数量、用户数量、销售额等统计卡片。商品管理商品列表、新增/编辑商品、上下架、库存维护。分类管理运动户外分类的树形管理比如“运动鞋”“户外装备”“骑行配件”。订单管理订单列表、订单状态流转待发货、已发货、已完成。用户管理用户列表、禁用/启用账号。内容管理轮播图、公告等运营位维护。如果项目里已经接了 Element Plus 或 Ant Design Vue表单校验、表格分页、弹窗确认这些高频交互都可以直接用组件库实现不需要手写。3.3 小程序端微信原生小程序小程序端是用户真正在微信里看到的部分。使用原生小程序开发意味着页面由 WXML、WXSS、JS/TS 组成组件采用小程序自定义组件或内置组件请求接口统一走wx.request。小程序端主要页面首页顶部搜索、轮播 Banner、推荐商品列表、运动户外分类入口。分类页左侧分类 Tabs 右侧商品列表联动。商品详情页图片轮播、价格、库存、规格选择、加入购物车、立即购买。购物车页勾选商品、修改数量、计算总价、去结算。订单确认页选择收货地址、填写备注、提交订单。订单列表页不同订单状态切换、模拟支付或调用微信支付。个人中心页用户昵称头像、订单入口、收货地址管理、关于我们。小程序端最容易踩坑的地方集中在微信登录态维护和支付模拟。登录时通常需要先调用wx.login获取 code然后把 code 传给后端换取 openid 和自定义 token支付时如果没有商户号建议在测试环境做“模拟支付”按钮把订单状态直接置为已支付方便跑完整个流程。4. 环境准备与本地部署前置条件本地跑通这个项目核心是保证 Java、Node、MySQL 三件套版本兼容。下面是一份通用前置清单。具体版本以仓库内 README 或 pom.xml 为准但按这份准备基本不会出方向性错误。4.1 环境总览组件建议版本方向用途JDKJDK 17 或更高版本运行 SpringBoot 后端MavenMaven 3.6后端依赖管理和打包MySQLMySQL 5.7 / 8.0持久化业务数据Node.jsNode 16 / 18运行 Vue3 管理后台npm / pnpmnpm 9 或 pnpm 8管理后台依赖安装微信开发者工具最新稳定版打开小程序端代码IDEA 或 VS Code不限Java/前端编码调试4.2 安装检查命令后端开发机建议先把 JDK 和 Maven 确认好。Windows 打开 PowerShellmacOS / Linux 打开终端执行java -version mvn -v node -v npm -v预期输出里能看到对应的版本号。如果java -version报错说明 JDK 没装或系统环境变量没配好如果mvn -v报错说明 Maven 没配置或者没有把MAVEN_HOME加到 Path 里。MySQL 安装后建议直接用 Navicat、DataGrip 或命令行工具确认能正常连接mysql -u root -p输入密码后能进入 MySQL 交互命令行就说明数据库服务正常。4.3 数据库准备商城项目启动前基本都要先导入 SQL 脚本。正常的项目结构会提供一个sql目录内部是初始化脚本比如sport_shop.sql。导入方式有两种。方式一命令行导入以 Windows 为例实际路径替换成自己机器的路径mysql -u root -p sport_shop D:/project/sport_shop.sql方式二在 Navicat 中右键数据库 - 运行 SQL 文件选择脚本执行。执行成功后需要检查数据库配置文件里的账号、密码、库名是否和本地一致。SpringBoot 项目的核心配置通常在src/main/resources/application.yml或application.properties里要重点核对这几项spring: datasource: url: jdbc:mysql://localhost:3306/sport_shop?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 你的数据库密码 driver-class-name: com.mysql.cj.jdbc.Driver这里的sport_shop只是示例库名具体以你的 SQL 脚本里的 CREATE DATABASE 名称为准。5. 安装部署与启动方式三端启动先后顺序建议是先后端再管理后台最后小程序端。因为管理后台和小程序都需要调用后端接口提前把服务端跑起来可以避免前端调试时一直报网络错误。5.1 启动 SpringBoot 后端用 IDEA 打开后端目录一般目录结构里会包含src、pom.xml。打开后IDEA 会自动识别 Maven 项目并开始下载依赖。首次下载依赖时间取决于网络环境如果 Maven 下载很慢建议在settings.xml里配置阿里云镜像mirror idaliyunmaven/id mirrorOfcentral/mirrorOf nameAliyun Maven Mirror/name urlhttps://maven.aliyun.com/repository/public/url /mirror依赖下载完成后找到主类。主类通常是项目里带有SpringBootApplication注解的类类名一般是Application、SportShopApplication这种命名。直接右键 Run。后端默认端口在配置里指定常见是8080。启动成功后控制台里会出现 Spring Boot 的启动 Logo接着显示类似这样的日志Tomcat started on port 8080 (http) with context path Started Application in X.XX seconds看到这行日志后端服务就起来了。快速验证接口是否通畅可以在浏览器直接访问http://localhost:8080/api/health或访问项目中某个公开的商品列表接口只要返回 JSON 就说明后端基本没问题。如果项目配置了统一前缀server.servlet.context-path比如/sport-shop那所有接口都要带上前缀。5.2 启动 Vue3 管理后台管理后台目录一般包含package.json打开终端进入该目录先安装依赖npm install如果项目里存在pnpm-lock.yaml或yarn.lock优先使用对应的包管理器pnpm install依赖安装完成后启动开发服务npm run dev默认情况下 Vite 服务会跑在http://localhost:5173控制台会输出可访问地址。浏览器打开后第一步要检查的是登录接口是否通。如果后台页面里所有请求都报 404需要检查项目的前端环境配置文件比如.env.development里的 API 地址VITE_API_BASE_URLhttp://localhost:8080如果后端设置了 context-path还要补全VITE_API_BASE_URLhttp://localhost:8080/sport-shop另外需要处理跨域。调试阶段最快的方式是在后端加 WebMvcConfigurer 配置允许本地跨域下面是一个通用示例实际代码要以项目已有配置为准Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }5.3 启动微信小程序端小程序目录里会有app.js、app.json、pages这类文件。用微信开发者工具导入项目时选择小程序端目录而不是后端或后台目录。最容易被卡住的步骤是 AppID。如果没有已注册的小程序账号可以选择“测试号”。导入后项目里的project.config.json可能会有自己的 appid 配置需要替换成你自己的测试号或正式 AppID。小程序端请求后端的地址配置一般在utils/config.js、api/request.js或app.js的全局变量里设置。如果 I 的真机预览要把localhost改成电脑在局域网中的 IP并在微信开发者工具里勾选“不校验合法域名、web-view业务域名、TLS 版本以及 HTTPS 证书”。下面是一个典型的请求地址配置示例用于说明// utils/config.js module.exports { baseUrl: http://localhost:8080/sport-shop }在开发者工具里编译后小程序页面能正常加载商品列表就说明后端和小程序的链路打通了。5.4 准备一份最小可运行配置针对这种三端项目我强烈建议在本地保留一份最小可运行配置记录内容包含后端端口号和接口前缀。数据库名称、账号密码。Vue3 后台的VITE_API_BASE_URL。小程序端request.js里配置的 baseUrl。本地 MySQL 服务是否开机自启。Maven 镜像是否已配置。把这些信息记在一个local-config.md文件里。换电脑、重装环境、交给同学部署时一份准确的环境记录能省下一个下午的排查时间。6. 数据库设计领域模型与核心业务表电商商城的数据库设计是整套项目业务逻辑的地基。只要订单表、订单明细表和购物车表关系理解了后面的接口测试流程自然顺。下面这些表和字段比较典型。6.1 用户相关表用户表用于保存小程序用户或后台管理用户的信息。字段方向说明id主键openid微信用户唯一标识如果走微信登录nickname昵称avatar头像phone手机号status账号状态启用/禁用create_time注册时间收货地址表关联用户 id保存收货人姓名、手机号、省市区和详细地址。下单时从地址列表选择也可以维护默认地址。6.2 商品相关表商品表保存商品本身的通用信息如名称、主图、价格、原价、库存、销量、上下架状态。分类可以单独建表也可以设计为层级分类比如“运动户外”一级分类下挂“跑步”“骑行”“露营”“健身”等。如果商品有颜色、尺码等多规格属性规范的电商设计里需要一张 SKU 表来维护每种具体规格的库存和价格但很多教学项目的简化做法是直接在商品表里用一个字段存默认库存小程序端只做单规格商品购买。从实际项目演示来看单规格设计可以快速跑通完整流程多规格 SKU 适合后续二次扩展。6.3 购物车、订单与订单明细表购物车表记录用户 id 和商品 id以及加入的数量。订单表是核心中的核心字段大体包括字段方向说明order_no订单号通常由时间戳随机数生成user_id下单用户total_amount订单总金额pay_amount实付金额status待付款/已付款/待发货/已发货/已完成/已取消receiver_name / receiver_phone / receiver_address收货信息create_time / pay_time / ship_time各状态时间戳订单明细表记录每个订单内包含哪些商品、数量、单价。为了方便对账商品名称、图片、单价这些字段建议做冗余存储否则商品修改价格或删除后会丢失历史订单的可读信息。另外简单商品交易场景下不设置运费表建议在小程序设计为“包邮”省去运费计算分支。一个最少可用的数据库建表脚本导向如下。实际需结合项目脚本填写字段以实际项目为准DROP TABLE IF EXISTS t_order; CREATE TABLE t_order ( id BIGINT NOT NULL AUTO_INCREMENT, order_no VARCHAR(50) NOT NULL COMMENT 订单号, user_id BIGINT NOT NULL COMMENT 用户ID, total_amount DECIMAL(10,2) NOT NULL COMMENT 总金额, status TINYINT NOT NULL DEFAULT 0 COMMENT 订单状态:0待付款,1已付款等, PRIMARY KEY (id), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单表;7. 核心交易链路与接口设计这个项目最值得动手调试的部分就是“用户将商品加入购物车发起下单完成状态流转”这一条链路。理顺这条链路后就能理解商城系统里前后端如何协作。一次完整的下单流程至少要经过这几个环节。7.1 商品浏览与加购用户进入小程序后在商品列表页请求后端商品接口后端返回商品列表包含封面图、标题、价格、销量信息。用户在详情页点击“加入购物车”小程序端会发起添加购物车请求请求包含商品 id数量用户标识。由于小程序端没有主动维护登录态通常的做法是用户在小程序启动时先做静默登录调用wx.login获取临时 code传给后端的登录接口后端拿 code 换取 openid 后生成 token 返回小程序后续请求在 header 中携带 token后端根据 token 识别用户。这种模式下购物车接口自然能定位到是哪个用户的数据。7.2 下单与幂等问题这是下单链路里面最容易写出 Bug 的一环。用户从购物车发起结算后端收到请求后要执行的事务里包含校验商品是否存在且为上架状态。校验库存。计算订单金额。扣减库存。创建订单主记录。创建订单明细记录。清空购物车中对应商品。这个流程必须放在数据库事务里最直接的原因是库存扣减和订单创建需要保持一致性。如果先扣库存但订单创建失败库存没了订单也没了用户无法继续购买。真实电商中设计接口时还要考虑一个高频问题用户连点两次“提交订单”会不会生成两个订单解决方向通常是在后端做订单创建幂等或者前端在提交按钮上做 loading 禁用。在课程演示阶段至少做到前端按钮“防止重复提交”点击提交后立即置灰按钮并给后端请求加上像“订单令牌”或“客户端操作流水号”这类唯一标识后端在创建订单前检查该标识是否已经用过从源头避免同一操作生成多个订单。下面给出一段简化版的下单服务接口体实现思路实际项目里实现方案会受 Mapper 等影响这里重点是看事务逻辑Service public class OrderService { private static final Logger log LoggerFactory.getLogger(OrderService.class); Transactional public OrderCreateResult createOrder(OrderCreateRequest request) { // 1. 解析商品ID和数量 // 2. 查询商品列表校验是否上架 // 3. 校验库存不满足则抛出业务异常 // 4. 生成唯一订单号例如 yyyyMMddHHmmss userId 4位随机数 // 5. 插入订单主记录状态置为待付款 // 6. 插入订单明细记录 // 7. 扣减库存 // 8. 删除购物车已选商品 // 9. 组装返回订单号结合微信支付参数返回给小程序 return null; } }拦截重复下单的这个“幂等令牌”也可以放进 Redis 等缓存组件里但显然这里先不引入 Redis 也能完成整套下单链路演示。7.3 支付回调与订单状态流转订单创建成功后是待付款状态。研发环节可以做一个“模拟支付”按钮点击后调用后端的模拟支付接口把订单从待付款流转为已付款。如果是真实微信支付前端需要调用wx.requestPayment并传入后端返回的时间戳、随机串、包名、签名、paySign、签名方式等参数。这个阶段后端会同时向微信支付服务器发送异步通知。异步通知到达后端接口后后端需要验证签名和订单金额确认无误后再把订单状态从待付款更新为已付款。此时必须小心通知到达不一定按顺序同一笔支付可能通知多次对通知处理要设计成幂等。稳妥的写法思路是在回调处理中先根据 order_no 查询订单状态如果当前订单已经是已付款就直接返回成功不再次处理。这里的连接关系可以这样理解小程序端不是直接把订单改成已付款而是微信支付先把结果通知到后端由后端更新状态后再通知小程序刷新订单列表。7.4 订单列表与售后状态订单列表页面需要按状态标签过滤例如待付款、待发货、待收货、已完成以及取消/退款。小程序端通过status参数请求后端订单列表接口后端按用户 id 和状态查询。如果项目需要发货管理后台中增加“发货”操作即可填写物流单号后订单状态流转到待收货用户确认收货或发货后延迟自动确认后订单状态流转到已完成。8. 三端接口调用与功能验证启动完成后本人建议按以下顺序做一套完整功能验收这套顺序能够把前后端链路中大多数问题暴露出来。8.1 验证管理后台商品发布在 Vue3 管理后台登录进入商品管理。新增一件商品比如“户外轻量跑步背包”填好分类、价格、库存、上传封面图、上下架状态为上架提交保存。到商品列表中确认新商品显示。这里一个关键点是管理后台发布商品后小程序端必须能看到该商品这依赖两边查询的是同一张商品表并且商品处于上架状态。如果小程序端刷新后看不到数据优先检查请求是否成功、商品上下架状态是否过滤掉以及小程序请求的后端地址和当前后端是否匹配。8.2 验证小程序商品浏览与加购在小程序端首页下拉刷新确认商品列表出现刚才新增的商品。打开商品详情页点“加入购物车”底部导航进入购物车页面确认对应商品数量和总价正确。如果请求失败打开开发者工具的控制台和 Network 面板查看请求返回码。最常见的问题是没有勾选“不校验合法域名”或 baseUrl 写错。8.3 验证统一下单流程在购物车内勾选刚才的商品点击去结算。这一步会跳转到订单确认页需要选择收货地址。如果没有地址先新增一个测试地址。提交订单后在订单列表页确认出现了“待付款”状态订单。测试环境没有真实微信支付通道时点击“模拟支付”或“直接完成支付”按钮确认订单状态翻转为“待发货/已发货”。然后在管理后台的订单管理里能搜到这单订单点发货并填入物流号。小程序端订单列表里这单状态变为“待收货”。如果项目没有发货管理可以直接在后台把订单标注为已完成重点能看到状态链路已经跑通。8.4 用 curl 验证后端接口后端服务启动后完全可以通过 curl 快速验证接口可用。下面是一个通用的 curl 模板实际 URL 和参数以后端 Controller 为准curl -X GET http://localhost:8080/api/product/list \ -H Content-Type: application/json查看返回 JSON 是否包含商品列表数据。如果接口要求登录态就需要先调用登录接口获得 token然后带上 Authorization 头curl -X POST http://localhost:8080/api/user/login \ -H Content-Type: application/json \ -d {code:wx_login_code_placeholder}响应里如果包含token字段下次请求带上curl -X GET http://localhost:8080/api/cart/list \ -H Authorization: Bearer 你的token9. 接口 API 设计参考与批量任务扩展虽然项目本身是电商系统但也有后端 API 提供给不同端调用下面就接口内容做一个组织和解释。9.1 接口分组建议为了让管理后台和小程序区分也方便管理新建一个模块时接口地址风格可以分成三组小程序端接口/api/user/login、/api/product/list、/api/cart/add、/api/order/create。管理后台接口/admin/product/page、/admin/order/page、/admin/dashboard/statistics。微信回调接口/notify/wxpay。通过/admin前缀可以将需要管理员权限的接口统一保护起来避免和普通用户接口混在一起。下面是一个通用 Controller 方法体示例RestController RequestMapping(/api/product) public class ProductController { GetMapping(/list) public Result list(RequestParam(defaultValue 1) Integer page, RequestParam(defaultValue 10) Integer limit) { // 返回分页商品列表 return Result.ok(); } }9.2 接口鉴权SpringBoot 体系里常见方案是使用拦截器或过滤器来统一校验用户 token。逻辑上一般是这样小程序登录成功后后端把 session 或 token 与用户 id 绑定。后续每个请求先从请求头中提取 token如果 token 不存在或已过期则拦截直接返回 401让小程序重新登录。管理中台和商品列表接口是否需要鉴权要看项目的开放程度。公开浏览页面不登录也要能看下单和购物车则需要登录态。9.3 批量导入与任务扩展电商项目里批量导入业务常见的是“批量上架商品”。后台如果只有几十个商品手工录入可以接受。商品数量到几百个时最好提供一个 Excel 导入入口。这个能力在管理后台里不一定是必需功能但按演示价值考虑值得扩展实现。批量导入的一个参考流程先设计一个导入模板包含商品名称、分类、价格、库存、上下架状态等必要字段。后台解析 Excel 时先做字段校验比如价格不能为负数库存不能小于 0。校验通过后循环写入商品表记录成功和失败的行数。将导入结果返回给前端展示“导入成功 X 行失败 Y 行失败原因明细”。用 Java 解析 Excel 通常用到 EasyExcel 库。这段扩展比较适合作为二次开发练习能让表结构设计与后台列表交互密合起来。10. 资源占用与性能观察思路这个项目不是 AI 推理模型但资源占用观察仍然重要。启动三端服务时IDE、Node、MySQL、微信开发者工具同时开着中低配置电脑可能会遇到内存不足。实操过程中可以打开任务管理器或活动监视器观察。具体观察思路后端 SpringBoot 运行时会占用 JVM 堆内存默认情况下 JVM 会根据机器内存自动设置最大堆。如果本机内存只有 8GB同时又运行了 MySQL、微信开发者工具和 IDE很容易整体卡顿。这时可以给后端设置内存启动参数java -Xms256m -Xmx512m -jar sport-shop.jarVue3 后台的npm run dev启动后进程内存占用并不高通常在几百 MB 范围内。但如果 Node 进程卡死优先检查node_modules是否安装完整删除后重新npm install。MySQL 本身占用比较稳定但如果不生产环境需要关注慢查询。订单列表、商品列表、销量统计等页面分页要加好索引。微信开发者工具本身比较吃内存如果要模拟器页面同时开着实测体感上会更明显。建议运行小程序端和 Vue3 后台时不要同时开太多无用的开发者工具窗口。接口性能优化方向可以从商品列表开始商品列表要有分页字段避免一次查询全部数据。首页用懒加载图片页面滚动到可视区域再加载封面可显著降低网络消耗。如果用户浏览频繁商品详情可以用热点缓存但商品库存和价格还是要强一致读取。11. 常见问题与排查方法三端项目部署过程中问题通常集中在环境、网络、路径三个方面。整理一份排查清单基本能覆盖大多数情况。问题现象可能原因排查方式解决方案SpringBoot 启动失败端口被占用查看控制台日志报错会直接指出 Port 8080 was already in use换端口在 application.yml 里改server.port数据库连接失败数据库名、用户名、密码不匹配查看日志里的 SQL 异常检查 application.yml修正数据库连接配置控制台出现中文乱码控制台编码不是 UTF-8IDEA 的 VM 参数加-Dfile.encodingUTF-8调整运行时编码Maven 依赖下载失败网络问题或镜像问题检查本地 maven 仓库是否有 lastUpdated 文件配置阿里云 Maven 镜像或检查网络Vue3 后台空白页Node 版本不兼容或依赖缺失查看浏览器控制台报错使用 Node 16删除 node_modules 重新 npm install小程序请求接口报 403 / timeout域名校验开关未关或地址写错打开开发者工具的 Network 面板勾选“不校验合法域名”确认 baseUrl 正确小程序请求后端地址在真机上失败localhost 指向了手机自身手机和电脑连同一 Wi-Fi将地址改为电脑局域网 IP重启开发者工具或换用 IP 访问商品图片不显示图片上传路径是磁盘绝对路径或图片服务器地址不可访问查看图片请求 URL判断后端是否提供静态资源映射为后端增加静态资源映射地址配置统一走本地或 OSS下单提示库存不足库存字段没有在扣减时判空或商品未上架管理后台看商品库存状态手动调整测试库存后再下单微信登录失败AppID 是测试号但后端依赖正式 appid 配置看后端日志中微信接口返回信息在配置中使用测试号对应的 AppSecret无法调用真实微信接口时使用 mock 登录订单创建重复用户双击提交按钮看数据库订单是否存在两条相同订单前端加 loading 禁用后端做幂等处理SQL 脚本导入报错数据库字符集或表已存在看报错行号如果表已存在DROP 后重新导入注意跑测试环境前确认可以重建表12. 最佳实践与合规使用建议12.1 开发期工程化建议先按小数据量跑通全流程再把数据量扩大。不要一开始就在后台录几十个商品然后测试下单这会干扰问题定位。第一次建议只录入 2 到 3 个商品走完“加购-下单-支付-发货-完成”链条后再批量补数据。商品和分类建议用树形思维组织。运动户外商品一般会挂一级分类“运动鞋靴”“运动服”“户外装备”“健身器材”每个一级分类下再设二级分类。新版本若要新增分类字段先规划好 code 值和展示顺序避免出现后台看到分类但小程序首页无法显示。多人开发时如果遇到过代码或数据处理这类问题很容易产生严重冲突尤其要提醒注意避免上面出现的由于多人各自本地修改产生 merge 冲突这种场景出现可以统一约定严格后端接口命名。12.2 数据与隐私合规项目涉及用户订单、手机号、收货地址这些都属于敏感数据。管理后台登录密码绝不能硬编码在配置里用户密码要加密存储。后端接口应该限制接口不允许绕过权限尤其是发货、删除商品这类接口都应该校验当前操作者的管理员权限。微信小程序正式上线前必须填隐私保护指引收集手机号、地址时要明确告知用途。开发调试阶段可以使用假地址和假手机号不要把真实测试用户的微信号或地址信息存储在公网上。商品图片等方面建议只用白底自拍照或合法购买的正版图库图片源。选用无版权/CC0 素材版权安全无保障建议正式展示前自行确认授权范围。12.3 测试与上线分流项目在本地运行调试与正式运行有不同的技术栈边界。可以先自己确认能否在本地完整走通流程再考虑公网部署。如果一定要部署到云服务器建议按以下最小策略数据库连接在配置中改为生产库名称。把 Redis、OSS 等可选依赖做好区分。项目必须关闭开发环境的 Debug 日志输出和 Swagger 文档暴露面。在 Nginx 里为管理后台配置 HTTPS。SpringBoot 服务不要直接暴露在公网端口Nginx 反向代理服务器就好。12.4 后续功能扩展方向这个项目最基本的骨架已经非常完整再往上扩展的空间其实很大。备选方向有用户在订单记录里申请售后或退款时管理后台可加审核处理。支付真实化了接入微信支付和对应的退款回调。之前没有做 SKU 的可以把它扩展为多规格sku商品库存的变化、SKU 列表的渲染、购物车中多规格商品的选择逻辑会涉及一批较高价值练手细节。营销体系把满减、优惠券、秒杀等功能拆开来分析与实现对订单金额计算做扩展。数据看板在管理后台加入 ECharts 图表让管理员看到近 7 日销售额趋势、分类销量比例比单纯列表灵活直观比基本 Table 展示更流程感。13. 总结与下一步这个项目的价值不在于代码量有多大而在于用一个运动户外交易小程序把全栈开发的主线完整串了一遍SpringBoot 后端负责数据和交易Vue3 管理后台负责商品和订单管理微信小程序负责用户交易三端通过 API 协作业务闭环清晰。最先建议验证的内容是“商品发布到小程序首页展示”这一步因为它会把后端可行性、MySQL 连接、接口请求、文件上传路径、后台配置这五个关键环节全部过一遍。一旦跑通整个项目的第一道门槛就已经跨过去了。最容易踩坑的位置我也再来总结一下后端包依赖下载卡住可以先去配置 Maven 镜像小程序端请求不通先检查 baseUrl 和端口不要在没确认网络请求的时候就去改后端代码下单重复不是前端加一个 loading 就行服务端要设计幂等方案。把这几条记住再按这篇顺序走一遍环境准备和链路测试基本到当天晚上就可以做到在自己的电脑上把商品从“后台录入”到“小程序下单”完整跑通。这个目标达成再把订单管理、支付回调、Excel 批量商品管理、图表统计这些扩展一个个接上去运动户外电商中的实战开发经验就会自然积累下来。对要做毕业设计或想入门全栈电商开发的同学来说这个项目值得收藏按这套部署思路练习一遍代码会变成比看教程更扎实的能力。 
长河君 · 2026/9/4 14:25:34 · 阅读 1.2k SpringBoot+Vue3+微信小程序：运动户外商城全栈实战项目解析
这次我们来看一个很典型的全栈电商实战项目基于 SpringBoot Vue3 微信小程序实现的运动户外交易小程序商城。这类项目在课程设计、毕业设计和接私活场景里出现频率很高原因很简单它同时覆盖了后端接口服务、Vue3 管理后台和微信小程序 C 端三个端一条链路下来正好把 Java 全栈开发的完整流程走了一遍而且业务领域是运动户外商品交易贴近真实电商场景不是那种只有增删改查的演示项目。先说这个项目最值得关注的重点后端采用的是 SpringBoot 体系按项目命名对应到较新的 SpringBoot4 大版本如果之前用过 SpringBoot2/3迁移到新版本时最直观的感受是自动配置方式、起步依赖和配置文件的组织习惯有变化管理后台用了 Vue3小程序端则是原生微信小程序开发。也就是说一个项目同时覆盖“用户端小程序商城 商家后台商品订单管理 SpringBoot 后端服务”对于想系统学习前后端分离、小程序上线流程和电商订单闭环的同学来说它的参考价值比单体 CRUD 项目高很多。下面这篇内容我会直接按可复现的思路来拆解项目核心功能是什么、技术栈怎么组织、本地环境怎么准备、三个端分别怎么启动、数据库表怎么设计、核心交易流程怎么跑通、常见部署问题怎么排查。全程没有虚拟机的花活所有步骤都按普通 Windows/Mac 开发机来给。1. 核心能力速览先把项目最核心的信息放在前面方便快速判断它适不适合你。能力项说明项目类型运动户外电商平台 / 微信小程序商城技术栈SpringBoot Vue3 微信小程序后端架构前后端分离SpringBoot 提供 REST API管理后台Vue3 Element Plus 风格后台管理界面用户端微信小程序覆盖商品浏览、购物车、下单、支付流程商城核心功能运动户外商品展示、分类检索、商品详情、购物车、订单、支付、收货地址、个人中心后台管理功能商品管理、分类管理、订单管理、用户管理、轮播图管理、销售数据统计方向数据库MySQL核心表覆盖用户、商品、分类、订单、订单明细、购物车、收货地址、轮播等方向适合场景毕业设计、课程设计、Java 全栈学习、小程序电商项目二次开发启动复杂度三个端分别启动SpringBoot 后端 Vue3 管理后台 微信开发者工具是否支持 API支持SpringBoot 天然提供 REST API 给管理后台和小程序消费需要说明的是显存、GPU 这类参数在这里不存在这个项目吃的是 JDK、MySQL、Node 和微信开发者工具属于“本地开发机就能跑”的传统 Web 全栈项目。2. 适用场景与使用边界在动手部署之前先明确这个项目的适用范围避免很多人装到一半发现和自己想的不一样。这个项目适合这几类人正在做毕业设计或课程设计需要一个功能完整、页面量够、有真实业务闭环的电商系统。想系统学习 SpringBoot Vue3 小程序三端协作的开发方式尤其是搞清楚管理后台和小程序如何共用同一套后端接口。需要快速搭建运动户外类小程序商城原型验证商品展示、购物车、订单流程的可行性。想基于一套现成代码做二次开发替换成自己的运动品牌、骑行装备、露营用品等垂直场景。它不适合的场景也要提前说清楚如果只是想做一个“能发朋友圈展示页面”的静态商城不需要后端和数据库这个项目偏重没必要上 SpringBoot。如果没有微信小程序 AppID也不打算注册测试号小程序端只能体验部分静态页面登录、支付等真实微信能力会受限。如果完全没接触过 Java 和 Maven启动后端时要先补一下 SpringBoot 基础否则配置文件、依赖下载、端口占用这三个问题会轮番出现。使用边界这块必须重点提醒商城项目一旦涉及真实商品、用户手机号、微信授权、订单数据和支付接口就属于真实业务系统。测试阶段建议把支付切换为模拟支付或沙箱等需要上线时微信小程序类目、微信支付商户号、隐私保护协议等都必须按平台要求走。不要拿测试代码直接跑真实交易也不要采集用户信息后随意存储。另外项目代码中的图片素材、品牌 Logo、商品描述若来自网络仅可用于学习演示商用前替换为自有版权素材或者确认过授权的素材。3. 项目架构与技术栈分析从整体架构来看这个项目是标准的前后端分离单体应用结构由一个 SpringBoot 后端同时支撑 Vue3 管理后台和微信小程序两个前端。这里我建议先建立一个全局心智模型管理后台和小程序之间不直接通信都通过 HTTP 调用 SpringBoot 暴露的 REST 接口。管理后台主要负责商品、订单、用户等内容管理运行在浏览器。小程序是 C 端用户真正接触的商城页面运行在微信里。数据库统一使用 MySQLRedis 这类缓存组件如果项目里没引入可以先不装避免环境准备阶段多一个变量。3.1 后端SpringBoot后端是整个项目的核心服务端按项目标题内的技术命名对应 SpringBoot4 方向实际使用中请以项目 pom.xml 里的 spring-boot-starter-parent 版本为准。如果之前写过 SpringBoot迁移到新版本后需要注意几个变化点配置文件方面SpringBoot 新版本依旧支持application.yml但配置项的组织方式更推荐分模块管理。起步依赖的命名习惯保持为spring-boot-starter-*。Java 基础版本建议直接使用 JDK 17如果本机还停留在 JDK 8很可能因为版本兼容问题启动失败。后端在电商项目里最核心的职责是维护商品、SKU、购物车、订单的数据一致性提供小程序端所需的列表、详情、下单接口以及提供管理后台所需的统计、编辑接口。典型的分层结构是Controller 层接收 HTTP 请求、参数校验、返回统一响应结构。Service 层处理业务逻辑比如下单时校验库存、计算金额、生成订单号。Mapper 层操作 MySQL 数据库取决于项目用的是 MyBatis、MyBatis-Plus 还是 Spring Data JPA。Entity / DTO对应的数据实体和传输对象。3.2 管理后台Vue3 Vite管理后台使用 Vue3 构建这一个小节里值得关注的是工程化体验。Vue3 项目现在多数基于 Vite 启动开发模式下热更新非常快。管理后台通常包含的页面方向登录页管理员身份认证。仪表盘商品数量、订单数量、用户数量、销售额等统计卡片。商品管理商品列表、新增/编辑商品、上下架、库存维护。分类管理运动户外分类的树形管理比如“运动鞋”“户外装备”“骑行配件”。订单管理订单列表、订单状态流转待发货、已发货、已完成。用户管理用户列表、禁用/启用账号。内容管理轮播图、公告等运营位维护。如果项目里已经接了 Element Plus 或 Ant Design Vue表单校验、表格分页、弹窗确认这些高频交互都可以直接用组件库实现不需要手写。3.3 小程序端微信原生小程序小程序端是用户真正在微信里看到的部分。使用原生小程序开发意味着页面由 WXML、WXSS、JS/TS 组成组件采用小程序自定义组件或内置组件请求接口统一走wx.request。小程序端主要页面首页顶部搜索、轮播 Banner、推荐商品列表、运动户外分类入口。分类页左侧分类 Tabs 右侧商品列表联动。商品详情页图片轮播、价格、库存、规格选择、加入购物车、立即购买。购物车页勾选商品、修改数量、计算总价、去结算。订单确认页选择收货地址、填写备注、提交订单。订单列表页不同订单状态切换、模拟支付或调用微信支付。个人中心页用户昵称头像、订单入口、收货地址管理、关于我们。小程序端最容易踩坑的地方集中在微信登录态维护和支付模拟。登录时通常需要先调用wx.login获取 code然后把 code 传给后端换取 openid 和自定义 token支付时如果没有商户号建议在测试环境做“模拟支付”按钮把订单状态直接置为已支付方便跑完整个流程。4. 环境准备与本地部署前置条件本地跑通这个项目核心是保证 Java、Node、MySQL 三件套版本兼容。下面是一份通用前置清单。具体版本以仓库内 README 或 pom.xml 为准但按这份准备基本不会出方向性错误。4.1 环境总览组件建议版本方向用途JDKJDK 17 或更高版本运行 SpringBoot 后端MavenMaven 3.6后端依赖管理和打包MySQLMySQL 5.7 / 8.0持久化业务数据Node.jsNode 16 / 18运行 Vue3 管理后台npm / pnpmnpm 9 或 pnpm 8管理后台依赖安装微信开发者工具最新稳定版打开小程序端代码IDEA 或 VS Code不限Java/前端编码调试4.2 安装检查命令后端开发机建议先把 JDK 和 Maven 确认好。Windows 打开 PowerShellmacOS / Linux 打开终端执行java -version mvn -v node -v npm -v预期输出里能看到对应的版本号。如果java -version报错说明 JDK 没装或系统环境变量没配好如果mvn -v报错说明 Maven 没配置或者没有把MAVEN_HOME加到 Path 里。MySQL 安装后建议直接用 Navicat、DataGrip 或命令行工具确认能正常连接mysql -u root -p输入密码后能进入 MySQL 交互命令行就说明数据库服务正常。4.3 数据库准备商城项目启动前基本都要先导入 SQL 脚本。正常的项目结构会提供一个sql目录内部是初始化脚本比如sport_shop.sql。导入方式有两种。方式一命令行导入以 Windows 为例实际路径替换成自己机器的路径mysql -u root -p sport_shop D:/project/sport_shop.sql方式二在 Navicat 中右键数据库 - 运行 SQL 文件选择脚本执行。执行成功后需要检查数据库配置文件里的账号、密码、库名是否和本地一致。SpringBoot 项目的核心配置通常在src/main/resources/application.yml或application.properties里要重点核对这几项spring: datasource: url: jdbc:mysql://localhost:3306/sport_shop?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 你的数据库密码 driver-class-name: com.mysql.cj.jdbc.Driver这里的sport_shop只是示例库名具体以你的 SQL 脚本里的 CREATE DATABASE 名称为准。5. 安装部署与启动方式三端启动先后顺序建议是先后端再管理后台最后小程序端。因为管理后台和小程序都需要调用后端接口提前把服务端跑起来可以避免前端调试时一直报网络错误。5.1 启动 SpringBoot 后端用 IDEA 打开后端目录一般目录结构里会包含src、pom.xml。打开后IDEA 会自动识别 Maven 项目并开始下载依赖。首次下载依赖时间取决于网络环境如果 Maven 下载很慢建议在settings.xml里配置阿里云镜像mirror idaliyunmaven/id mirrorOfcentral/mirrorOf nameAliyun Maven Mirror/name urlhttps://maven.aliyun.com/repository/public/url /mirror依赖下载完成后找到主类。主类通常是项目里带有SpringBootApplication注解的类类名一般是Application、SportShopApplication这种命名。直接右键 Run。后端默认端口在配置里指定常见是8080。启动成功后控制台里会出现 Spring Boot 的启动 Logo接着显示类似这样的日志Tomcat started on port 8080 (http) with context path Started Application in X.XX seconds看到这行日志后端服务就起来了。快速验证接口是否通畅可以在浏览器直接访问http://localhost:8080/api/health或访问项目中某个公开的商品列表接口只要返回 JSON 就说明后端基本没问题。如果项目配置了统一前缀server.servlet.context-path比如/sport-shop那所有接口都要带上前缀。5.2 启动 Vue3 管理后台管理后台目录一般包含package.json打开终端进入该目录先安装依赖npm install如果项目里存在pnpm-lock.yaml或yarn.lock优先使用对应的包管理器pnpm install依赖安装完成后启动开发服务npm run dev默认情况下 Vite 服务会跑在http://localhost:5173控制台会输出可访问地址。浏览器打开后第一步要检查的是登录接口是否通。如果后台页面里所有请求都报 404需要检查项目的前端环境配置文件比如.env.development里的 API 地址VITE_API_BASE_URLhttp://localhost:8080如果后端设置了 context-path还要补全VITE_API_BASE_URLhttp://localhost:8080/sport-shop另外需要处理跨域。调试阶段最快的方式是在后端加 WebMvcConfigurer 配置允许本地跨域下面是一个通用示例实际代码要以项目已有配置为准Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }5.3 启动微信小程序端小程序目录里会有app.js、app.json、pages这类文件。用微信开发者工具导入项目时选择小程序端目录而不是后端或后台目录。最容易被卡住的步骤是 AppID。如果没有已注册的小程序账号可以选择“测试号”。导入后项目里的project.config.json可能会有自己的 appid 配置需要替换成你自己的测试号或正式 AppID。小程序端请求后端的地址配置一般在utils/config.js、api/request.js或app.js的全局变量里设置。如果 I 的真机预览要把localhost改成电脑在局域网中的 IP并在微信开发者工具里勾选“不校验合法域名、web-view业务域名、TLS 版本以及 HTTPS 证书”。下面是一个典型的请求地址配置示例用于说明// utils/config.js module.exports { baseUrl: http://localhost:8080/sport-shop }在开发者工具里编译后小程序页面能正常加载商品列表就说明后端和小程序的链路打通了。5.4 准备一份最小可运行配置针对这种三端项目我强烈建议在本地保留一份最小可运行配置记录内容包含后端端口号和接口前缀。数据库名称、账号密码。Vue3 后台的VITE_API_BASE_URL。小程序端request.js里配置的 baseUrl。本地 MySQL 服务是否开机自启。Maven 镜像是否已配置。把这些信息记在一个local-config.md文件里。换电脑、重装环境、交给同学部署时一份准确的环境记录能省下一个下午的排查时间。6. 数据库设计领域模型与核心业务表电商商城的数据库设计是整套项目业务逻辑的地基。只要订单表、订单明细表和购物车表关系理解了后面的接口测试流程自然顺。下面这些表和字段比较典型。6.1 用户相关表用户表用于保存小程序用户或后台管理用户的信息。字段方向说明id主键openid微信用户唯一标识如果走微信登录nickname昵称avatar头像phone手机号status账号状态启用/禁用create_time注册时间收货地址表关联用户 id保存收货人姓名、手机号、省市区和详细地址。下单时从地址列表选择也可以维护默认地址。6.2 商品相关表商品表保存商品本身的通用信息如名称、主图、价格、原价、库存、销量、上下架状态。分类可以单独建表也可以设计为层级分类比如“运动户外”一级分类下挂“跑步”“骑行”“露营”“健身”等。如果商品有颜色、尺码等多规格属性规范的电商设计里需要一张 SKU 表来维护每种具体规格的库存和价格但很多教学项目的简化做法是直接在商品表里用一个字段存默认库存小程序端只做单规格商品购买。从实际项目演示来看单规格设计可以快速跑通完整流程多规格 SKU 适合后续二次扩展。6.3 购物车、订单与订单明细表购物车表记录用户 id 和商品 id以及加入的数量。订单表是核心中的核心字段大体包括字段方向说明order_no订单号通常由时间戳随机数生成user_id下单用户total_amount订单总金额pay_amount实付金额status待付款/已付款/待发货/已发货/已完成/已取消receiver_name / receiver_phone / receiver_address收货信息create_time / pay_time / ship_time各状态时间戳订单明细表记录每个订单内包含哪些商品、数量、单价。为了方便对账商品名称、图片、单价这些字段建议做冗余存储否则商品修改价格或删除后会丢失历史订单的可读信息。另外简单商品交易场景下不设置运费表建议在小程序设计为“包邮”省去运费计算分支。一个最少可用的数据库建表脚本导向如下。实际需结合项目脚本填写字段以实际项目为准DROP TABLE IF EXISTS t_order; CREATE TABLE t_order ( id BIGINT NOT NULL AUTO_INCREMENT, order_no VARCHAR(50) NOT NULL COMMENT 订单号, user_id BIGINT NOT NULL COMMENT 用户ID, total_amount DECIMAL(10,2) NOT NULL COMMENT 总金额, status TINYINT NOT NULL DEFAULT 0 COMMENT 订单状态:0待付款,1已付款等, PRIMARY KEY (id), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单表;7. 核心交易链路与接口设计这个项目最值得动手调试的部分就是“用户将商品加入购物车发起下单完成状态流转”这一条链路。理顺这条链路后就能理解商城系统里前后端如何协作。一次完整的下单流程至少要经过这几个环节。7.1 商品浏览与加购用户进入小程序后在商品列表页请求后端商品接口后端返回商品列表包含封面图、标题、价格、销量信息。用户在详情页点击“加入购物车”小程序端会发起添加购物车请求请求包含商品 id数量用户标识。由于小程序端没有主动维护登录态通常的做法是用户在小程序启动时先做静默登录调用wx.login获取临时 code传给后端的登录接口后端拿 code 换取 openid 后生成 token 返回小程序后续请求在 header 中携带 token后端根据 token 识别用户。这种模式下购物车接口自然能定位到是哪个用户的数据。7.2 下单与幂等问题这是下单链路里面最容易写出 Bug 的一环。用户从购物车发起结算后端收到请求后要执行的事务里包含校验商品是否存在且为上架状态。校验库存。计算订单金额。扣减库存。创建订单主记录。创建订单明细记录。清空购物车中对应商品。这个流程必须放在数据库事务里最直接的原因是库存扣减和订单创建需要保持一致性。如果先扣库存但订单创建失败库存没了订单也没了用户无法继续购买。真实电商中设计接口时还要考虑一个高频问题用户连点两次“提交订单”会不会生成两个订单解决方向通常是在后端做订单创建幂等或者前端在提交按钮上做 loading 禁用。在课程演示阶段至少做到前端按钮“防止重复提交”点击提交后立即置灰按钮并给后端请求加上像“订单令牌”或“客户端操作流水号”这类唯一标识后端在创建订单前检查该标识是否已经用过从源头避免同一操作生成多个订单。下面给出一段简化版的下单服务接口体实现思路实际项目里实现方案会受 Mapper 等影响这里重点是看事务逻辑Service public class OrderService { private static final Logger log LoggerFactory.getLogger(OrderService.class); Transactional public OrderCreateResult createOrder(OrderCreateRequest request) { // 1. 解析商品ID和数量 // 2. 查询商品列表校验是否上架 // 3. 校验库存不满足则抛出业务异常 // 4. 生成唯一订单号例如 yyyyMMddHHmmss userId 4位随机数 // 5. 插入订单主记录状态置为待付款 // 6. 插入订单明细记录 // 7. 扣减库存 // 8. 删除购物车已选商品 // 9. 组装返回订单号结合微信支付参数返回给小程序 return null; } }拦截重复下单的这个“幂等令牌”也可以放进 Redis 等缓存组件里但显然这里先不引入 Redis 也能完成整套下单链路演示。7.3 支付回调与订单状态流转订单创建成功后是待付款状态。研发环节可以做一个“模拟支付”按钮点击后调用后端的模拟支付接口把订单从待付款流转为已付款。如果是真实微信支付前端需要调用wx.requestPayment并传入后端返回的时间戳、随机串、包名、签名、paySign、签名方式等参数。这个阶段后端会同时向微信支付服务器发送异步通知。异步通知到达后端接口后后端需要验证签名和订单金额确认无误后再把订单状态从待付款更新为已付款。此时必须小心通知到达不一定按顺序同一笔支付可能通知多次对通知处理要设计成幂等。稳妥的写法思路是在回调处理中先根据 order_no 查询订单状态如果当前订单已经是已付款就直接返回成功不再次处理。这里的连接关系可以这样理解小程序端不是直接把订单改成已付款而是微信支付先把结果通知到后端由后端更新状态后再通知小程序刷新订单列表。7.4 订单列表与售后状态订单列表页面需要按状态标签过滤例如待付款、待发货、待收货、已完成以及取消/退款。小程序端通过status参数请求后端订单列表接口后端按用户 id 和状态查询。如果项目需要发货管理后台中增加“发货”操作即可填写物流单号后订单状态流转到待收货用户确认收货或发货后延迟自动确认后订单状态流转到已完成。8. 三端接口调用与功能验证启动完成后本人建议按以下顺序做一套完整功能验收这套顺序能够把前后端链路中大多数问题暴露出来。8.1 验证管理后台商品发布在 Vue3 管理后台登录进入商品管理。新增一件商品比如“户外轻量跑步背包”填好分类、价格、库存、上传封面图、上下架状态为上架提交保存。到商品列表中确认新商品显示。这里一个关键点是管理后台发布商品后小程序端必须能看到该商品这依赖两边查询的是同一张商品表并且商品处于上架状态。如果小程序端刷新后看不到数据优先检查请求是否成功、商品上下架状态是否过滤掉以及小程序请求的后端地址和当前后端是否匹配。8.2 验证小程序商品浏览与加购在小程序端首页下拉刷新确认商品列表出现刚才新增的商品。打开商品详情页点“加入购物车”底部导航进入购物车页面确认对应商品数量和总价正确。如果请求失败打开开发者工具的控制台和 Network 面板查看请求返回码。最常见的问题是没有勾选“不校验合法域名”或 baseUrl 写错。8.3 验证统一下单流程在购物车内勾选刚才的商品点击去结算。这一步会跳转到订单确认页需要选择收货地址。如果没有地址先新增一个测试地址。提交订单后在订单列表页确认出现了“待付款”状态订单。测试环境没有真实微信支付通道时点击“模拟支付”或“直接完成支付”按钮确认订单状态翻转为“待发货/已发货”。然后在管理后台的订单管理里能搜到这单订单点发货并填入物流号。小程序端订单列表里这单状态变为“待收货”。如果项目没有发货管理可以直接在后台把订单标注为已完成重点能看到状态链路已经跑通。8.4 用 curl 验证后端接口后端服务启动后完全可以通过 curl 快速验证接口可用。下面是一个通用的 curl 模板实际 URL 和参数以后端 Controller 为准curl -X GET http://localhost:8080/api/product/list \ -H Content-Type: application/json查看返回 JSON 是否包含商品列表数据。如果接口要求登录态就需要先调用登录接口获得 token然后带上 Authorization 头curl -X POST http://localhost:8080/api/user/login \ -H Content-Type: application/json \ -d {code:wx_login_code_placeholder}响应里如果包含token字段下次请求带上curl -X GET http://localhost:8080/api/cart/list \ -H Authorization: Bearer 你的token9. 接口 API 设计参考与批量任务扩展虽然项目本身是电商系统但也有后端 API 提供给不同端调用下面就接口内容做一个组织和解释。9.1 接口分组建议为了让管理后台和小程序区分也方便管理新建一个模块时接口地址风格可以分成三组小程序端接口/api/user/login、/api/product/list、/api/cart/add、/api/order/create。管理后台接口/admin/product/page、/admin/order/page、/admin/dashboard/statistics。微信回调接口/notify/wxpay。通过/admin前缀可以将需要管理员权限的接口统一保护起来避免和普通用户接口混在一起。下面是一个通用 Controller 方法体示例RestController RequestMapping(/api/product) public class ProductController { GetMapping(/list) public Result list(RequestParam(defaultValue 1) Integer page, RequestParam(defaultValue 10) Integer limit) { // 返回分页商品列表 return Result.ok(); } }9.2 接口鉴权SpringBoot 体系里常见方案是使用拦截器或过滤器来统一校验用户 token。逻辑上一般是这样小程序登录成功后后端把 session 或 token 与用户 id 绑定。后续每个请求先从请求头中提取 token如果 token 不存在或已过期则拦截直接返回 401让小程序重新登录。管理中台和商品列表接口是否需要鉴权要看项目的开放程度。公开浏览页面不登录也要能看下单和购物车则需要登录态。9.3 批量导入与任务扩展电商项目里批量导入业务常见的是“批量上架商品”。后台如果只有几十个商品手工录入可以接受。商品数量到几百个时最好提供一个 Excel 导入入口。这个能力在管理后台里不一定是必需功能但按演示价值考虑值得扩展实现。批量导入的一个参考流程先设计一个导入模板包含商品名称、分类、价格、库存、上下架状态等必要字段。后台解析 Excel 时先做字段校验比如价格不能为负数库存不能小于 0。校验通过后循环写入商品表记录成功和失败的行数。将导入结果返回给前端展示“导入成功 X 行失败 Y 行失败原因明细”。用 Java 解析 Excel 通常用到 EasyExcel 库。这段扩展比较适合作为二次开发练习能让表结构设计与后台列表交互密合起来。10. 资源占用与性能观察思路这个项目不是 AI 推理模型但资源占用观察仍然重要。启动三端服务时IDE、Node、MySQL、微信开发者工具同时开着中低配置电脑可能会遇到内存不足。实操过程中可以打开任务管理器或活动监视器观察。具体观察思路后端 SpringBoot 运行时会占用 JVM 堆内存默认情况下 JVM 会根据机器内存自动设置最大堆。如果本机内存只有 8GB同时又运行了 MySQL、微信开发者工具和 IDE很容易整体卡顿。这时可以给后端设置内存启动参数java -Xms256m -Xmx512m -jar sport-shop.jarVue3 后台的npm run dev启动后进程内存占用并不高通常在几百 MB 范围内。但如果 Node 进程卡死优先检查node_modules是否安装完整删除后重新npm install。MySQL 本身占用比较稳定但如果不生产环境需要关注慢查询。订单列表、商品列表、销量统计等页面分页要加好索引。微信开发者工具本身比较吃内存如果要模拟器页面同时开着实测体感上会更明显。建议运行小程序端和 Vue3 后台时不要同时开太多无用的开发者工具窗口。接口性能优化方向可以从商品列表开始商品列表要有分页字段避免一次查询全部数据。首页用懒加载图片页面滚动到可视区域再加载封面可显著降低网络消耗。如果用户浏览频繁商品详情可以用热点缓存但商品库存和价格还是要强一致读取。11. 常见问题与排查方法三端项目部署过程中问题通常集中在环境、网络、路径三个方面。整理一份排查清单基本能覆盖大多数情况。问题现象可能原因排查方式解决方案SpringBoot 启动失败端口被占用查看控制台日志报错会直接指出 Port 8080 was already in use换端口在 application.yml 里改server.port数据库连接失败数据库名、用户名、密码不匹配查看日志里的 SQL 异常检查 application.yml修正数据库连接配置控制台出现中文乱码控制台编码不是 UTF-8IDEA 的 VM 参数加-Dfile.encodingUTF-8调整运行时编码Maven 依赖下载失败网络问题或镜像问题检查本地 maven 仓库是否有 lastUpdated 文件配置阿里云 Maven 镜像或检查网络Vue3 后台空白页Node 版本不兼容或依赖缺失查看浏览器控制台报错使用 Node 16删除 node_modules 重新 npm install小程序请求接口报 403 / timeout域名校验开关未关或地址写错打开开发者工具的 Network 面板勾选“不校验合法域名”确认 baseUrl 正确小程序请求后端地址在真机上失败localhost 指向了手机自身手机和电脑连同一 Wi-Fi将地址改为电脑局域网 IP重启开发者工具或换用 IP 访问商品图片不显示图片上传路径是磁盘绝对路径或图片服务器地址不可访问查看图片请求 URL判断后端是否提供静态资源映射为后端增加静态资源映射地址配置统一走本地或 OSS下单提示库存不足库存字段没有在扣减时判空或商品未上架管理后台看商品库存状态手动调整测试库存后再下单微信登录失败AppID 是测试号但后端依赖正式 appid 配置看后端日志中微信接口返回信息在配置中使用测试号对应的 AppSecret无法调用真实微信接口时使用 mock 登录订单创建重复用户双击提交按钮看数据库订单是否存在两条相同订单前端加 loading 禁用后端做幂等处理SQL 脚本导入报错数据库字符集或表已存在看报错行号如果表已存在DROP 后重新导入注意跑测试环境前确认可以重建表12. 最佳实践与合规使用建议12.1 开发期工程化建议先按小数据量跑通全流程再把数据量扩大。不要一开始就在后台录几十个商品然后测试下单这会干扰问题定位。第一次建议只录入 2 到 3 个商品走完“加购-下单-支付-发货-完成”链条后再批量补数据。商品和分类建议用树形思维组织。运动户外商品一般会挂一级分类“运动鞋靴”“运动服”“户外装备”“健身器材”每个一级分类下再设二级分类。新版本若要新增分类字段先规划好 code 值和展示顺序避免出现后台看到分类但小程序首页无法显示。多人开发时如果遇到过代码或数据处理这类问题很容易产生严重冲突尤其要提醒注意避免上面出现的由于多人各自本地修改产生 merge 冲突这种场景出现可以统一约定严格后端接口命名。12.2 数据与隐私合规项目涉及用户订单、手机号、收货地址这些都属于敏感数据。管理后台登录密码绝不能硬编码在配置里用户密码要加密存储。后端接口应该限制接口不允许绕过权限尤其是发货、删除商品这类接口都应该校验当前操作者的管理员权限。微信小程序正式上线前必须填隐私保护指引收集手机号、地址时要明确告知用途。开发调试阶段可以使用假地址和假手机号不要把真实测试用户的微信号或地址信息存储在公网上。商品图片等方面建议只用白底自拍照或合法购买的正版图库图片源。选用无版权/CC0 素材版权安全无保障建议正式展示前自行确认授权范围。12.3 测试与上线分流项目在本地运行调试与正式运行有不同的技术栈边界。可以先自己确认能否在本地完整走通流程再考虑公网部署。如果一定要部署到云服务器建议按以下最小策略数据库连接在配置中改为生产库名称。把 Redis、OSS 等可选依赖做好区分。项目必须关闭开发环境的 Debug 日志输出和 Swagger 文档暴露面。在 Nginx 里为管理后台配置 HTTPS。SpringBoot 服务不要直接暴露在公网端口Nginx 反向代理服务器就好。12.4 后续功能扩展方向这个项目最基本的骨架已经非常完整再往上扩展的空间其实很大。备选方向有用户在订单记录里申请售后或退款时管理后台可加审核处理。支付真实化了接入微信支付和对应的退款回调。之前没有做 SKU 的可以把它扩展为多规格sku商品库存的变化、SKU 列表的渲染、购物车中多规格商品的选择逻辑会涉及一批较高价值练手细节。营销体系把满减、优惠券、秒杀等功能拆开来分析与实现对订单金额计算做扩展。数据看板在管理后台加入 ECharts 图表让管理员看到近 7 日销售额趋势、分类销量比例比单纯列表灵活直观比基本 Table 展示更流程感。13. 总结与下一步这个项目的价值不在于代码量有多大而在于用一个运动户外交易小程序把全栈开发的主线完整串了一遍SpringBoot 后端负责数据和交易Vue3 管理后台负责商品和订单管理微信小程序负责用户交易三端通过 API 协作业务闭环清晰。最先建议验证的内容是“商品发布到小程序首页展示”这一步因为它会把后端可行性、MySQL 连接、接口请求、文件上传路径、后台配置这五个关键环节全部过一遍。一旦跑通整个项目的第一道门槛就已经跨过去了。最容易踩坑的位置我也再来总结一下后端包依赖下载卡住可以先去配置 Maven 镜像小程序端请求不通先检查 baseUrl 和端口不要在没确认网络请求的时候就去改后端代码下单重复不是前端加一个 loading 就行服务端要设计幂等方案。把这几条记住再按这篇顺序走一遍环境准备和链路测试基本到当天晚上就可以做到在自己的电脑上把商品从“后台录入”到“小程序下单”完整跑通。这个目标达成再把订单管理、支付回调、Excel 批量商品管理、图表统计这些扩展一个个接上去运动户外电商中的实战开发经验就会自然积累下来。对要做毕业设计或想入门全栈电商开发的同学来说这个项目值得收藏按这套部署思路练习一遍代码会变成比看教程更扎实的能力。