微信小程序商城系统设计与实现：从技术选型到上线实践

1. 立项背景与核心需求拆解

1.1 为什么这个时间点做恒星商城线上订购系统

做这个项目之前，我把2025年前后的零售环境、用户消费行为和现有的小程序工具链看了一遍，最终觉得“恒星商城线上订购系统”这个题目不是拍脑袋想出来的，而是确实踩在几个真实的痛点上。

传统商超、连锁门店、社区零售店如今面临的最大问题，不是商品不好，而是“到店客流不稳定”。顾客习惯在手机上先看、先比、先下单，再决定要不要到店。如果商家只有线下收银系统，没有任何线上承接能力，那么顾客进了美团、饿了么、抖音本地生活这些平台，下单数据、会员资产、营销触达全都是平台的，商家只是一个“供货商”，连回头客都沉淀不下来。恒星商城线上订购系统要解决的问题，就是把这部分订单和用户收回到自己的私域容器里，让门店拥有一个成本可控、数据自有、可随时改造成会员商城的小程序入口。

我把整个系统的定位拆成了三层：

• 第一层是“卖货”：商品上架、分类浏览、SKU选择、购物车、下单支付，这是基础零售能力；
• 第二层是“服务”：线上选购、到店自提、同城配送、售后处理，满足不同配送半径的客户需求；
• 第三层是“运营”：会员标签、优惠券、满减活动、订单统计，让线上不是单纯接单，还能反哺线下经营。

这三层定位决定了后面所有的功能设计和技术选型。如果只做第一层，那不需要小程序原生能力，做个H5就行；但要同时支撑第二层和第三层，微信生态的用户授权、订阅消息、支付、登录等能力就必须用起来，小程序是最合适的载体。

1.2 目标用户与典型使用场景

我梳理了这个系统日常会碰到的三类用户，他们的核心诉求完全不同：

• C端消费者：追求“快”。打开小程序能快速找到商品，看到价格和库存，下单时最好不用反复填写地址，支付一次完成。他们对加载速度很敏感，对小程序卡不卡、流畅不流畅有直接体感。
• 门店运营人员：追求“省”。他们不一定是专业程序员，日常需要处理商品上下架、库存修改、接单核销。后台操作必须简单，最好手机上就能完成大部分操作。
• 商家管理决策者：追求“看得见”。他们需要知道今天卖了多少、哪个商品卖得好、哪个时段订单集中、复购率怎么样。这些数据如果还靠人工整理，系统上线就是失败的。

典型场景我也列了几条，方便后面设计功能时对齐：

• 顾客在店里看到商品却没带够现金，扫码进入小程序下单，选择“到店自提”，结账时出示核销码；
• 老顾客在家打开小程序，看到周末满减活动，提前下单，预约次日配送；
• 分店店长打开管理端，发现某款生鲜库存不足，直接在小程序后台改库存并同步给订货供应商；
• 老板在周例会前打开数据报表，看到本周复购率上升，决定把营销预算投到老客召回上。

这些场景中，小程序不是替代线下门店，而是扩展门店的服务半径。这是整个项目最核心的业务判断。

2. 技术路线与关键选型解析

2.1 原生小程序还是uni-app，我为什么这么选

技术选型是开题阶段最容易反复摇摆的地方。恒星商城线上订购系统涉及前端、后端、管理端三个面，如果每个端各搞一套技术栈，开发和维护成本会成倍增长。

先说结论：我建议小程序端采用uni-app（Vue 3语法），管理后台采用Vue 3 + Element Plus，后端采用Node.js（NestJS）或Java（Spring Boot），数据库用MySQL + Redis，对象存储用云存储，消息推送接入微信订阅消息。

选uni-app的原因很现实：如果今天只做微信小程序，原生开发当然没问题；但恒星商城的定位是面向多个平台扩展——支付宝小程序、抖音小程序、H5、甚至以后要做App，原生写一遍就要复制一遍。uni-app用一套Vue代码，可以编译到多个平台，虽然会有少量平台差异化代码，但整体还是省很多事。另外，团队如果后续招人，Vue生态的开发者比小程序原生开发者更容易补齐。

