SpringBoot+Vue3化妆品电商小程序：交易链路与状态机实践

化妆品交易小程序这类在线销售系统最让人没底的不是写几个商品列表和下单接口而是把用户端、管理后台、支付回调、小程序发布全部串成一条能真正跑通的交易链路。项目标题里的 SpringBoot4 Vue3 常见理解是后端用 Spring Boot 技术栈提供交易接口管理后台用 Vue3小程序端负责真实用户的下单入口。下面我按一个可上线的化妆品电商平台来拆新手照着做能少绕弯已经写过基础 CRUD 的人也可以看后面的状态机、幂等和上线检查清单。1. 先弄明白它到底是一个官网、一个商城还是一套完整前后台系统很多人第一次看到这个标题时会以为要同时开发三个系统。其实更准确的理解是一套化妆品商城被拆成三个端彼此配合而不是三套彼此无关的代码。1.1 化妆品商城和普通官网的差异官网的重点是展示品牌、内容和入口用户浏览完可以离开。商城不一样用户进入之后会产生加购、下单、支付、查看物流、申请售后等一系列动作这些动作会让商品库存、订单状态、资金状态发生变化。后端不能只把数据查出来返回给前端还要管理这些状态之间的流转是否合法。化妆品品类还有一个特殊性它不只是“一件商品”的描述。同样是口红有色号、规格、包装不同同样是护肤套装有适用肤质、容量、赠品。所以建表时不能只有简单的商品表还要把商品和 SKU 拆开。1.2 一套完整系统应该拆成哪三块按实际落地顺序我建议拆成用户端、管理后台、后端服务三块用户端运行在微信小程序里面向消费者做商品浏览、搜索、加购、下单、支付、售后申请。管理后台运行在浏览器里面向运营和客服用 Vue3 开发做商品上下架、库存调整、订单处理、退款审核。后端服务用 SpringBoot4 标题对应的 Spring Boot 技术栈做提供 REST API接入 MySQL、Redis处理微信登录和支付回调。如果你的标题来自课程项目或比赛这套拆分也够用。它可以避免“所有页面都堆在小程序里”的失控状态也方便以后把管理后台从 Vue3 换成其他技术栈时不牵连业务逻辑。1.3 什么才算一个真正跑通的最小闭环判断一个商城是不是至少能跑通不要只看首页多好看要看下面的链路是否成立用户在小程序里看到商品列表。点开商品详情看到不同 SKU 的价格和库存。加入购物车购物车能计算总价。提交订单后端扣库存。发起微信支付支付回调后订单状态变成已支付。管理后台能看到订单并发货。用户收到货或申请售后售后单状态被记录。只要其中一条断掉整个项目就是“能打开但不能用”。2. 动手前先定模块、版本和核心表别急着写第一行代码我见过不少项目一上来就写 Controller结果写到订单模块时发现没有地方存商品快照也没有唯一订单号只能回头改表。先花半天时间把版本、目录和库表定下来比后面加班修数据要划算。2.1 SpringBoot4 这个版本说法怎么处理项目标题里写的是“SpringBoot4”实际生成项目时我建议把它理解成“选当前较新、稳定的 Spring Boot 技术路线”。落地时先确认几件事JDK 版本是否和 Spring Boot 匹配。MyBatis 或 MyBatis-Plus、MySQL 驱动版本是否兼容。Maven 或 Gradle 构建是否正常。是否有 Redis、OSS、微信支付 SDK 等依赖冲突。不要为了版本数字去追最前沿。很多商城项目核心用的还是 Spring Boot 3.x 或 2.7 的稳定写法代码结构差别不大。真正影响开发效率的是依赖版本是否一致、JDK 是否统一、启动时是否缺包。2.2 数据库核心表先定下来一套最小可运营的化妆品商城至少需要这些业务域业务域核心表作用商品中心product、product_sku、product_image、brand存商品标题、图文、SKU、价格、图库库存中心inventory、stock_log存实时库存和出入库记录会员中心member、member_address存用户加密身份、收货地址交易中心orders、order_item、cart存订单主表、商品快照、购物车支付/售后payment_order、refund_order、aftersale存支付回调、退款、售后状态营销中心coupon、coupon_user存优惠券和领取记录商品和 SKU 是一定要拆开的。一个商品可以有很多 SKU每个 SKU 有自己的价格、库存、规格标识。订单明细里不能只存 SKU ID还要把当时的商品名称、图片、价格、规格快照存进去。这是为了防止以后商家改价或删除商品后老订单仍然能正常显示。2.3 三端开发环境准备本地开发不需要特别高配但建议把环境固定下来后端JDK 17 或对应 Spring Boot 支持版本、MySQL、Redis。管理后台Node.js、npm 或 pnpm、Vite。小程序端微信开发者工具。前后端联调准备好统一格式的返回体比如code、message、data。联调时最忌讳每个接口返回结构不一样。小程序的请求封装、Vue3 管理后台的 axios 拦截器都要统一处理登录失效和错误码。2.4 先写一个最简启动流程不要第一天就把商品详情页、优惠券、积分都做完。我推荐按这个顺序启动初始化数据库建好 product、orders、member 等核心表。后端启动先提供“登录、商品列表、商品详情、下单、查询订单”这几个接口。小程序端写好请求封装能完成一次注册或模拟登录。Vue3 管理后台先做商品列表和订单列表。接口跑通后再逐步加入支付回调、售后、营销等功能。这个顺序能让每一步都有验证点不会写到最后才发现整体设计有问题。3. 用户端核心交易流程从 SKU、购物车到支付回调用户端是用户能感知到的部分但真正决定商城能不能用的是交易流程里的数据模型和状态流转。3.1 商品列表和详情接口不要只查一张表如果商品有规格详情接口至少要做一次聚合查出商品基本信息查出它的所有 SKU查出商品图片列表查出当前商品可用的优惠信息。不要在小程序端拼多个接口一次请求拿完整数据体验更稳定。商品列表接口要返回的字段也要克制通常只需要商品 ID商品名称主图最低价格销量或热度上架状态价格不能直接用一个固定字段因为同一个商品不同 SKU 价格可能不同。列表页展示的是最低价格或价格区间。点进详情后再按所选 SKU 确定最终价格。3.2 加购只是轻操作真正复杂的是下单购物车可以直接在后端建一张 cart 表也可以先用 Redis 缓存。我的建议是至少在后端留存一份数据这样用户换手机也不会丢。购物车合并时要处理几个细节同一用户把同一 SKU 再次加购时是数量加一还是重复新记录。商品下架后购物车条目是否可以继续结算。商品价格变化后购物车里显示旧价还是新价。结算时已经不允许购买的 SKU 要去除或提示。这些细节如果不在购物车接口里做就会漏到订单接口里。用户被提示“商品已失效请返回购物车修改”时体验已经很差了。3.3 下单要解决三个问题库存、幂等、事务下单接口是整个系统的核心至少要处理库存扣减、重复提交和事务一致性三个问题。库存扣减不能直接写成“先查询库存再判断是否大于 0再 update”。高并发场景下很容易超卖。更简单稳妥的做法是使用数据库的原子更新UPDATE product_sku SET stock stock - 1 WHERE id #{skuId} AND stock 1;影响行数为 0 就说明库存不足。批量场景可以一次减多个数量但要保证条件里库存足够。重复提交的防护可以这样做用户点击提交按钮时前端生成一个clientOrderNo后端在订单表上对业务单号加唯一约束。同一请求重复到达时数据库唯一键会挡住第二次插入而不是生成两笔订单。下单时还要开启事务。扣减库存、创建订单主表、创建订单明细、删除购物车记录这些操作要么全部成功要么全部回滚。没有事务时最常见的现象就是“订单创建了但库存没扣”或者“库存扣了但订单明细查不到”。3.4 订单状态机不能只靠 if else 乱改订单状态最好先定义清楚状态含义可以流转到什么状态PENDING_PAY待支付PAID、CANCELEDPAID已支付SHIPPED、REFUNDINGSHIPPED已发货FINISHED、REFUNDINGFINISHED已完成无CANCELED已取消无REFUNDING退款中REFUNDEDREFUNDED已退款无在代码里不要允许从已取消直接变成已支付也不要从已退款重新发货。状态流转可以用状态机模式也可以用统一的updateOrderStatus方法每次流转都记录操作日志。3.5 支付回调必须做幂等商城对接微信支付后微信支付平台会通过异步通知把支付结果发送到后端接口。这个通知可能会重复发送后端如果不做幂等同一个订单可能被重复处理成已支付。最基础的处理顺序是收到回调后先校验签名。按订单号或交易号查询支付单是否存在。如果支付单已经处理过直接返回成功。如果支付单没有处理再更新订单状态。只有整个业务更新成功后才返回给微信支付平台“成功”的响应。这里常见的一个坑是只会在 Controller 里打印日志不会判断重复通知。调试时看不出问题等到真实交易或压测时就会出现订单金额和状态不一致的情况。3.6 售后单不要和订单状态混在同一张表很多新手会直接在 orders 表上加一个 refund 状态字段。刚上线几天看不出问题一旦出现多次部分退款、换货、仅退款场景字段就不够用了。更合适的方式是单独建售后/退款单一张售后单关联一个订单记录售后类型、原因、状态、处理时间、管理员备注。这样可以保留完整的售后历史不影响订单主表的主流程状态。4. Vue3 管理后台商品、订单、权限三块最值得做管理后台面向运营人员。它不是给消费者看的展示站不需要花哨动画需要的是信息清晰、操作顺手、权限可控。4.1 Vue3 在后台里具体承担什么如果你用 Vue3 开发管理后台常规组合会是这样Vue3 Vite 做基础框架。Vue Router 管理菜单页面跳转。Pinia 管理登录用户信息、权限状态、全局配置。axios 做请求封装。Element Plus 或其他组件库做表格、弹窗、表单。管理后台的页面通常包括商品管理、类目管理、订单管理、会员管理、售后管理、优惠券管理、数据看板、系统管理。第一个版本不用全部做完但商品、订单、售后这三个模块必须有。4.2 商品上下架要和库存联动运营在管理后台编辑商品时最容易出的问题是商品下架后前端购物车还能不能提交这个商品小程序端下单时如果不对商品状态做校验用户可以把已经下架的 SKU 提交成订单。更好的做法是商品列表只展示上架状态。商品详情和下单接口都校验product.status和product_sku.status。用户购物车里如果有失效商品在结算接口里返回具体失效原因。后台修改库存后前端能看到最新库存但不必让运营每次刷新都重新拉全量数据。4.3 订单管理不只是展示列表真正运营时订单管理会遇到搜索、导出、发货、退款、备注、客服改价等需求。后端要为订单模块单独设计查询条件订单号、用户昵称、手机号、订单状态、下单时间范围、支付时间范围。订单列表返回的数据最好带上商品缩略图、订单总额、实付金额、支付方式、支付时间、收货人信息。运营每天看到的订单可能很多列表要支持分页批量导出时还要注意一次性导出数据量过大导致接口超时的问题。4.4 权限可以先从简单 RBAC 开始管理后台不是所有人都能访问。至少应该区分三种角色超级管理员可以配置系统、管理所有模块。运营可以编辑商品、处理上下架、查看订单。客服只能查看和处理售后、退款。前端菜单根据角色动态生成不行的话至少要在后端接口做权限校验。只把按钮隐藏但接口不校验用户在浏览器控制台直接调用接口还是能越权这是最基础的安全问题。5. 小程序端接入与发布域名、登录、版本一个都不能漏很多商城项目在本地浏览器里跑得很顺一到微信开发者工具就报错。问题往往不在代码逻辑而在微信平台规范。5.1 小程序端用原生还是 Vue3 技术项目标题里强调 Vue3通常管理后台用 Vue3小程序端可以选原生微信小程序也可以用 uni-app 这类 Vue 语法兼容方案。如果你希望一个人同时维护管理后台和小程序用 Vue3 语法写小程序可以降低学习成本。但要注意原生小程序的页面生命周期、组件事件、路由跳转和管理后台不太一样不能直接把 Vue3 管理后台代码搬进小程序。如果时间紧、只要求上线那么用原生小程序写商城基础功能也完全够用。关键在于接口统一前端技术栈只影响页面开发方式不影响商品、订单、支付这些后端业务。5.2 request 请求和合法域名在微信小程序里正式环境的网络请求要求使用 HTTPS并且域名需要配置到微信公众平台后台。开发时可以在开发者工具里勾选“不校验合法域名”但真机体验版和正式上线时必须处理好。建议从一开始就把接口地址统一放到一个配置文件里不要散落在每个页面里。本地开发用一个 baseURL测试环境用另一个 baseURL发版前再切到正式环境。最常见的白屏问题就是因为小程序请求了没有配置的域名或未备案地址。5.3 登录态处理小程序登录通常流程是小程序调用wx.login()获取临时 code。小程序把 code 发给后端。后端调用微信官方接口用 code 获取用户的 openid 等信息。后端生成本系统会话 token 返回给小程序。小程序后续请求都带上 token。不建议把用户手机号直接存为明文也不要在接口里直接传递用户唯一标识当作认证凭证。后端要统一拦截未登录请求并在登录态过期时返回统一错误码前端收到后跳转登录或重新登录。5.4 版本发布和审核注意小程序代码写完后要经过“上传代码-体验版-提交审核-发布”的流程。在上传代码前要检查是否已经切换到正式接口域名。是否关掉了开发者工具里的调试绕过。是否有测试数据留在页面上。商品图片、文案是否合规尤其是化妆品不能使用明显夸大宣传的说法。版本描述和功能说明是否和实际页面一致。审核被驳回时不要反复硬提先看驳回原因。很多驳回原因是类目、医疗功效描述、诱导分享、虚拟支付问题而不是代码功能本身。6. 经验向排查顺序与上线前检查清单项目报错时不要凭感觉乱改代码。我建议按下面的顺序排查能节省大量时间。6.1 项目跑不起来先从环境查起如果前端访问不到接口先检查后端是否真的启动成功。如果后端启动失败先看端口是否被占用、MySQL 是否启动、Redis 是否启动、数据库配置里的地址密码是否正确。这里常见的问题是电脑之前启动过别的服务占用 8080 端口或者 MySQL 连接失败后 Spring Boot 启动到一半就退出。可以先在浏览器直接访问一个最简单的后端接口排除前端问题。6.2 接口返回慢或超时先看是否有循环请求和 N1 查询商品详情如果每查一个 SKU 都单独发一条 SQL会很容易出现接口慢。建议用关联查询或批量查询把数据组合好再返回。Vue3 管理后台里如果表格数据量很大不要一次性拉全量。先做后端分页再做前端搜索条件。不要试图把所有历史订单都返回给前端再由前端做筛选。6.3 订单状态不一致时先查事务和幂等订单创建了但库存没扣大概率是事务没有生效或扣库存代码在事务之外。支付回调重复处理后订单金额不对大概率是没有做幂等判断。排查时可以按顺序看后端日志里有没有异常。数据库里有没有唯一约束。下单接口是否开启事务。支付回调里是否先查支付单状态。是否有定时任务并发处理同一个订单。6.4 小程序端发版后没变化先看缓存和版本号微信小程序在一定情况下会使用旧版本缓存。开发者工具预览正常用户手机上却是旧页面通常是代码版本号没有递增或者发布后没有等待足够时间再测试。正式发布前最好把小程序前端版本号和后端接口版本号分开记录。小程序更新后如果后端接口不兼容不能只靠前端发布还要考虑旧版本用户怎么办。6.5 不建议急着上生产的表现如果你的项目还是课程阶段或比赛阶段不建议一上来就照搬完整的生产方案。但如果你准备让它接受真实用户和交易至少要补上这些数据库定期备份。后端日志按天切分。支付和退款操作有审计记录。管理后台有操作日志。库存负数有告警。批量任务有失败重试。真实运营环境里用户不会按你预设的完美路径走。有的人会连点两次支付按钮有的人会在发货后立刻申请退款有的人会同时开多个小程序端加购同一件限购商品。交易系统能不能稳定不取决于功能列表有多长而取决于状态、幂等和边界是否处理好。我个人更建议先把“商品浏览-下单-支付-管理后台发货”这条最窄链路跑稳再一步步加优惠券、积分、会员、售后。商城项目做到最后真正难的不是新增页面而是旧数据和状态不冲突。希望这份梳理能让你在动手前先规避掉最基础、也最容易返工的那一批问题。