1. 项目缘起与定位护肤垂直品类为什么值得单独做一个小程序这个项目最开始是朋友工作室接的一个毕业设计需求甲方要求很明确做一个“精致护肤购物系统”载体必须是微信小程序后端要求能用 Java 技术栈实现最好还能带一套管理后台。当时市面上通用的电商小程序模板很多但直接套模板大概率会在答辩时被问倒尤其是“精致护肤”这四个字不是简单的换皮商城能覆盖住的。所以我没有急着写代码而是先花了大概一周时间把需求边界定清楚把“护肤购物”拆成几个具体的差异化场景再决定系统怎么设计。先说说为什么选微信小程序而不是 H5 或者独立 App。护肤品的消费决策链路和买普通日用品不太一样用户会反复查看成分表、看肤质适配、比对博主测评导致整个浏览到下单的过程往往不是一次完成而是分多次、跨多个时间段回来。小程序“用完即走、微信内直接打开”的特性天然吻合这种非连续的决策场景。用户在一篇公众号推文里种草了一款精华顺手点小程序查看详情、加入购物车过两天在聊天列表里划回来付款这个路径比打开独立 App 要顺滑得多。另外对商家来说小程序不需要用户注册账号就能通过微信授权建立身份体系冷启动门槛低配合微信支付的闭环也能省掉很多传统电商的跳转流失。然后是“精致护肤”这个垂类到底和普通电商有什么不同。我梳理下来主要有四点商品规格不是简单的“颜色尺码”而是“容量大小 肤质适配 套装组合”比如 30ml 和 50ml 的同一款精华价格、库存、优惠策略都可能完全独立。用户需要看到详细成分、使用说明、注意事项这类非结构化内容占比远高于服装数码类商品。复购周期明显护肤品的消耗周期通常在 4-8 周系统需要支持收藏、会员优惠、积分抵扣这类偏运营的功能。买家的评价数据对决策影响极大评价里需要带肤质标签、照片、点赞回复等互动维度。这些差异直接决定了我的数据库设计、页面结构和接口定义方式。我见过很多套壳商城项目的通病商品表只有名称、价格、库存、图片四个字段评价就是一张单向写死的表购物车和订单模块也是直接抄通用电商的 CRUD 模板。这类系统展示演示还行一旦面对真实的护肤消费场景基本是没法用的。项目范围我是这么划定的C 端微信小程序负责用户登录、逛首页、看商品分类和详情、加购、结算下单、支付、查看订单、评价后端管理端负责商品上下架、库存管理、订单发货、退款处理、数据看板。前后端完整闭环不做多余的东西比如社区种草、直播带货这类功能虽然听起来炫酷但会大幅拉长开发周期对毕业设计或早期上线验证来说意义不大。目标用户画像也定了以 20-35 岁女性为主力对肤质、成分有一定敏感度愿意花时间在详情页做功课价格敏感但不是纯低价导向。整个系统的页面色调、组件风格、文案语气也都是围绕这个用户群体去调的。这一点在后面的页面设计部分会详细说。2. 整体技术架构设计与选型取舍技术选型从确定开发方式那一刻开始就要想清楚。微信小程序的开发姿势大概分三派原生小程序WXML WXSS JS/TS、跨端框架uni-app、Taro、低代码平台。这个项目我毫不犹豫选了原生小程序理由是第一作为“设计与实现”类型的课程设计或毕设原生开发能把微信生态的机制讲得更清楚答辩时更有东西可说第二护肤购物系统的页面主要就是列表、详情、表单这类常规场景原生开发完全够用不需要引入跨端框架的编译复杂度第三uni-app 这种框架一旦踩到平台差异的坑排查的难度比对原生要高一截反而浪费时间。后端技术栈用了 Spring Boot 3 MyBatis-Plus MySQL 8 Redis。选 Spring Boot 没有太多悬念Java 技术栈里这对组合最成熟社区资料也多遇到问题基本都能搜到现成答案。MyBatis-Plus 相比原生 MyBatis 省掉了很多重复的 CRUD 代码对单人开发的节奏非常友好。Redis 的用途集中在三个地方Session 登录态缓存、购物车临时数据、订单防重令牌。整个系统的前后端交互模型是这样的小程序端只负责渲染和收集用户操作所有业务逻辑都通过 HTTP 接口调后端完成。没有采用云开发那种把小程序的数据库操作直接暴露给前端的方式因为“设计与实现”这个课题本身需要呈现一个完整的分层架构而且云开发的服务商锁定问题在一个长期项目中是很现实的隐患。数据库设计是这次项目的核心部分我直接放几张核心表的设计思路用户表主键、微信 OpenID、昵称、头像、手机号、肤质类型干性/油性/混合/敏感、生日用于会员生日礼、积分余额、会员等级、创建时间。把肤质类型直接冗余在用户表上是为了方便商品列表做“按肤质推荐”的查询不需要再单独查一张用户画像表。商品表主键、类目 ID、商品名称、副标题、主图、详情富文本、成分列表JSON 字符串存储例如 [{name:烟酰胺,purpose:美白提亮,concentration:5%}]、适用肤质JSON 数租、原价、现价、总库存、销量、上下架状态、排序权重。成分和适用肤质用 JSON 字段存储虽然违反第三范式但这两个字段的读取频率远大于修改而且格式是半结构化的拆表反而让代码更复杂。SKU 表主键、商品 ID、规格名称如“30ml”“50ml”“油皮专用装”、价格、库存、SKU 图、是否默认选中。护肤品的多规格逻辑在这里和通用电商完全一样但要注意的是每个 SKU 的价格可能差异很大必须用独立的 SKU 层来处理不能直接挂在商品表上。购物车表ID、用户 ID、商品 ID、SKU ID、数量、选中状态、添加时间。选了 Redis 做热数据而不是单纯依赖这张表因为购物车是高频读写场景每次都打 MySQL 没有必要但最终结算时必须以 MySQL 数据为准。订单表订单号、用户 ID、商品总金额、优惠金额、实付金额、运费、支付方式、支付流水号、订单状态、收货地址快照、创建时间、支付时间、发货时间、完成时间、关闭时间。订单状态我用一个有序的状态机来管理待付款、已付款/待发货、已发货/待收货、已完成、已取消、售后中、已退款。状态流转只允许前进或按特定路径回退不允许任意跳转这是订单系统的第一原则。订单明细表订单号、商品 ID、SKU ID、商品名称快照、规格快照、单价快照、数量、小计金额。快照字段是必须的因为商品信息后续可能被修改或删除订单不能跟着变。评价表评价 ID、订单号、用户 ID、商品 ID、评分、评价内容、晒图JSON 数组、肤质标注、点赞数、是否置顶。带肤质标注是护肤类购物系统的标志性功能其他品类的评价体系里很少会单独拆一个字段。公共字段如 create_time、update_time、deleted 我全部采用逻辑删除而非物理删除这样在回溯订单问题时能拿到完整的数据链。整体架构图如果非要说就是标准的三层表现层微信小程序页面 - 业务逻辑层Spring Boot 的 Service 层 - 数据访问层MyBatis-Plus 的 Mapper外加 Redis 作为缓存加速。没有引入消息队列、分布式事务这些重组件因为这类系统在初期阶段并不需要引入只会增加学习和部署成本。3. 小程序端页面结构与核心交互实现小程序端的页面规划直接对应着用户的核心动线登录/授权 - 首页逛 - 分类找 - 详情看 - 购物车管 - 结算付 - 订单查 - 评价晒。我按照这个动线把页面分成 tabBar 页面和普通页面。tabBar 用了四个首页、分类、购物车、我的。商品详情页、订单列表、结算页、评价页等都是普通页面。3.1 登录态的处理与唤醒微信小程序的登录流程是规定动作但这里有几个细节值得注意。wx.login 拿到的 code 只能换一次 openid 和 session_key不能把 code 直接当身份凭证传给后端。我让小程序的 app.js 里维护一个 globalData 的 token 字段启动时先检查本地缓存是否有 token没有就调 login 接口拿 code然后通过后端 code2session 换取 openid后端用 openid 去用户表查找查不到就自动创建用户最终把服务端签发的 token我用的是 JWT返回给小程序存储。这里我踩了一个坑开发者工具里模拟器的 openid 和真机上是一样的但每个账号的 openid 不同如果测试时用开发者工具的“模拟登录”状态真机预览的时候登录态数据会不一致。所以我在开发阶段就把登录逻辑和测试账号隔离专门写了一个测试登录开关方便反复切账号验证。// app.js 中登录逻辑的核心片段 const login () { return new Promise((resolve, reject) { wx.login({ success: async (res) { const code res.code const { data } await request({ url: /api/auth/login, method: POST, data: { code } }) wx.setStorageSync(token, data.token) resolve(data) }, fail: reject }) }) }3.2 首页护肤内容的聚合入口首页我没有做成传统的电商首页纯 op 轮播图加商品瀑布流。护肤用户进入首页时的心理状态是“想看看有什么适合我的新品”而不是“我来搜一个具体的东西”。所以首页的模块顺序是Banner 区主推活动或新品 - 肤质雷达一个简单的肤质测试入口引导用户答题归档 - 会员福利区积分和券的展示 - 热卖榜单按销量和好评率融合排序 - 为你推荐按用户肤质匹配商品。这个信息结构是从大量美妆电商的首页跳失数据里总结出来的第一屏就要给用户“这个平台懂我的肤质”的信号。肤质雷达入口我做成一个三步选择的小问卷用户选完肤质后结果会写入用户表后续所有“为你推荐”的查询条件里都会带上肤质匹配字段。3.3 商品列表与详情页护肤品的信息密度控制商品列表页按分类筛选同时支持按肤质、成分、价格区间做二次筛选。护肤品的列表卡片除了主图、名称、价格三件套之外我特意放了两个字段一个是“适合肤质”图标一个是主要成分的关键词标签比如“烟酰胺”“神经酰胺”“A醇”。这两个标签能显著降低用户的筛选成本但也导致列表页接口返回的数据结构比普通电商多一层嵌套。详情页是这次开发的重点。护肤商品的详情页信息密度很大我一共规划了五个区块主图和视频区、价格与规格选择区弹层、成分安全说明区、用户评价精选区、相关推荐区。其中成分安全说明区是护肤垂类独有的板块我实现了将后端返回的成分 JSON 数组渲染成表格每种成分后面标作用、浓度、注意事项。这个功能看起来简单但字段格式的统一是后端服务端做好的如果每个商品的数据格式不一致前端渲染就会很痛苦。规格选择的弹层我实现了一个通用的 SKU 选择组件核心理念是“先选规格、再看库存”。每次用户选择一个规格维度就触一次查询把该维度的可用性实时反馈出来避免用户选到一个已经没有库存的规格组合。这一部分的交互逻辑表面上是前端的事但由于护肤品的规格维度是动态的有的商品按容量有的按肤质有的按套装数据库设计上必须允许规格维度自定义前端组件也要能适配不同的维度数量。3.4 购物车与结算从加购到支付减库存的完整链路购物车页面我用双数据源策略用户加购操作先写本地缓存Storage保证响应立刻可见同时当前端空闲时再异步同步到后端 Redis 和 MySQL。这样做的好处是用户体验顺滑坏处是存在本地缓存和服务器数据不一致的风险。我的处理方式是每次进入购物车页面触发一次全量同步以服务器数据为准覆盖本地。结算页面处理起来要更小心。用户在结算页确认订单时前端拿着商品 ID、SKU ID、数量数组去请求预下单接口后端做四件事检查用户登录态、检查 SKU 库存是否充足、计算最终价格商品金额减去优惠和积分抵扣、生成订单号并返回一个临时的 token。这个 token 跟订单号绑定在真正支付前有效期为 5 分钟。前端拿到订单号后调微信支付完成后再用订单号调一次确认接口确保服务端订单状态同步。库存扣减的时机我选择了“用户点击支付时预占库存支付回调到达时正式扣减库存”。也就是说下单但不支付的订单不会导致库存减少而是超时后释放预占的库存。这样做能最大程度避免恶意刷单导致库存虚低的问题代码实现上是在 Redis 里用 Lua 脚本做原子扣减保证并发场景下不会超卖。// Redis Lua 脚本实现库存预占 String script if redis.call(exists, KEYS[1]) 1 then local stock tonumber(redis.call(get, KEYS[1])) if stock tonumber(ARGV[1]) then redis.call(decrby, KEYS[1], ARGV[1]) return 1 end return 0 end return -1;3.5 我的页面订单查询、评价与售后入口“我的”页面承载了订单入口、收藏夹、收货地址、会员积分、售后记录。订单列表按状态分类 tab 展示每个订单卡片可以跳转到订单详情。评价功能我特意做到订单详情页里面只有已完成的订单才会出现“去评价”按钮评价时强制要求选择肤质类型否则提示用户补全。肤质标签会直接展示在评价模块里后续其他用户看评价时能一眼判断“我一个干皮用户看到油皮用户的评价参考价值不高”。4. 微信支付与后端对接的完整落地链路支付是购物系统绕不开的核心步骤也是整个项目里最容易踩坑和最容易出系统级事故的部分。微信支付官方文档写得不算差但初次接触时容易被几个概念绕晕商户号、AppID、API 密钥、APIv3 密钥、证书序列号、回调地址。我花点时间把这些概念理清然后讲整条链路。前置准备用小程序收款需要先有一个微信支付商户号然后在小程序后台里把商户号绑定到该小程序。如果项目只是学习演示“仅退款”的功能可以不用申请但“支付”功能必须开通。开通时要用营业执照认证这个过程通常是毕业设计和课程设计里最卡时间的一步如果时间紧张可以考虑用测试商户号或者服务商提供的开发测试环境但要注意测试环境拿不到真实支付结果回调模拟要自己写一套。发起支付的顺序是前端拿订单号调后端的下单接口 - 后端组装统一下单参数包括 openid、金额、回调 URL、小程序 AppID、商户号 - 后端用自己的 API 证书对参数做 RSA 签名 - 调用微信支付统一下单 API - 拿到 prepay_id 后再生成小程序端所需的支付参数包括 timeStamp、nonceStr、packageprepay_idxxx、signTypeRSA、paySign - 前端拿到这些参数后调用 wx.requestPayment。微信在签名上卡得非常严格任何一个参数漏传、顺序不对都会直接返回签名错误。// 生成小程序支付参数的简化示意伪代码 MapString, Object paramMap new HashMap(); paramMap.put(appId, miniProgramAppId); paramMap.put(timeStamp, String.valueOf(System.currentTimeMillis() / 1000)); paramMap.put(nonceStr, generateNonceStr()); paramMap.put(package, prepay_id prepayId); paramMap.put(signType, RSA); String signContent appId miniProgramAppId timeStamp paramMap.get(timeStamp) nonceStr paramMap.get(nonceStr) package paramMap.get(package) signTypeRSA; String paySign rsaSign(signContent, merchantPrivateKey);支付回调的落地是另一个容易被忽视的点。微信支付成功后会以异步方式请求你设置的回调接口。这个回调不能只做“收到就改订单状态”这种简单处理必须注意三点验签必须用微信支付平台证书验证回调请求体的签名防止伪造回调。幂等处理同一个订单的回调可能因为网络问题重复推送要用订单号做幂等校验判断更新后才响应 successful。回调超时结果如果回调接口挂了微信会按策略重试一段时间这期间用户已经付款但订单状态没更新就会产生“钱付了但前端查不到已付款”的问题。我的处理是前端支付成功后主动轮询一次订单状态接口用户看到的结果以这个接口的数据为准防止界面出现“待付款”的瞬间误导。退款接口的处理逻辑和支付类似但退款的用途通常是管理后台的“同意退款”。我在管理后台实现了两种退款整单退款和部分退款比如用户只退其中一个 SKU。部分退款的金额计算要非常仔细如果商品参与了满减或折扣部分退款时必须按比例返还优惠金额否则会出现退款金额超过实付金额的严重 bug。我在实现中专门写了一个 prorateRefund 方法按照子订单原价占比来分摊优惠。5. 开发过程中真实踩过的坑与优化方案这部分内容含金量比较高都是没有真正把系统跑到上线前不会意识到的问题。5.1 包体大小控制图片资源千万不要堆在代码包里小程序的代码包有明确的大小限制我在开发到一半时发现代码包已经接近 2MB 上限排查发现三分之二的体积是详情页富文本里的图片和 CSS 内联的渐变色背景图。解决思路是所有商品图片、Banner 图、富文本里的图片全部改成网络 URL并且按宽度做 CDN 压缩裁剪开发时不要图方便把测试图直接拖进项目目录。另外我把详情页富文本的渲染改为异步加载详情接口只返回富文本的 URL小程序端用 web-view 或者 rich-text 组件加载这样商品详情里的图片体积再大也不会影响主包大小。如果后续功能增多还需要考虑按功能拆分包。比如把“订单列表”和“售后”相关页面放主包把“肤质雷达”“积分商城”等低频页面放分包。5.2 真机兼容模拟器跑得通不代表真机没问题模拟器上调试时最常用的是 API 的返回 mock 数据和本机回环地址。真机预览时小程序是没有办法直接访问你电脑的 localhost 的必须通过局域网 IP 访问后端服务。这里就需要在 request 封装里做 BaseURL 的动态切换开发环境用局域网 IP生产环境用已备案的域名。而且微信小程序要求所有请求必须走 HTTPS生产部署时没有 HTTPS 证书是万万不可的。真机和模拟器还有个明显差异是底部安全区域。iPhone X 以上设备底部有 home indicator如果没有适配 safe-area-inset-bottom购物车页面的结算按钮会被遮挡一半。我在全局样式中加入了 env(safe-area-inset-bottom) 适配。5.3 微信支付回调在本地开发时怎么调试微信支付的回调必须是一个公网可以访问的 HTTPS 地址本地开发时收不到真实回调。我的做法是开发环境完全不依赖回调前端模拟支付成功后直接调用一个 debug 专用的“模拟支付成功”接口来更新订单状态。这个接口只在后端的开发配置里开放生产环境会关闭。这样本地联调省去了内网穿透这套麻烦事。另外微信支付还要求回调接口返回格式必须是{code:SUCCESS,message:成功}注意不是普通 JSON 的{code:200}如果返回格式不对微信会认为回调失败并不断重试。5.4 数据库索引与慢查询优化订单表和商品表的数据量上到一定量级后查询速度会明显下降。我在三个地方加了索引订单表按用户 ID 建索引用户查自己订单的场景订单状态字段建联合索引用户 ID状态创建时间购物车表按用户 ID选中状态建联合索引。加索引之后订单列表的响应时间从 800ms 降到了 120ms 左右。另外详情页的高频访问对 MySQL 压力很大我给商品详情接口加了 Redis 缓存缓存 key 设计为商品 ID版本号商品上下架或编辑时主动更新版本号来失效缓存。5.5 关于类目审核的一些提醒小程序发布前要过微信审核购物类小程序需要选择电商类目并完成资质认证。护肤品类目属于特殊类目需要补充相关行业资质。如果是毕业设计项目通常不会真实发布上线但如果你想把它部署到线上做演示建议提前确认好类目和资质否则会因为类目不匹配而被审核驳回。6. 一点个人体会整个项目从需求梳理、数据库设计、接口开发到小程序端调试累计开发周期大概两个月。做这类系统最花时间的其实不是写代码本身而是各种联调细节登录态在不同环境下的差异、库存扣减的并发安全、支付回调的幂等处理、不同型号手机的安全区域适配。这些问题的共性在于它们都是真实业务场景下才会暴露出来的光靠看教程是发现不了的。当初如果直接把通用电商模板拿过来改改商品字段应付中期检查没问题但越往后面做越是寸步难行。如果让我再优化这个系统我会优先考虑两个方向一是把推荐算法做厚基于用户肤质、浏览记录、购买记录做更细粒度的个性化排序目前只是按肤质匹配和销量权重排序还不够“懂用户”二是给小程序的商品详情页增加“用户肤质匹配度”的可视化指数把成分表里的各维度含量换算成类似“干皮友好程度 88%”之类的指标让用户在详情页停留的时间转化为有效决策信息。这两块都是护肤购物系统里非常有挖掘空间的地方也是和通用电商系统拉开差距的关键点。 
长河君 · 2026/10/6 17:00:29 · 阅读 1.2k 基于Spring Boot+微信小程序的精致护肤购物系统设计与实现
1. 项目缘起与定位护肤垂直品类为什么值得单独做一个小程序这个项目最开始是朋友工作室接的一个毕业设计需求甲方要求很明确做一个“精致护肤购物系统”载体必须是微信小程序后端要求能用 Java 技术栈实现最好还能带一套管理后台。当时市面上通用的电商小程序模板很多但直接套模板大概率会在答辩时被问倒尤其是“精致护肤”这四个字不是简单的换皮商城能覆盖住的。所以我没有急着写代码而是先花了大概一周时间把需求边界定清楚把“护肤购物”拆成几个具体的差异化场景再决定系统怎么设计。先说说为什么选微信小程序而不是 H5 或者独立 App。护肤品的消费决策链路和买普通日用品不太一样用户会反复查看成分表、看肤质适配、比对博主测评导致整个浏览到下单的过程往往不是一次完成而是分多次、跨多个时间段回来。小程序“用完即走、微信内直接打开”的特性天然吻合这种非连续的决策场景。用户在一篇公众号推文里种草了一款精华顺手点小程序查看详情、加入购物车过两天在聊天列表里划回来付款这个路径比打开独立 App 要顺滑得多。另外对商家来说小程序不需要用户注册账号就能通过微信授权建立身份体系冷启动门槛低配合微信支付的闭环也能省掉很多传统电商的跳转流失。然后是“精致护肤”这个垂类到底和普通电商有什么不同。我梳理下来主要有四点商品规格不是简单的“颜色尺码”而是“容量大小 肤质适配 套装组合”比如 30ml 和 50ml 的同一款精华价格、库存、优惠策略都可能完全独立。用户需要看到详细成分、使用说明、注意事项这类非结构化内容占比远高于服装数码类商品。复购周期明显护肤品的消耗周期通常在 4-8 周系统需要支持收藏、会员优惠、积分抵扣这类偏运营的功能。买家的评价数据对决策影响极大评价里需要带肤质标签、照片、点赞回复等互动维度。这些差异直接决定了我的数据库设计、页面结构和接口定义方式。我见过很多套壳商城项目的通病商品表只有名称、价格、库存、图片四个字段评价就是一张单向写死的表购物车和订单模块也是直接抄通用电商的 CRUD 模板。这类系统展示演示还行一旦面对真实的护肤消费场景基本是没法用的。项目范围我是这么划定的C 端微信小程序负责用户登录、逛首页、看商品分类和详情、加购、结算下单、支付、查看订单、评价后端管理端负责商品上下架、库存管理、订单发货、退款处理、数据看板。前后端完整闭环不做多余的东西比如社区种草、直播带货这类功能虽然听起来炫酷但会大幅拉长开发周期对毕业设计或早期上线验证来说意义不大。目标用户画像也定了以 20-35 岁女性为主力对肤质、成分有一定敏感度愿意花时间在详情页做功课价格敏感但不是纯低价导向。整个系统的页面色调、组件风格、文案语气也都是围绕这个用户群体去调的。这一点在后面的页面设计部分会详细说。2. 整体技术架构设计与选型取舍技术选型从确定开发方式那一刻开始就要想清楚。微信小程序的开发姿势大概分三派原生小程序WXML WXSS JS/TS、跨端框架uni-app、Taro、低代码平台。这个项目我毫不犹豫选了原生小程序理由是第一作为“设计与实现”类型的课程设计或毕设原生开发能把微信生态的机制讲得更清楚答辩时更有东西可说第二护肤购物系统的页面主要就是列表、详情、表单这类常规场景原生开发完全够用不需要引入跨端框架的编译复杂度第三uni-app 这种框架一旦踩到平台差异的坑排查的难度比对原生要高一截反而浪费时间。后端技术栈用了 Spring Boot 3 MyBatis-Plus MySQL 8 Redis。选 Spring Boot 没有太多悬念Java 技术栈里这对组合最成熟社区资料也多遇到问题基本都能搜到现成答案。MyBatis-Plus 相比原生 MyBatis 省掉了很多重复的 CRUD 代码对单人开发的节奏非常友好。Redis 的用途集中在三个地方Session 登录态缓存、购物车临时数据、订单防重令牌。整个系统的前后端交互模型是这样的小程序端只负责渲染和收集用户操作所有业务逻辑都通过 HTTP 接口调后端完成。没有采用云开发那种把小程序的数据库操作直接暴露给前端的方式因为“设计与实现”这个课题本身需要呈现一个完整的分层架构而且云开发的服务商锁定问题在一个长期项目中是很现实的隐患。数据库设计是这次项目的核心部分我直接放几张核心表的设计思路用户表主键、微信 OpenID、昵称、头像、手机号、肤质类型干性/油性/混合/敏感、生日用于会员生日礼、积分余额、会员等级、创建时间。把肤质类型直接冗余在用户表上是为了方便商品列表做“按肤质推荐”的查询不需要再单独查一张用户画像表。商品表主键、类目 ID、商品名称、副标题、主图、详情富文本、成分列表JSON 字符串存储例如 [{name:烟酰胺,purpose:美白提亮,concentration:5%}]、适用肤质JSON 数租、原价、现价、总库存、销量、上下架状态、排序权重。成分和适用肤质用 JSON 字段存储虽然违反第三范式但这两个字段的读取频率远大于修改而且格式是半结构化的拆表反而让代码更复杂。SKU 表主键、商品 ID、规格名称如“30ml”“50ml”“油皮专用装”、价格、库存、SKU 图、是否默认选中。护肤品的多规格逻辑在这里和通用电商完全一样但要注意的是每个 SKU 的价格可能差异很大必须用独立的 SKU 层来处理不能直接挂在商品表上。购物车表ID、用户 ID、商品 ID、SKU ID、数量、选中状态、添加时间。选了 Redis 做热数据而不是单纯依赖这张表因为购物车是高频读写场景每次都打 MySQL 没有必要但最终结算时必须以 MySQL 数据为准。订单表订单号、用户 ID、商品总金额、优惠金额、实付金额、运费、支付方式、支付流水号、订单状态、收货地址快照、创建时间、支付时间、发货时间、完成时间、关闭时间。订单状态我用一个有序的状态机来管理待付款、已付款/待发货、已发货/待收货、已完成、已取消、售后中、已退款。状态流转只允许前进或按特定路径回退不允许任意跳转这是订单系统的第一原则。订单明细表订单号、商品 ID、SKU ID、商品名称快照、规格快照、单价快照、数量、小计金额。快照字段是必须的因为商品信息后续可能被修改或删除订单不能跟着变。评价表评价 ID、订单号、用户 ID、商品 ID、评分、评价内容、晒图JSON 数组、肤质标注、点赞数、是否置顶。带肤质标注是护肤类购物系统的标志性功能其他品类的评价体系里很少会单独拆一个字段。公共字段如 create_time、update_time、deleted 我全部采用逻辑删除而非物理删除这样在回溯订单问题时能拿到完整的数据链。整体架构图如果非要说就是标准的三层表现层微信小程序页面 - 业务逻辑层Spring Boot 的 Service 层 - 数据访问层MyBatis-Plus 的 Mapper外加 Redis 作为缓存加速。没有引入消息队列、分布式事务这些重组件因为这类系统在初期阶段并不需要引入只会增加学习和部署成本。3. 小程序端页面结构与核心交互实现小程序端的页面规划直接对应着用户的核心动线登录/授权 - 首页逛 - 分类找 - 详情看 - 购物车管 - 结算付 - 订单查 - 评价晒。我按照这个动线把页面分成 tabBar 页面和普通页面。tabBar 用了四个首页、分类、购物车、我的。商品详情页、订单列表、结算页、评价页等都是普通页面。3.1 登录态的处理与唤醒微信小程序的登录流程是规定动作但这里有几个细节值得注意。wx.login 拿到的 code 只能换一次 openid 和 session_key不能把 code 直接当身份凭证传给后端。我让小程序的 app.js 里维护一个 globalData 的 token 字段启动时先检查本地缓存是否有 token没有就调 login 接口拿 code然后通过后端 code2session 换取 openid后端用 openid 去用户表查找查不到就自动创建用户最终把服务端签发的 token我用的是 JWT返回给小程序存储。这里我踩了一个坑开发者工具里模拟器的 openid 和真机上是一样的但每个账号的 openid 不同如果测试时用开发者工具的“模拟登录”状态真机预览的时候登录态数据会不一致。所以我在开发阶段就把登录逻辑和测试账号隔离专门写了一个测试登录开关方便反复切账号验证。// app.js 中登录逻辑的核心片段 const login () { return new Promise((resolve, reject) { wx.login({ success: async (res) { const code res.code const { data } await request({ url: /api/auth/login, method: POST, data: { code } }) wx.setStorageSync(token, data.token) resolve(data) }, fail: reject }) }) }3.2 首页护肤内容的聚合入口首页我没有做成传统的电商首页纯 op 轮播图加商品瀑布流。护肤用户进入首页时的心理状态是“想看看有什么适合我的新品”而不是“我来搜一个具体的东西”。所以首页的模块顺序是Banner 区主推活动或新品 - 肤质雷达一个简单的肤质测试入口引导用户答题归档 - 会员福利区积分和券的展示 - 热卖榜单按销量和好评率融合排序 - 为你推荐按用户肤质匹配商品。这个信息结构是从大量美妆电商的首页跳失数据里总结出来的第一屏就要给用户“这个平台懂我的肤质”的信号。肤质雷达入口我做成一个三步选择的小问卷用户选完肤质后结果会写入用户表后续所有“为你推荐”的查询条件里都会带上肤质匹配字段。3.3 商品列表与详情页护肤品的信息密度控制商品列表页按分类筛选同时支持按肤质、成分、价格区间做二次筛选。护肤品的列表卡片除了主图、名称、价格三件套之外我特意放了两个字段一个是“适合肤质”图标一个是主要成分的关键词标签比如“烟酰胺”“神经酰胺”“A醇”。这两个标签能显著降低用户的筛选成本但也导致列表页接口返回的数据结构比普通电商多一层嵌套。详情页是这次开发的重点。护肤商品的详情页信息密度很大我一共规划了五个区块主图和视频区、价格与规格选择区弹层、成分安全说明区、用户评价精选区、相关推荐区。其中成分安全说明区是护肤垂类独有的板块我实现了将后端返回的成分 JSON 数组渲染成表格每种成分后面标作用、浓度、注意事项。这个功能看起来简单但字段格式的统一是后端服务端做好的如果每个商品的数据格式不一致前端渲染就会很痛苦。规格选择的弹层我实现了一个通用的 SKU 选择组件核心理念是“先选规格、再看库存”。每次用户选择一个规格维度就触一次查询把该维度的可用性实时反馈出来避免用户选到一个已经没有库存的规格组合。这一部分的交互逻辑表面上是前端的事但由于护肤品的规格维度是动态的有的商品按容量有的按肤质有的按套装数据库设计上必须允许规格维度自定义前端组件也要能适配不同的维度数量。3.4 购物车与结算从加购到支付减库存的完整链路购物车页面我用双数据源策略用户加购操作先写本地缓存Storage保证响应立刻可见同时当前端空闲时再异步同步到后端 Redis 和 MySQL。这样做的好处是用户体验顺滑坏处是存在本地缓存和服务器数据不一致的风险。我的处理方式是每次进入购物车页面触发一次全量同步以服务器数据为准覆盖本地。结算页面处理起来要更小心。用户在结算页确认订单时前端拿着商品 ID、SKU ID、数量数组去请求预下单接口后端做四件事检查用户登录态、检查 SKU 库存是否充足、计算最终价格商品金额减去优惠和积分抵扣、生成订单号并返回一个临时的 token。这个 token 跟订单号绑定在真正支付前有效期为 5 分钟。前端拿到订单号后调微信支付完成后再用订单号调一次确认接口确保服务端订单状态同步。库存扣减的时机我选择了“用户点击支付时预占库存支付回调到达时正式扣减库存”。也就是说下单但不支付的订单不会导致库存减少而是超时后释放预占的库存。这样做能最大程度避免恶意刷单导致库存虚低的问题代码实现上是在 Redis 里用 Lua 脚本做原子扣减保证并发场景下不会超卖。// Redis Lua 脚本实现库存预占 String script if redis.call(exists, KEYS[1]) 1 then local stock tonumber(redis.call(get, KEYS[1])) if stock tonumber(ARGV[1]) then redis.call(decrby, KEYS[1], ARGV[1]) return 1 end return 0 end return -1;3.5 我的页面订单查询、评价与售后入口“我的”页面承载了订单入口、收藏夹、收货地址、会员积分、售后记录。订单列表按状态分类 tab 展示每个订单卡片可以跳转到订单详情。评价功能我特意做到订单详情页里面只有已完成的订单才会出现“去评价”按钮评价时强制要求选择肤质类型否则提示用户补全。肤质标签会直接展示在评价模块里后续其他用户看评价时能一眼判断“我一个干皮用户看到油皮用户的评价参考价值不高”。4. 微信支付与后端对接的完整落地链路支付是购物系统绕不开的核心步骤也是整个项目里最容易踩坑和最容易出系统级事故的部分。微信支付官方文档写得不算差但初次接触时容易被几个概念绕晕商户号、AppID、API 密钥、APIv3 密钥、证书序列号、回调地址。我花点时间把这些概念理清然后讲整条链路。前置准备用小程序收款需要先有一个微信支付商户号然后在小程序后台里把商户号绑定到该小程序。如果项目只是学习演示“仅退款”的功能可以不用申请但“支付”功能必须开通。开通时要用营业执照认证这个过程通常是毕业设计和课程设计里最卡时间的一步如果时间紧张可以考虑用测试商户号或者服务商提供的开发测试环境但要注意测试环境拿不到真实支付结果回调模拟要自己写一套。发起支付的顺序是前端拿订单号调后端的下单接口 - 后端组装统一下单参数包括 openid、金额、回调 URL、小程序 AppID、商户号 - 后端用自己的 API 证书对参数做 RSA 签名 - 调用微信支付统一下单 API - 拿到 prepay_id 后再生成小程序端所需的支付参数包括 timeStamp、nonceStr、packageprepay_idxxx、signTypeRSA、paySign - 前端拿到这些参数后调用 wx.requestPayment。微信在签名上卡得非常严格任何一个参数漏传、顺序不对都会直接返回签名错误。// 生成小程序支付参数的简化示意伪代码 MapString, Object paramMap new HashMap(); paramMap.put(appId, miniProgramAppId); paramMap.put(timeStamp, String.valueOf(System.currentTimeMillis() / 1000)); paramMap.put(nonceStr, generateNonceStr()); paramMap.put(package, prepay_id prepayId); paramMap.put(signType, RSA); String signContent appId miniProgramAppId timeStamp paramMap.get(timeStamp) nonceStr paramMap.get(nonceStr) package paramMap.get(package) signTypeRSA; String paySign rsaSign(signContent, merchantPrivateKey);支付回调的落地是另一个容易被忽视的点。微信支付成功后会以异步方式请求你设置的回调接口。这个回调不能只做“收到就改订单状态”这种简单处理必须注意三点验签必须用微信支付平台证书验证回调请求体的签名防止伪造回调。幂等处理同一个订单的回调可能因为网络问题重复推送要用订单号做幂等校验判断更新后才响应 successful。回调超时结果如果回调接口挂了微信会按策略重试一段时间这期间用户已经付款但订单状态没更新就会产生“钱付了但前端查不到已付款”的问题。我的处理是前端支付成功后主动轮询一次订单状态接口用户看到的结果以这个接口的数据为准防止界面出现“待付款”的瞬间误导。退款接口的处理逻辑和支付类似但退款的用途通常是管理后台的“同意退款”。我在管理后台实现了两种退款整单退款和部分退款比如用户只退其中一个 SKU。部分退款的金额计算要非常仔细如果商品参与了满减或折扣部分退款时必须按比例返还优惠金额否则会出现退款金额超过实付金额的严重 bug。我在实现中专门写了一个 prorateRefund 方法按照子订单原价占比来分摊优惠。5. 开发过程中真实踩过的坑与优化方案这部分内容含金量比较高都是没有真正把系统跑到上线前不会意识到的问题。5.1 包体大小控制图片资源千万不要堆在代码包里小程序的代码包有明确的大小限制我在开发到一半时发现代码包已经接近 2MB 上限排查发现三分之二的体积是详情页富文本里的图片和 CSS 内联的渐变色背景图。解决思路是所有商品图片、Banner 图、富文本里的图片全部改成网络 URL并且按宽度做 CDN 压缩裁剪开发时不要图方便把测试图直接拖进项目目录。另外我把详情页富文本的渲染改为异步加载详情接口只返回富文本的 URL小程序端用 web-view 或者 rich-text 组件加载这样商品详情里的图片体积再大也不会影响主包大小。如果后续功能增多还需要考虑按功能拆分包。比如把“订单列表”和“售后”相关页面放主包把“肤质雷达”“积分商城”等低频页面放分包。5.2 真机兼容模拟器跑得通不代表真机没问题模拟器上调试时最常用的是 API 的返回 mock 数据和本机回环地址。真机预览时小程序是没有办法直接访问你电脑的 localhost 的必须通过局域网 IP 访问后端服务。这里就需要在 request 封装里做 BaseURL 的动态切换开发环境用局域网 IP生产环境用已备案的域名。而且微信小程序要求所有请求必须走 HTTPS生产部署时没有 HTTPS 证书是万万不可的。真机和模拟器还有个明显差异是底部安全区域。iPhone X 以上设备底部有 home indicator如果没有适配 safe-area-inset-bottom购物车页面的结算按钮会被遮挡一半。我在全局样式中加入了 env(safe-area-inset-bottom) 适配。5.3 微信支付回调在本地开发时怎么调试微信支付的回调必须是一个公网可以访问的 HTTPS 地址本地开发时收不到真实回调。我的做法是开发环境完全不依赖回调前端模拟支付成功后直接调用一个 debug 专用的“模拟支付成功”接口来更新订单状态。这个接口只在后端的开发配置里开放生产环境会关闭。这样本地联调省去了内网穿透这套麻烦事。另外微信支付还要求回调接口返回格式必须是{code:SUCCESS,message:成功}注意不是普通 JSON 的{code:200}如果返回格式不对微信会认为回调失败并不断重试。5.4 数据库索引与慢查询优化订单表和商品表的数据量上到一定量级后查询速度会明显下降。我在三个地方加了索引订单表按用户 ID 建索引用户查自己订单的场景订单状态字段建联合索引用户 ID状态创建时间购物车表按用户 ID选中状态建联合索引。加索引之后订单列表的响应时间从 800ms 降到了 120ms 左右。另外详情页的高频访问对 MySQL 压力很大我给商品详情接口加了 Redis 缓存缓存 key 设计为商品 ID版本号商品上下架或编辑时主动更新版本号来失效缓存。5.5 关于类目审核的一些提醒小程序发布前要过微信审核购物类小程序需要选择电商类目并完成资质认证。护肤品类目属于特殊类目需要补充相关行业资质。如果是毕业设计项目通常不会真实发布上线但如果你想把它部署到线上做演示建议提前确认好类目和资质否则会因为类目不匹配而被审核驳回。6. 一点个人体会整个项目从需求梳理、数据库设计、接口开发到小程序端调试累计开发周期大概两个月。做这类系统最花时间的其实不是写代码本身而是各种联调细节登录态在不同环境下的差异、库存扣减的并发安全、支付回调的幂等处理、不同型号手机的安全区域适配。这些问题的共性在于它们都是真实业务场景下才会暴露出来的光靠看教程是发现不了的。当初如果直接把通用电商模板拿过来改改商品字段应付中期检查没问题但越往后面做越是寸步难行。如果让我再优化这个系统我会优先考虑两个方向一是把推荐算法做厚基于用户肤质、浏览记录、购买记录做更细粒度的个性化排序目前只是按肤质匹配和销量权重排序还不够“懂用户”二是给小程序的商品详情页增加“用户肤质匹配度”的可视化指数把成分表里的各维度含量换算成类似“干皮友好程度 88%”之类的指标让用户在详情页停留的时间转化为有效决策信息。这两块都是护肤购物系统里非常有挖掘空间的地方也是和通用电商系统拉开差距的关键点。