但这里有个坑必须提前说明：uni-app不是银弹，它有一个“中间层抽象”的代价。微信小程序特有的能力，比如订阅消息、支付、getUserProfile、云开发等，uni-app虽然封装了，但更新不一定跟得上微信官方的节奏。遇到这类问题，最终还是要写条件编译代码，直接调用wx.xxx原生API。所以技术选型时不要单纯看“哪个框架火”，要看团队对底层API的理解能力。

后端选型的考量也是一样的逻辑。Node.js适合快速迭代、前后端语言统一（都是JavaScript/TypeScript），对商城这类业务系统很友好；Java则在事务管理、稳定性、团队招聘上有优势。如果是一家有现成Java团队的零售企业，用Spring Boot更稳；如果是独立开发者或小团队从零开始，NestJS的开发效率更香。我在方案里不强行绑定某一个，但建议开题报告里把两种方案的取舍写清楚，后面实施时就不容易翻烧饼。

2.2 数据库与缓存设计的关键点

商城系统的数据量不会一开始就很大，但表结构必须按“可扩展”的标准设计，否则商品SKU一多、促销活动一叠加，数据库马上成为瓶颈。

核心表我梳理了一遍：

• 用户表：uid、openid、unionid、手机号、昵称、头像、会员等级、邀请人、创建时间；
• 商品表：商品ID、名称、标题、主图、轮播图、详情内容、上下架状态；
• SKU表：规格名、规格值、价格、库存、SKU编码、商品ID；
• 购物车表：用户ID、商品ID、SKU ID、数量、选中状态；
• 订单表：订单号、用户ID、商品快照、总金额、实付金额、支付方式、订单状态、配送方式、核销码、优惠信息；
• 订单明细表：订单ID、商品ID、SKU ID、单价、数量、小计；
• 库存流水表：商品ID、SKU ID、变化数量、变化类型（下单锁定、支付扣减、取消释放）、关联订单号；
• 优惠券表：券模板、领取记录、使用记录、有效期；
• 消息记录表：订阅消息模板ID、发送状态、用户openid、发送结果。

库存设计建议采用“下单锁定库存、支付扣减库存、超时释放库存”的策略。用户在购物车点“去结算”时，系统预占库存，锁定15分钟；超过时间未支付，订单取消并释放库存。这样可以避免超卖，又不至于因为用户占用库存导致商品卖不出去。库存流水表必须完整记录每一次变化，出现超卖或对账问题时，可以倒查到底哪个环节出了错。

Redis在这套系统里不是炫技，而是三个明确用途：

• 缓存热门商品详情，减少MySQL查询压力；
• 存储验证码、临时token、防重复提交标记；
• 存储购物车临时状态，以及订单支付状态机的流转标记。

2.3 登录态与用户体系的前后台配合

登录是商城系统里最容易出错、也最容易被低估的一环。2021年之后微信官方调整了用户信息获取规则，不再支持通过getUserInfo直接拿到头像昵称，必须用头像昵称填写能力或让用户主动授权，很多在小程序上做商城的团队，第一批线上问题就出在这里。

我的方案是“静默登录 + 主动补充”两步走：

第一步，小程序启动后调用wx.login获取code，通过后端接口向微信服务端换session_key和openid。这个openid就是用户在微信生态里的唯一身份标识。后端用自己的session机制或JWT生成登录态返回给前端，小程序端存到storage里，后续请求都带着这个token。

第二步，在用户需要展示头像昵称的场景（比如个人中心、评论功能）时，引导用户使用头像昵称填写能力。不要一进小程序就强制弹授权框，那样转化率会掉很多。最稳妥的做法是：用户逛商品、下单用不到头像昵称，先让他们“游客身份 + openid绑定”也能完成购买，等到需要参与互动时再补全资料。

关于手机号：现在的手机号一键验证组件可以快速拿到用户手机号，但需要企业认证的小程序账号，并且每个用户每次获取都要收费。如果不是强实名场景（比如生鲜配送需要电话联系），建议不强制手机号绑定，让用户能买就行。如果要做会员积分、订单通知，用订阅消息就够了，不一定要绑手机。

2.4 支付流程与订单状态机设计

支付是整个系统里“一次失误影响全局信誉”的部分，绝不能草率接入。

小程序端支付流程看起来简单，就是wx.requestPayment，但后端的支付回调处理和订单状态流转才是真正的重点。我设计的状态机是：

支付回调处理有两个容易踩坑的地方：

