微信小程序看起来门槛不高：会点 HTML、CSS、JavaScript，照着官方文档敲几个组件，页面就能跑起来。但真正动手做一个能下单、能算钱、能管状态的点单系统，问题就来了——页面之间怎么传数据？购物车里的数量改一个，总价怎么跟着变？本地缓存什么时候用、什么时候该扔？这些不是看文档能看明白的，得有一个完整项目把坑踩一遍。

这门课选的是咖啡点单系统。它比待办清单复杂一点，比商城简单一点，正好卡在"能覆盖核心机制、又不至于被业务逻辑淹没"的位置。下面从几个能力缺口说说什么样的人适合看、看的时候该盯住什么。

缺口一：页面会写，但数据流是乱的

很多人写小程序的状态是：数据从接口拿到，直接 setData 铺到页面上，用户点一下按钮再改回去。单页面没问题，一旦涉及菜单页、详情页、购物车页、订单页，数据就开始各管各的。菜单页加了一份拿铁，切回购物车发现没同步；购物车里删掉一项，总价还停在旧数字上。

咖啡点单系统天然会逼你处理这个问题：商品列表、规格选项（冷热、大小杯、加料）、数量、金额，这几层数据是有依赖关系的。看这门课时，重点不是记某个 API 怎么写，而是看它在页面跳转和返回时把数据放在哪里、由谁负责更新。这一层想清楚了，换任何小程序项目都能套用。

缺口二：知道组件，但没组织过页面结构

小程序的基础组件就那么几个，view、text、image、scroll-view、button，背下来不难。难的是拿到一张设计稿之后，怎么拆成合理的层级，哪些部分该抽成自定义组件，哪些直接写在页面里就行。

点单系统里有一类典型结构：一个可以滚动的商品分类列表，旁边挂着分类锚点，点一下滚到对应位置。这种交互用纯页面写会越写越乱，只有拆成组件、把数据通过 properties 传进去，逻辑才收得住。跟着敲的时候别只顾复制，停下来想想这一步为什么要单独拎出来。

缺口三：后端是空的，接口不知道从哪来

做前端项目最常见的卡点是：页面写好了，没有数据。这门课在环境搭建部分会涉及开发工具配置和本地数据来源的处理方式。对转岗或者自学的人来说，这部分比 UI 更有价值——你得知道一个没有真实后端的项目怎么先跑起来，怎么用假数据模拟出接近真实的交互，等真接上接口时又该改哪些地方。

如果你之前只用过静态页面，这里会有个认知转变：小程序的请求是异步的，页面渲染和数据处理不在一个时间点上。点单流程里，加购物车、算总价、提交订单，每一步都要考虑"数据还没回来的时候界面显示什么"。

看完应该能回答的问题

同一个商品加了两种规格（大杯热 / 小杯冰），购物车里该存成一条还是两条？数量怎么算？
页面返回时，之前填的备注、选的规格怎么保住？用本地缓存还是全局变量？
下单前需要校验哪些东西？校验失败时提示放在哪一层？
如果要把这套系统改成奶茶店、快餐店，哪些代码能直接复用，哪些必须重写？

怎么用这门课

建议不要一次看完再动手，那样看完就忘。按功能块走：先把商品列表和详情跑通，再单独做购物车，最后接订单。每一块做完，自己改一个需求试试——比如加一个"第二杯半价"，看能不能在不破坏原有结构的前提下加上去。加得动，说明这部分你确实掌握了；加不动，回头再看那一节。

另外提醒一句：小程序的基础语法更新不算快，但开发工具和某些能力（比如登录、支付相关）的规则会变。课里的实现方式可以照做，涉及平台规则的部分，动手前顺手查一下当前官方文档，别把过期写法当成标准答案。