微信小程序商城构建全栈应用开发

这门课的主题很明确：用微信小程序把一套商城从页面搭到下单，再把购物车、订单、微信支付这些链路跑通。它不属于那种只讲 WXML 标签和 API 罗列的入门课，重心放在「一个真实商城的结构怎么分层、模块怎么拆、状态在哪一层维护、支付回调怎么接」这些工程问题上。适合已经能写基础小程序页面、但没独立做过完整交易闭环的开发者拿来对照。

技术栈与整体结构

默认前提是小程序原生开发配合服务端接口，前端承担页面渲染与本地状态，后端处理商品、库存、订单与支付签名。理解这门课时，建议先把结构分成四层来看：视图层（页面与组件）、状态层（购物车、用户登录态）、数据层（接口请求与缓存）、交易层（下单、支付、回调）。课程的推进基本沿着这四层展开，所以看的时候不要把它当成线性视频，而是按层去抓每个模块的职责边界。

小程序侧最关键的一点是：它没有浏览器那套完整能力，登录靠 code 换 openid，支付靠服务端签名后调起 requestPayment。这两处决定了你不能照搬 Web 商城的做法，必须理解小程序自己的鉴权与支付时序。

可复用的模块

• 商品列表与详情：列表分页、详情规格选择（SKU）的组织方式，是最容易在别的项目里直接搬的部分。
• 购物车：本地与服务端购物车如何取舍、数量增减、选中态与总价计算，这里的 reducer 思路可以抽出来独立用。
• 下单与地址：收货地址、订单确认页的参数拼装，是一套相对固定的表单与校验逻辑。
• 微信支付：统一下单、签名、调起支付、支付结果查询与回调处理，这条链路换个商城项目思路几乎不变。
• 通用请求封装：拦截器、token 携带、错误统一处理，属于全栈项目都该有的一块基础设施。

把这几块当成独立模块去看，比顺着章节往下刷更有效——它们各自有清晰的输入输出，抽出来就能放到下一个项目里。

购物车与支付这两条主线

购物车是状态管理最密集的地方：多个页面共享同一份数据，加减、删除、全选都要立刻反映到总价上。课程里对这部分拆得比较细，重点不在于写多少行代码，而在于想清楚「谁是数据源、谁负责同步」。如果这一层没理顺，后面下单页会直接拿到脏数据。

支付则是全栈性质最强的一段。小程序端只负责调起，真正的安全性落在服务端签名和回调校验上。看这段时要盯住三件事：订单号如何生成与幂等、支付回调如何防止重复处理、支付成功后前端状态怎么和订单状态对齐。这三点是实际项目里最容易出问题的地方。

怎么用它自学

不建议从头到尾只看不写。更实际的做法是：先跑通一遍完整下单流程，建立整体感知；然后合上代码，自己按模块重写购物车和支付请求封装，再对照源码找差异。遇到状态同步、回调时序这类问题时，回头查对应章节比反复看视频有用得多。

这套资料的价值在于它提供了一份可运行的完整工程参考，而不是零散的知识点。把它当对照组：你写一遍，它写一遍，差异处就是你要补的地方。