• 回调接口必须做签名验证，确认请求确实来自微信支付，不能直接信任请求参数；
• 回调处理要做幂等，同一笔订单的支付成功通知可能会发送多次，必须保证只有第一次执行“状态更新 + 积分发放 + 库存扣减”，后面收到重复通知直接返回成功不再处理。

退款流程最好走微信支付的退款API，退款金额不能超过原订单实付金额。同时要保留退款与订单状态、库存释放的事务一致性。我见过很多系统把退款搞成“先改订单状态，再调退款接口”，结果接口失败后订单状态已经变了，用户没收到钱却看到“已退款”，这个Bug会直接导致客诉。

3. 功能模块拆解与核心流程实现

3.1 商品浏览、检索与SKU选择

恒星商城的商品模块，我按“首页、分类、搜索、商品详情、SKU选择弹层”五块来拆。

首页不追求花哨排版，核心目标是“成交”。顶部是搜索框，下面依次是轮播图banner位、金刚区快捷入口、秒杀或活动专题、普通商品流。分类页用左侧一级分类、右侧二级分类+商品列表的经典结构。搜索支持关键词模糊匹配，后端用MySQL的LIKE或全文索引都可以，前期数据量不大，不需要上ElasticSearch。

商品详情页的设计要点在SKU选择。一个商品有多规格（颜色、尺码）时，前端要做一个“SKU选择弹层”，用户选择规格后，动态显示对应价格、库存和图片。这里有一种常见做法是把所有规格组合的SKU数据一次性返回给前端，由前端计算出可选与不可选项（比如某个颜色+尺码组合没货，选项置灰）。SKU数据用类雪花算法生成唯一编码，避免拼接字符串过长导致索引失效。

我在实际项目里发现，很多新增的商品详情页不做库存实时刷新，导致用户在详情页看到有货，下单时却提示库存不足。解决方法是：详情页进入时和下单前各做一次库存校验，并在SKU弹层里显示剩余库存数量，数量为0时直接隐藏“加入购物车”按钮。

3.2 购物车、下单与库存锁定

购物车功能看起来没什么技术含量，却是用户购物体验最容易出问题的地方。设计时要把“登录态失效”“购物车价格与详情页不一致”“库存数据过期”这三种情况全部考虑到。

购物车在服务端保存还是本地保存？我的建议是：未登录时保存在本地storage，登录后同步到服务端。这样既不会让用户刚打开小程序就看到空购物车，又能跨设备同步。同步策略简单点：以服务端数据为准，登录时把本地购物车合并上去，同名商品数量取两者之和。

下单流程我拆成了四个步骤：

1. 前端携带购物车选中的SKU列表、地址ID、配送方式请求“创建预订单”接口；
2. 后端校验库存是否充足、用户是否满足满减条件、优惠券是否可用；
3. 创建订单（状态为待支付），同时锁定库存，生成预支付单参数；
4. 前端调用wx.requestPayment发起支付。

这个流程里有一个关键的并发控制点：创建预订单时不能只做“查询库存是否大于0”的判断，而是要用数据库行锁或Redis分布式锁把SKU锁住，再判断库存数量并扣除。否则在高并发秒杀场景，两个用户同时看到库存还剩1件，都下单成功，最终库存就成了负的。

3.3 支付回调与订单确认的链式处理

用户支付成功后，微信支付会异步回调商家服务器的通知地址。这个回调必须返回JSON格式的{"code":"SUCCESS"}给微信服务器，否则微信会重复发送通知。

回调处理完订单状态更新后，还可以继续触发一系列后续动作：发送订阅消息通知用户订单已支付、通知商家有新的待接单订单、给用户发积分、记录支付流水。这些动作不要全部放在一个方法里同步执行，否则会拖慢回调响应速度。我习惯用消息队列（RabbitMQ或Redis的Stream）把非核心动作异步化：回调只更新订单状态和支付流水，然后发一条消息进队列，消费者再处理推送、积分、库存扣减等操作。等到业务体量变大后，这种设计能直接平滑升级为分布式架构。

订单确认这块，用户支付后页面会停留在“支付成功”页，此时要展示“查看订单”和“返回首页”两个按钮，不要只给一个“完成”让用户干瞪眼。订单详情页要在前端做一次状态刷新轮询（支付成功后延迟1秒、3秒、5秒查询一次），确保用户看到的状态是准确的。

3.4 配送、自提与售后流程

