几年前我第一次完整做完一个微信小程序电商项目时最大的感悟是购物系统本身并不难难的是把购物放进一个垂直领域后所有通用设计都会变形。精致护肤这四个字放在购物系统前面意味着你面对的不是普通商品堆砌而是一套要结合肤质测评、成分筛选、复购周期、内容合规这些复杂因素的业务体系。这篇文章直接把我在这个项目里的设计决策、实现路径和踩坑记录摊开讲从需求边界、技术选型、数据库设计到手机号登录、微信支付、护肤垂直功能落地再到上线审核和性能优化给准备做同类小程序购物项目的人一份可以照着走的参考。1. 项目定位与范围先想明白做的是护肤还是购物很多人拿到这类题目第一反应是照着通用商城框架抄一套结果做出来的是一个谁都能用的商品列表加购物车把精致护肤完全做成了装饰词。我在动手之前先做了两件事明确用户是谁明确系统边界在哪里。1.1 目标用户与业务场景假设这个系统面向的是对护肤有认知、愿意花时间了解成分和功效的用户以女性用户为主年龄集中在20到35岁。她们不是随便逛而是带着明确意图来的——可能是我是敏感肌想找不含酒精的精华也可能是我用了三个月烟酰胺想换个更温和的A醇进阶。这个人群有一个典型特征复购频率高、决策链路长、对推荐逻辑敏感。顺着这个判断我把业务场景拆成了三条核心链路发现商品首页推荐 肤质测评结果推荐 成分/功效筛选交易转化商品详情、SKU选择、购物车、下单支付、订单跟踪长期运营周期购提醒、收藏关注、会员积分、优惠券核销和普通商城相比少了拼团、分销、直播带货这些偏流量玩法的模块把精力集中在让用户买对东西和让用户持续回来买上。1.2 MVP范围与明确的不做清单项目启动时最怕什么都想要。我这边的MVP最小可行产品范围砍得非常明确用户端手机号登录、首页、商品分类与搜索、商品详情、肤质测评、购物车、订单确认与支付、订单列表与详情管理端商品管理、库存管理、订单管理、用户管理、测评问卷配置没有做的包括社区种草、直播、拼团、分销裂变、退款售后流程只保留订单状态标记等。原因也很简单这些模块每加一个数据库设计和接口复杂度都会翻倍但核心用户旅程其实用不上它们。这里特别想说一句设计与实现类项目需求边界本身就是设计的一部分能在论文或项目答辩里清楚说我为什么不做什么比无脑堆功能加分得多。1.3 为什么选择微信小程序作为载体这个我专门对比过原生App获客成本太高H5又难以触达服务通知和支付闭环而微信小程序天然具备三个优势。微信生态内的登录与支付闭环用户从看到到付款的路径最短公众号、搜一搜、订阅消息等入口能支撑护肤类目的内容运营和复购触达对于个人开发者或小团队小程序审核和发布周期比App上架灵活尤其是订阅消息这个能力对护肤品的周期购提醒太合适了这个后面我会专门讲实现方法。2. 技术选型与整体架构每一步选型都有取舍逻辑做技术选型最怕因为别人用所以我也用。我在这个项目里的选型逻辑是反着来的——先列出这个系统最核心的约束再选能满足约束的技术。2.1 前端方案原生小程序而非uni-app前端框架我最终选择了微信小程序原生开发没有用uni-app或Taro。对比下来有几个关键原因本项目不需要多端发布uni-app的多端编译优势用不上原生小程序对微信API的兼容性最好尤其是手机号一键登录、订阅消息、微信支付这类强依赖微信能力的模块原生SDK的调试体验最直接原生WXML/WXSS的渲染逻辑在复杂列表页面商品详情、订单列表下性能更容易把控当然这不是说uni-app不好如果你有App端或H5端的发布需求uni-app的跨端价值就出来了。但就这个项目而言砍掉不需要的复杂度本身就是一种优化。2.2 后端方案Spring Boot MyBatis-Plus后端选用Spring Boot理由可以总结成三条电商核心链路涉及订单、库存、支付对事务一致性要求高Java生态的声明式事务和成熟的状态机方案最稳Spring Boot的生态太全了微信支付SDK、Redis、消息队列都是开箱即用团队或个人的Java基础普遍更扎实后期维护成本低持久层用MyBatis-Plus主要是看中它的代码生成、分页插件和Lambda条件构造器能让CRUD代码量至少少写三分之一。数据库用了MySQL缓存用了Redis存储对象用了阿里云OSS这些都没有悬念。这里可能有人会问为什么不直接用微信云开发我的答案是云开发确实能省掉服务器运维但云开发的数据模型和事务能力在电商这种强一致场景下需要很多变通而且后期要接私有部署或扩展会很受限。如果是课程设计级别的项目云开发能省很多事如果希望系统有真实的业务承载力自建后端更踏实。2.3 数据库设计商品、订单、测评三张核心表之外数据库设计我花的时间最多因为护肤品的商品模型比普通商品复杂。普通商品一个SKU就是一个规格但护肤品涉及容量、套装、赠品绑定甚至还有同款不同批次的问题。商品部分我用了经典的SPU标准化产品单元和SKU库存量单位分层设计productSPU表存商品名称、主图、详情图文、品牌、功效标签、成分标签等product_skuSKU表存具体规格比如50ml装30ml洁面赠品套装含价格、库存、SKU图product_tag标签表护肤系统最重要的维度之一后面专门讲订单部分围绕状态流转设计orders主表记录订单号、用户ID、总金额、状态、支付时间等order_item明细表记录每个SKU的数量、单价、快照信息cart购物车表与用户绑定合并了原来要做的临时表和正式表肤质测评模块额外设计了问卷表skin_question题目配置表支持选择题和分值规则skin_result测评结果表存放用户的肤质类型和对应推荐商品ID集合2.4 接口与权限设计统一响应体加Token双轨认证所有后端接口遵循RESTful风格统一返回结构是{ code, message, data }分页数据统一为{ list, total, pageNum, pageSize }。这样小程序端可以写一个统一的请求封装状态码、鉴权失败、业务错误全部走同一套拦截逻辑。鉴权采用JWT Token方案。用户通过wx.login拿到code后后端调用微信接口换openid生成自定义Token返回前端。之后的请求都在Header里带Authorization: Bearer token。下单、加购物车、修改个人信息这些敏感操作都要过一层拦截器校验登录态。数据库设计这一块我自己的一个心得是订单明细里一定要存商品快照名称、价格、图片URL不能直接关联商品表。因为商品价格和展示信息是会变动的历史订单必须还原下单那一刻的内容。这个细节面试和答辩里常被问也是很多新手设计电商库时最容易漏掉的。3. 核心业务链路实现从手机号登录到支付回调的完整闭环这一章是整个系统实现的核心我会按用户实际走过的业务顺序把每条链路的实现逻辑和代码级细节讲清楚。3.1 手机号登录不能把解密放前端微信小程序的手机号登录现在的标准做法是使用button组件并设置open-typegetPhoneNumber用户点击授权后通过e.detail.code换取手机号。这个code是动态令牌需要回传到后端由后端调用微信接口换取真实的手机号信息。这里有一个很关键的坑手机号解密逻辑绝不能放在小程序前端。用code换手机号的接口需要用到小程序的AppSecret这个密钥一旦暴露在前端代码里任何人都能拿到你的小程序管理权限。正确做法是前端只拿到code传给后端由后端去请求微信接口。我的实现流程拆开是这样的微信端返回的code通过请求传入后端后端调用微信接口https://api.weixin.qq.com/wxa/business/getuserphonenumber换取手机号用手机号去用户表查询如果已存在则直接登录不存在则创建新用户登录成功后用UUID生成Token返回同时把Token存入Redis并设置过期时间我设为7天小程序端把Token存入wx.storage后续请求自动携带要注意的是getPhoneNumber能力需要小程序已完成企业主体认证个人主体的小程序是没有这个权限的。如果做课程设计用个人主体可以退回wx.login静默登录再让用户手动填手机号的方案但真实商业项目必须走企业认证。3.2 商品浏览与购物车SKU选择和库存联动商品列表页我用的是onReachBottom触底分页加载每页10条请求参数里带分类ID、排序字段综合/销量/价格、筛选标签ID列表。这里筛选条件直接拼成SQL动态条件用MyBatis-Plus的wrapper配合StringUtils.isNotBlank判空处理比手动拼SQL干净得多。商品详情页的核心是SKU选择器。护肤品一个SPU下往往有多个SKU比如同一种精华有30ml和50ml价格和库存不同。SKU选择我用了二维矩阵思路先加载所有SKU及可选规格值用户选一个规格后用every判断组合是否有效无效的组合置灰。这个逻辑比想象中费时间因为要同时处理规格值选择顺序不同和部分组合缺货的情况。购物车我采用登录后远程存储方案。用户加购时如果未登录先弹窗提示登录登录后购物车数据存后端换设备不丢还能在管理后台统计加购数据。加购接口做了数量合并同一个用户同一个SKU如果已存在购物车直接加数量而不是插入新记录。库存处理是这个链路最容易出错的地方。我的方案是加入购物车不锁库存提交订单时预扣库存支付超时释放库存。用户下单后生成订单状态为待支付同时把对应SKU库存扣减如果30分钟未支付定时任务把订单置为已取消并恢复库存。这个方案能避免下单不付款导致库存被占满的问题也能在真实秒杀场景下做进一步扩展。3.3 订单流程与微信支付回调幂等是底线订单提交流程大概是这样的前端传递收货地址ID、购物车选中的SKU列表、备注后端校验登录态、校验库存、计算金额含运费规则开启数据库事务扣减库存、生成主订单和明细、清空购物车对应项返回订单号前端拉起微信支付支付环节调用微信支付统一下单接口。这里有个细节微信支付要求金额单位是分所以前端展示金额用元后端计算和传参全用分避免浮点数精度问题。我在实体类里直接用Integer表示金额写了个MoneyUtil转换。支付结果是通过微信支付回调通知的。回调接口的可靠性是底线我做了三层防护验签用微信支付平台证书验证回调签名幂等处理回调里带transaction_id先查本地支付流水表如果该流水已经处理过直接返回成功避免重复更新订单状态最终一致性回调处理成功后修改订单状态并标记支付时间这里分享一个实际踩过的坑回调接口必须返回{code: SUCCESS}给微信不然微信会重试多次。我第一次接支付回调就是返回了自定义的成功格式导致微信那边一直重投订单被更新了好几次后来加上幂等判断又改成微信要求的返回格式才稳定。3.4 订单状态机设计订单状态我用一个status字段管理核心状态包括待支付0、已支付/待发货1、已发货/配送中2、已完成3、已取消4、退款中5。状态流转严格控制待支付 - 已支付支付回调触发待支付 - 已取消用户主动取消、超时未付系统取消已支付 - 已发货商家后台操作已发货 - 已完成用户确认收货或系统自动确认发货后15天已完成 - 退款中 - 已取消售后流程这套状态机逻辑本身不复杂但要注意看订单列表时不同状态下展示不同按钮前端每个状态对应一套操作区配置。我在后端返回订单VO时直接带上allowedActions列表前端根据列表渲染按钮避免小程序端做大量if-else判断。4. 护肤垂直场景的功能设计测评、成分筛选、周期购如果只是把上面这些商城功能做完这个项目还配不上精致护肤四个字。这一章讲的才是这个系统和普通购物系统拉开差距的地方也是我在设计和答辩时最能体现思考深度的部分。4.1 肤质测评引擎规则判断和商品推荐的联动肤质测评我设计成一个独立的配置化模块。问卷题目存在数据库里每道题包含选项和对应分值用户答题后后端按规则引擎计算得分得出肤质类型干性、油性、混合、敏感然后根据肤质类型、季节因子、用户年龄自动推荐适合的商品。测评问卷维度我参考了常见的皮肤分类模型但不是直接照搬而是做了简化处理核心四类问题出油程度T区和脸颊的出油频率干燥程度换季或洗脸后的紧绷感敏感程度是否存在泛红、刺痛问题耐受程度使用功效型护肤品如酸类、A醇后的反应每道题选项对应不同分值和权重最后得分映射到肤质类型。结果页除了展示肤质类型还会展示适合你的商品排序规则是该商品标签命中用户肤质需求的得分权重。这套测评和商品的关系链让我在设计数据库时想了不少时间最后是这么处理的skin_result表存储测评结果JSON里面除了肤质类型还有一个recommend_product_ids字段存推荐商品ID的JSON数组。好处是接口不用每次即时算推荐坏处是如果商品标签变化推荐结果要重新生成。对于MVP阶段这个方案足够好用。4.2 成分标签与商品筛选护肤商品的核心维度普通商城筛商品一般按分类、价格、品牌。护肤系统必须多一个维度——功效与成分标签。我在商品标签表里维护了是否敏感肌适用“是否含酒精”“主打成分”适用肤质等标签列表页支持多标签组合筛选。这里我要特别说一个合规问题性能方面美白祛痘抗衰老这些词在护肤商品里使用有严格的广告法限制。2023年之后化妆品宣传违规抓得非常严普通商品标题和详情页里不能出现明示或暗示医疗作用的词语。我给商品维护标签时主动避开了治疗”“药妆”消炎这些词用舒缓修护保湿提亮替代。这个细节看似跟技术无关但上线审核管得比支付还严商品类目和文案不对很可能被拒审。筛选接口的实现是动态拼接查询条件标签之间用AND关系同一个标签下多个值用OR关系。前端筛选组件的数据直接来自后端接口后端从标签表读配置不再硬编码。这样运营人员以后加新标签不需要改代码改数据库就行。4.3 周期购提醒小程序订阅消息的正确用法护肤品的复购周期大约在30到60天一支精华用空瓶的时间比较固定。这个业务特性天然适合做周期购提醒。我的实现方案是订单状态变成已完成后系统根据商品关联的建议使用周期写入一条提醒计划到期前3天通过小程序订阅消息给用户推送一条你的精华快用完啦可以看看这些替代品的通知用户点击通知可以直接跳转回商品详情页订阅消息这里有个大坑微信的一次性订阅消息用户点一次授权只能推送一次而且授权弹窗必须在用户主动操作时触发比如点击一个按钮不能在setTimeout或用例触发。所以我在订单完成页放了一个接收空瓶提醒的开关用户手动点击后调wx.requestSubscribeMessage订阅消息。长期订阅消息目前只开放给特定类目普通电商类目基本拿不到所以别指望能无限推。4.4 会员积分与优惠券电商系统的运营闭环护肤品的客单价高、复购周期明确会员积分和优惠券运营起来比普通快消品更有效。积分模块我做了低配版下单送积分1元送1积分、积分抵现100积分抵1元。优惠券则分为满减券和折扣券后台可以创建前端在订单结算页列出当前用户可用券用户选券后重新计算实付金额。优惠券表设计要注意有效期和状态。我在表里设计了start_time和end_time用户领券时记录received_time和used_time每次计算可用券时会校验有效期和是否已使用、是否达到满减门槛。这里有个经常被忽略的点优惠券金额也要参与支付回调的金额校验后端需要维护一个订单实际减免金额的流水方便对账。5. 实测踩坑记录与性能优化清单这一章是全项目最折腾的部分。真实开发的每一天都在踩坑我把那些影响比较大、且不做这个项目很难提前发现的坑和优化点整理出来。5.1 小程序2MB包体限制分包加载与图片压缩微信小程序主包大小限制是2MB2023年后优化到单包2MB、总体积20MB以上需额外申请但护肤商城的商品详情页面里图片占比极其夸张。第一次构建时主包直接超过限制构建失败。我的解决办法是三层组合图片全部走CDN/OSS不在包内放任何商品图包内只保留tabBar图标等必须静态资源主包只放首页、登录、共通组件商品列表、详情、订单、测评等页面全部用分包加载大图统一缩放到750px宽度以下控制在100KB以内详情页用懒加载图片组件分包后的加载策略是进入页面时按需加载对应分包小程序IDE里能看到分包加载状态。如果项目里既有商城又有社区可以再拆一层独立分包核心逻辑相互不干扰。5.2 setData性能列表渲染不要一次性塞大对象小程序性能瓶颈往往出现在setData上。setData是全链路通信数据量大或频率高都会造成页面卡顿。我在商品列表页初次实现时直接把整个分页数据setData到页面上滑动起来帧率明显偏低。优化方案有两个分页加载时用setData的第二个参数回调确认渲染完成配合wx.nextTick列表页的商品卡片数据用精简VO只保留列表展示需要的字段详情等重数据延迟加载还有个细节不要把整个购物车对象反复setData而是单独维护数量字段并只对变化的行做局部更新。5.3 登录态过期与Token刷新护肤商城的用户使用频率不高Token过期后用户再打开小程序调接口会直接401。很多人的处理是弹登录框但更顺滑的做法是静默刷新。我的方案是后端接口统一做鉴权拦截401时返回特定错误码小程序端收到401后检查是否有wx.login换取的code用静默登录接口换新Token再用原请求重放一次。如果静默登录也失败比如RefreshToken失效才弹真正的登录框。切换到后台再回前台时会主动调用一次Token校验接口提前发现过期避免用户操作到一半才中断。5.4 支付回调与对账防止钱扣了订单还是待支付支付回调虽然做了幂等但我还是遇到过用户已支付但订单未更新的情况——集中在微信支付回调偶发延迟的场景。为了兜底我实现了一个主动对账任务定时扫描已支付但待发货订单中创建时间超过5分钟、且本地没有支付流水记录的订单反向调用微信支付查询接口查单如果查到了已支付就补更新订单状态。这个方案大大减少了客服咨询量。我的经验是做支付相关功能永远不能只依赖回调要同时做正向回调 定时对账 用户主动查询三保险。5.5 小程序审核被拒的常见原因上线审核时被拒了三次总结下来集中在三个点给准备上线的朋友提个醒类目不一致护肤购物属于商家自营-美妆/护肤类目需要营业执照经营范围包含化妆品零售用户隐私协议缺失小程序需要配置《用户隐私保护指引》手机号、收货地址都属于收集的信息必须明示用途支付流程不完整审核人员在测试时如果发现未支付订单没有取消入口或支付失败没有提示会被直接打回每次被拒都要在后台查看具体原因按提示改完再提审。提审前自己最好完整走一遍登录 - 浏览 - 加购 - 下单 - 支付 - 查看订单任何一步异常都可能成为审核不通过的理由。6. 从开发到上线的最后一公里账号、类目、配置代码写完了并不代表项目结束上线前还有不少偏配置和合规的工作。很多人在这一步卡了很久我按顺序列出来。6.1 小程序注册认证与企业主体要求个人主体的小程序无法开通微信支付和手机号快速验证组件所以商业化的护肤购物系统必须走企业主体注册。注册时需要准备营业执照经营范围需包含化妆品/护肤品销售对公账户信息用于微信支付商户号申请小程序名称和头像护肤类名称不能带官方治疗特效等违规词认证费用是300元/年微信支付商户号申请一般1到3个工作日能下来。如果做课程设计或者演示项目用测试号和测试商户号就行不需要真的花钱认证。6.2 服务端域名与HTTPS配置小程序正式版要求所有请求域名必须是HTTPS且在后台配置白名单。这一步很烦因为开发环境可以用不校验合法域名调试但上线必须配好备案域名和SSL证书。我建议的流程是先买域名并备案再去申请SSL证书最后在小程序后台配置request合法域名、uploadFile合法域名、downloadFile合法域名。如果涉及web-view嵌入H5还要配业务域名。这里最常见的问题是备案时间比预期长所以域名要提前准备不要等代码写完了再开始。6.3 版本发布与线上监控小程序发布流程是开发者工具上传代码 - 后台提交审核 - 审核通过后发布。发布后观察半天重点看接口错误率、支付成功率、首屏加载耗时。我这边用了一个简单的服务端日志监控把订单创建失败、支付回调异常、接口超时的日志单独输出到错误日志文件每天定时检查。还要特别留意微信后台的体验版功能。每次发新版本前先发体验版给测试人员或自己扫码体验确认核心链路无回归再提审。不要直接上正式版支付流程一旦出问题影响的是真实交易代价很大。6.4 系统上线后的运营数据埋点这个项目上线后我还加了几个简单的埋点首页曝光、商品详情页点击、加购次数、支付成功次数、测评完成次数。通过这些数据能看出一条核心漏斗曝光到支付的转化率、测评完成用户的下单率是否高于普通用户。这个数据不只是运营指标也是验证肤质测评推荐这个功能是否有价值的直接依据。我在后期优化推荐排序时就是靠这些数据决定哪些标签的权重需要调整。最后分享一点个人经验项目做完回头看技术上的难点其实都集中在几个地方SKU与库存的事务处理、支付回调的幂等、小程序包体与渲染性能、以及护肤垂直逻辑测评、成分标签、周期购怎么和交易系统自然结合。这些部分恰恰是面试官或答辩评委最感兴趣的点也是你和只会写CRUD拉开差距的地方。如果让我重新做一次我会在一开始就把数据库的表结构调整得更灵活尤其是标签系统和测评规则的配置化程度可以提高。另外支付功能建议先用微信支付沙箱环境跑通全流程再接真实商户号。最后提醒一句护肤类购物小程序在商品文案合规上的工作量比想象中大这类项目的成功不只是代码能跑还要过得了审核、留得住用户。希望这篇记录对准备做同类系统的人有实际帮助。