韩顺平-微信小程序实战：从零到一打造咖啡点单系统

这套资料的主题很明确：用微信小程序原生开发方式，做一个能跑通的咖啡点单系统。它不覆盖多端框架，也不绕道跨平台方案，而是老老实实走 WXML + WXSS + JavaScript 加小程序原生 API 的路线。对想搞清楚小程序底层运行方式的人来说，这种「笨」路线反而是最有复用价值的：页面栈怎么跳、setData 怎么触发渲染、生命周期怎么排布、组件间怎么通信，这些在小程序里是通用的。

技术栈与前置条件

整体是微信小程序原生技术栈，配微信开发者工具。你需要的底子是 HTML/CSS/JavaScript 的常规用法：会用 flex 排版，理解数组和对象操作，能看懂回调函数和 this 指向。有 Vue 或 React 经验会更顺，因为小程序的 WXML 数据绑定和 setData 机制在思路上接近声明式渲染，但要注意它和 Vue 双向绑定不一样——数据变更必须显式调用 setData，且 setData 是异步批量更新的，这个差异在调试列表渲染和表单输入时经常会踩坑。

项目结构与模块划分

咖啡点单系统的业务线索比较典型，属于「商品列表 → 商品详情/规格选择 → 购物车 → 下单 → 订单列表」的标准电商闭环。按照小程序的工程组织方式，通常会落到这几块：

• 页面层：商品列表页、咖啡详情页、购物车页、订单确认页、订单列表页，每页各自维护 data、onLoad 参数解析和页面间跳转逻辑。
• 自定义组件：规格选择弹层、数量加减器、购物车角标这类重复出现的 UI，适合抽成 component，通过 properties 接收数据、triggerEvent 向外抛事件。这是本项目最值得反复看的部分。
• 数据与工具层：把商品数据、订单数据的读写抽成独立模块，页面只负责调用，避免把业务逻辑写进 onLoad 里。
• 全局状态：购物车这种跨页面共享的数据，用 app.globalData 或简单的订阅通知机制管理，而不是每页各自存一份。

这些划分方式和真实小程序项目的目录约定一致，照着对照自己手上项目，能直接看出哪里该拆、哪里拆错了。

值得对照实践的几处工程细节

第一是「数据驱动的列表渲染」。咖啡分类切换、购物车数量变化都依赖 setData 的局部更新。看的时候留意它更新的是整个数组还是用路径语法只改某一项——后者性能差别在小程序里很实际。

第二是「事件冒泡与组件通信」。规格弹层选完规格后，怎么把结果传回商品页并更新价格，这是小程序组件化最容易讲不清的地方，跟着代码走一遍比看文档直观。

第三是「页面栈与导航」。下单成功后跳订单页，用 navigateTo、redirectTo 还是 switchTab，会直接影响用户能不能返回、返回后购物车状态对不对。这类细节只有跑起来才暴露。

第四是「本地存储的边界」。购物车、收货信息这类数据用 wx.setStorageSync 做持久化，什么时候读、什么时候清，是这个项目里很典型的数据生命周期问题。

自学路径建议

不建议一上来就逐行抄完整项目结构，容易变成抄完就忘。更有效的顺序是：先只跑通列表页渲染，确认能拿到数据、能循环出卡片；再补详情页和页面传参；接着搭购物车，把跨页面数据同步这件事想明白；最后做下单和订单流程。每一步都先自己写，卡住了再对照资料里的实现，看它和你的写法差在哪。

另外要主动做「反推」：看完一个页面后，先不看代码，自己列出这个页面需要哪些 data、哪些事件处理函数、和哪些页面有跳转关系，再回去比对。这种练习对小程序这类生命周期和页面栈约束较强的框架特别有效。整个咖啡点单的业务规模不大，正好适合当成一个把原生小程序吃透的练习载体，做完再去碰 uni-app、Taro 之类框架时会顺很多。