配送方式设计直接影响物流成本和用户体验。恒星商城初期建议提供三种：

• 到店自提：用户凭订单详情页的核销码到店取货，门店运营人员在小程序管理端输入核销码或扫码核销；
• 同城配送：接入第三方同城配送API，或者商家自建配送团队，由后台人工分配骑手；
• 普通快递：适合非生鲜标品，对接快递物流接口，生成运单号。

自提场景要对核销码做防刷处理。核销码在订单支付成功时生成，采用一单一码，不可重复使用。店员核销后，订单状态直接改为“已完成”，此时前端要提示用户确认取货。

售后流程的核心是“申请、审核、退款/退货、完成”四步状态机。用户发起售后申请时，需要选择售后类型（仅退款、退款退货）、填写原因、上传图片凭证。商家端在48小时内必须处理，超时自动同意，这样可以保护消费者权益，同时逼着商家提高响应速度。退款成功后，库存回补、积分扣回、优惠券回收这三个动作都要在同一个事务里完成，否则会出现用户退了款但积分还在、券还能用的数据不一致问题。

3.5 管理后台与消息触达

管理后台是整个系统的“中控室”。我规划了以下模块：

• 商品管理：录入商品、批量上下架、库存导入导出；
• 订单管理：按状态筛选订单、接单/发货/核销操作、订单备注；
• 用户管理：会员列表、消费记录、标签管理；
• 营销管理：优惠券创建、满减活动配置、秒杀专区设置；
• 数据报表：销售额趋势、商品销量排行、订单状态分布、复购率；
• 系统设置：配送参数、运费模板、客服电话、支付配置。

管理后台技术上不用太复杂，用Vue3 + Element Plus + ECharts就能覆盖全部需求。如果老板和技术团队想省事，直接用现成低代码平台或开源的admin框架也行，但要注意：后续新增功能时，自研比低代码平台更可控。

消息触达这块，微信订阅消息是目前最合规的触达方式。要设计好时机：

• 用户支付成功后，弹窗请求订阅“订单进度通知”，用户在弹窗里点击“允许”后，后续发货、配送、完成等节点可以推送消息；
• 营销类推送（优惠券到期、会员日）需要单独申请长期订阅，受限较多，前期不要作为重点。

消息发送的后端实现要维护一个模板ID和用户openid的映射关系，记录每次发送结果。订阅消息有一次性订阅和长期订阅之分，一次性订阅在用户允许后只能触发一次推送，用户再次操作需要重新唤起授权框。如果订单流程中用户在支付页允许过一次订阅，之后“发货通知”和“完成通知”是两个不同模板，每个模板都要单独申请授权。

4. 实施计划与里程碑安排

4.1 分阶段推进计划

我给这个项目排了一个16周的实施计划，分四个阶段，每个阶段有明确交付物和验收标准。

开发和联调有重叠，是因为前端和后端可以并行工作。前端在UI设计稿完成后马上开工，后端在数据库设计完成后也马上开工，到第6周开始前后端并联调，这样比“前端完事等后端”节约大约三周时间。

4.2 测试与验收要点

商城系统的测试必须覆盖功能测试、兼容性测试、性能测试、安全测试四个维度，不能只用开发者工具模拟器过一遍就上线。

功能测试要重点覆盖：

• 登录：新用户首次登录、老用户换设备登录、token过期后自动重新登录；
• 商品：上下架状态、库存为0时的界面展示、SKU组合选择；
• 下单：正常流程、库存不足、重复提交、支付取消、支付超时；
• 支付：支付成功、支付失败、支付回调重复通知、支付金额不一致；
• 售后：仅退款、退货退款、商家拒绝、超时自动同意。

兼容性测试要用真机在iOS和Android两端跑，覆盖不同屏幕尺寸（尤其是灵动岛设备和小屏安卓机）和微信版本。我见过不止一次WebView兼容性导致H5页面打不开、iOS键盘弹起后页面错位等问题，这类问题模拟器里完全复现不了。性能测试要给核心接口定标准：商品列表接口响应小于300ms，下单接口在下单高峰期不出现超时，支付回调的接口在连续收到重复通知时不会产生重复订单。安全测试重点检查越权问题，比如用户A能否通过篡改订单号查看或操作用户B的订单，这是商城系统绝对不能有的漏洞。

5. 常见技术问题与排查实录

5.1 微信登录获取用户信息失败：wx1cb4398e1413dce7这类报错

我发现很多开发者在遇到“获取登录后的微信用户失败”这种报错时，第一反应是去改前端代码，但其实根因往往出在三个方面：

• 小程序后台的AppID与代码里配置的AppID不一致。有时候因为开发工具缓存或复制项目导致ID变了，接口调用时就会报无权限或参数错误。
• 后端调用code2Session接口时，AppSecret填错或失效。AppSecret一旦重置，所有旧的会话缓存都会作废，线上用户会集体掉登录态。
• 用户网络代理或系统时间不准确，导致请求微信接口时TLS校验失败。

排查思路是从前往后按链条检查：前端拿到code没有，code是否重复使用，后端收到code后是否能成功换取openid，换不到就优先怀疑AppID/AppSecret配置。这里提醒一点：wx.login拿到的code只能用一次，用完了就失效，如果在并发请求里重复消费同一个code，也会报错。

5.2 真机测试报net::ERR_CONNECTION_RESET

很多开发者在小程序真机测试时遇到failed: net::ERR_CONNECTION_RESET，第一反应是“代码写错了”，但这个问题百分之八九十是网络环境或域名配置问题，常见的排查路径如下：

• 开发工具中的“不校验合法域名”选项只在工具里生效，真机上必须把请求域名配置到微信公众平台的“request合法域名”中，且必须是HTTPS接口，证书不能过期；
• 服务器防火墙或安全组没有放行443端口，或者反向代理配置错误导致连接被重置；
• 本机代理工具干扰了真机的网络请求，飞机模式开关切换一下，或更换4G/5G网络测试；
• 后端程序抛异常时没有正常返回HTTP响应，导致微信请求超时后主动重置连接。

这类问题一定要在开发阶段就准备好预发布环境，用正式的域名和HTTPS证书联调，别等上线前一晚才处理。

5.3 开发者工具：maximum setlocal recursion level reached.

这个报错是Windows命令行递归层数达到上限导致的，一般在Node.js依赖安装或项目构建脚本执行时出现。它本身不是小程序业务代码的问题，而是开发环境的系统限制。

我查过解决方案，有几条有效路径：

• 临时调整系统环境变量：把setlocal递归限制调大（通过组策略或注册表修改MaxShellHomeDirectoryLength不是标配，更直接的是一直用管理员身份运行命令行工具）；
• 用PowerShell或Git Bash代替CMD执行构建脚本，通常能绕开这个问题；
• 清理node_modules和package-lock.json后重新安装依赖，有时候是某个依赖包损坏导致的递归异常。

这类环境问题在团队协作中很常见，建议把开发环境要求写进项目的README，统一Node版本和包管理器版本，避免成员之间因为环境不一致消耗大量排查时间。

5.4 小程序分包：让首页启动更快

商城系统最大的性能杀手是主包体积过大。微信小程序主包限制是2MB，如果商品图片、公共组件、页面全塞在一起，很容易超限，直接导致无法上传和发布。

我的方案是：

• 把启动阶段必用的页面放进主包（首页、登录页、商品列表、商品详情）；
• 把低频页面放进分包（订单列表、售后、个人中心、优惠券等）；
• 公共组件和插件抽取成独立分包或使用微信的“分包异步化”特性，在页面需要时动态加载；
• 图片不要直接打包进代码，所有商品图和详情图都放云存储或CDN，用压缩后的webp格式，降低流量消耗。

分包之后要注意tabBar页面的归属。微信规定tabBar页面必须在主包中，所以底部导航涉及的个人中心、首页、分类、购物车这些页面不能放进分包。自定义tabBar是一个可选的优化方案，按需加载图标字体和资源，但实现复杂度会高一些，不是必需品。

5.5 自定义tabbar与顶部导航栏高度适配

使用自定义tabBar的场景通常是业务需要特殊图标、中间凸起按钮、或者对不同用户角色展示不同导航。这个功能需要用custom-tab-bar目录实现，并要在组件的pageLifetimes.show里同步选中状态，否则从二级页面返回时tab高亮会丢失。

顶部导航栏高度适配是另一个高频问题。微信小程序的导航栏会根据手机型号的刘海屏、灵动岛变化高度，不能直接写死一个像素值。正确做法是调用wx.getWindowInfo()获取statusBarHeight，再结合胶囊按钮位置计算导航栏总高度，把占位视图的高度动态设置为这个值。自定义导航栏做好后，在iPhone 14 Pro和普通安卓机上分别跑一遍，就能发现高度适配的差异。

6. 上线前必须解决的三个风险

6.1 用户隐私与合规风险

2025年小程序审核对用户隐私的审查越来越严格。商城系统需要用户授权手机号、地址、地理位置（配送场景），必须在隐私协议里明确说明这些信息的用途、存储方式、删除方式。小程序管理后台需要配置用户隐私保护指引，收集的用户信息要“最小化”。比如只是做商城，就不要偷偷获取用户的通讯录或相册权限，否则审核大概率被拒，甚至有封禁风险。

技术侧要做到：

• 开发者工具里勾选隐私相关接口声明；
• 每次调用地理位置、手机号能力前，先检查用户是否已同意隐私协议；
• 后端日志不记录明文手机号、详细地址等敏感信息，要用脱敏方式保存。

6.2 支付与资金安全风险

支付资金安全是商城系统的生命线。最关键的设置是支付密钥（APIv3密钥）的保管，绝不能硬编码在前端代码或版本仓库里。生产环境密钥要由专人分发，支持定期轮换。

后端处理支付回调时严格做到三点：用微信支付平台证书验证签名、校验订单号和金额与商户订单一致、成功后幂等写入支付记录。同时在管理后台提供每日对账功能，保证微信支付账单与本地订单记录一致。一旦出现对不上的账目，系统要能快速定位到具体订单和流水，而不是人工一单单去翻。

6.3 促销活动与库存一致性问题

商城上线后，第一个活动往往就是满减或秒杀。这时候最容易出现的问题就是库存扣减和优惠叠加计算错误。解决方案是提前做好活动规则引擎：

• 优惠计算放在服务端，不依赖前端传入的优惠金额；
• 同一笔订单只能使用一张优惠券，优惠券和满减活动是否可叠加要提前配置；
• 秒杀活动提前把库存预热到Redis，并用Lua脚本原子扣减，避免并发超卖。

这种问题一旦上线后出现，处理成本非常高，因为它直接涉及资金和用户情绪。最好在测试阶段就引入并发脚本压测，模拟100个用户同时抢购同一SKU，检查最终库存和订单数是否一致。

7. 从开题到落地，我的几点实际体会

这个项目从开题到真正上线，周期大概四个月。回头复盘，有几点经验值得分享。

第一，开题报告不要写得像学术论文，要把“投入产出比”想清楚。老板或投资人关心的不是技术多炫，而是系统能不能带来订单增长、能不能降低人工成本、能不能沉淀用户资产。开题材料里尽量把需求场景、功能边界、上线规划、预期效果讲具体，这决定了项目能不能获得足够的资源支持。

第二，不要试图在第一个版本覆盖所有需求。恒星商城线上订购系统，第一版只需要把“商品展示、下单支付、订单管理、基础营销”做扎实。会员等级、积分商城、分销裂变这些听起来很美，但会拖慢上线节奏。上线后根据用户反馈迭代，比憋一个大而全的版本更稳。

第三，技术栈要选团队最熟的，而不是最流行的。小程序商城的技术难度并不在某个单点，而在多个子系统（前端、后端、支付、管理端、数据统计）的串联。团队熟练度决定容错率，换一套新框架带来的隐性成本，往往比想象中大得多。

第四，微信支付的调试流程比想象中繁琐。从申请商户号、绑定AppID、配置回调域名，到开通APIv3、下载平台证书，每一步都容易卡住。建议把准备工作列成清单，提前半个月启动，别等到开发联调时才去申请，我一个朋友就因为在支付环节卡了两周导致整个排期延期。

第五，尽量在开发环境就用真实微信能力和正式环境联调。模拟器能覆盖70%的开发调试需求，但真机上的登录、支付、订阅消息、地理位置这些能力，模拟器里表现和真机差异很大。项目早期就申请好测试号，每周安排一次真机验收，问题越早暴露，修复成本越低。

最后再分享一个小技巧：把“订单状态流转图”和“支付回调处理流程图”打印出来贴在工位旁边。商城开发过程中，大多数让团队争吵的问题，最后都能追溯到对状态定义或回调时序的理解不一致。这两张图画清楚，项目就成功了一半。