一个真实业务系统的三端闭环怎么搭

很多人说自己做过“全栈项目”，最后拿出来的其实是一组页面，或者一个能跑的 demo。栖光这类项目更难的地方不在页面多少，而在于它是不是一套真的能承接业务的系统。

这篇文章想讲清楚的就是：为什么一个酒吧/餐饮场景下的小程序点餐与商城系统，会自然长成微信小程序、后台管理和后端服务三端协作的结构；以及这三端到底是怎么围绕同一套订单与运营逻辑闭合起来的。

三端闭环不是技术拆分，而是业务拆分

栖光面向的不是抽象用户，而是比较具体的门店场景：顾客需要在微信里完成堂食点餐、商城购买、支付、查看订单和申请退款；运营人员需要在后台维护商品、分类、公告、优惠券、营业时间和订单；系统本身还要保证支付、退款、库存、地址快照、积分、看板统计这些状态不要互相打架。

所以它天然会拆成三端：

• 小程序负责顾客侧体验。
• 后台负责门店运营和处理动作。
• 后端负责业务规则、状态流转和数据一致性。

这不是“前后端分层”那么简单，而是三类角色本来就在做三件不同的事。顾客关心能不能顺畅下单，运营关心今天有哪些订单待处理、哪些商品该调整，后端关心这笔订单到底处于什么状态、退款后哪些金额和积分要回滚、看板应该按什么口径统计。

如果没有这种拆分，最后通常会出现两种问题：要么前台能演示但一碰真实订单就乱，要么后台能录数据但和用户实际链路脱节。三端闭环的价值，就是把这三件事接成一套系统，而不是三个彼此独立的小项目。

栖光这套系统里，三端分别在做什么

小程序不是展示页，而是顾客交易入口

栖光的小程序承接的是顾客真实操作。它覆盖首页、点餐、商城、商品详情、订单列表、订单详情、个人中心这些典型页面，但重点不在页面数量，而在链路完整性。

顾客在小程序里会做几类事：

• 堂食场景下浏览点餐商品、加入购物车、录入桌号和备注，再进入订单详情确认支付。
• 商城场景下浏览周边商品、选择收货地址、提交订单并查看配送相关信息。
• 已支付后查看订单状态，必要时发起退款申请。
• 在“我的”里查看余额、累计消费、优惠券、积分和历史订单。

这里最关键的一点是：小程序不是直接把一堆输入随便发给后端。项目里已经把点餐和商城都整理成了明确的下单流程，比如点餐前需要桌号和人数，商城订单需要地址快照，草稿态订单详情允许用户回退修改，确认支付时才真正创建订单并发起支付。也就是说，小程序承载的是“顾客如何完成一次交易”，不是“把表单字段凑齐”。

后台不是附属页面，而是门店工作台

后台对应的是运营和履约角色，所以它和小程序不是一套页面换个皮。

在栖光里，后台负责的内容包括：

• 商品、分类、库存、上下架与库存预警。
• 订单查看、订单状态处理、制作中进度、发货和退款审核。
• 用户、优惠券、用户标签、地址查看、积分和存酒等客户资产能力。
• 公告、营业时间、私域入口、桌号二维码、歌曲与每日驻唱等门店配置。
• 数据看板、待处理事项、趋势分析和最近订单。

这说明后台的核心职责不是“把数据库内容展示出来”，而是给运营人员一个能工作的界面。比如订单管理不是只读列表，它要能处理待确认订单、制作中订单和退款；数据看板也不是简单图表，它要支持门店在营业中判断今天的经营状态和待处理事项。

后端才是这套闭环真正的中轴

三端里最不能散的是后端，因为它决定整个系统对“订单”这件事到底怎么理解。

从现有项目文档和数据库结构看，栖光的后端至少承担了几件核心工作：

• 用 Express + TypeScript + tsoa 提供业务 API，并生成 OpenAPI 契约。
• 用 MySQL 作为业务事实源，Redis 处理缓存、会话和限流，OSS 处理图片与文件。
• 统一订单、支付、退款、优惠券、地址、积分、库存等规则。
• 把同一份接口契约生成给 Admin 和小程序，减少联调时的类型漂移。

这层最重要的不是“提供接口”四个字，而是把状态定义清楚。比如 orders 表里已经明确区分：

• order_type：1 点餐订单，2 周边订单，3 充值订单。
• payment_status：待支付、已支付、已退款、部分退款、已取消。
• order_status：待确认、制作中、已完成、已取消、已发货。

这意味着系统不是把“订单完成了没有”混成一个模糊布尔值，而是把交易状态和履约状态拆开。对于真实业务系统，这种拆分非常重要，因为支付成功不等于已经出品，商城发货也不是堂食制作中的同一回事。

真正把三端串起来的，不是页面跳转，而是一条订单链路

如果只讲“有小程序、有后台、有后端”，文章还是容易变空。栖光真正有说服力的地方，在于它已经有了比较清楚的链路模型。

堂食点餐链路

一条典型的堂食链路大致是这样：

1. 顾客进入小程序点餐页，浏览商品，加入购物车。
2. 小程序要求先确认桌号、人数和备注，再进入订单详情草稿。
3. 顾客确认支付时，后端创建正式订单并发起支付。
4. 支付成功后，订单进入已支付状态，后台可以在订单列表或制作看板里看到这笔单。
5. 运营人员将订单推进到制作中，订单项可以逐项完成，最后一项完成后订单自动进入已完成。

这里三端的职责非常清楚：

• 小程序负责把顾客动作组织成一个顺畅的下单过程。
• 后端负责把桌号、商品、金额、支付结果和状态流转写成一笔可信订单。
• 后台负责把“已支付的订单”继续推进成“被处理完成的订单”。

如果缺任何一端，这条链路都不闭合。只有小程序，没有后台，订单没人履约；只有后台，没有小程序，顾客无法自助完成交易；只有接口，没有明确状态模型，支付、制作和完成就会混乱。

商城购买链路

商城链路和堂食很像，但业务重点不同：

1. 顾客在小程序商城浏览周边商品并加购。
2. 下单时选择地址，系统把收货信息保存成订单地址快照。
3. 用户确认支付后创建正式订单。
4. 后台查看订单、处理发货，订单进入已发货状态。
5. 如果用户后续申请退款，退款记录会影响订单状态，也会影响资金统计和看板口径。

这条链路里最能体现系统性的细节，是“地址快照”而不是“地址表”。项目没有把历史订单直接绑定到用户当前地址，而是把当时的收货信息写进订单快照里。这样用户后面改地址，不会把历史订单改坏。这个设计很小，但它正是业务系统和演示项目的差别。

图：栖光业务系统核心实体关系图。订单是三端闭环的中心实体，商品、支付、退款、优惠券、地址快照、积分流水和数据看板都围绕订单形成业务关系。

为什么说它已经不是功能堆砌，而是一个业务模型

栖光里最值得写出来的，不是某个单页，而是几个已经稳定下来的业务对象关系。

例如：

• 商品和规格决定顾客能买什么。
• 订单和订单项承接一次具体交易。
• 优惠券影响实付金额，并需要在订单里保留用券结果。
• 地址快照决定商城订单后续如何履约。
• 退款记录不仅改变订单状态，还会反映到资金口径。
• 积分发放和退款扣回要跟支付、退款流程保持一致。

这些对象不是孤立模块，而是互相牵连的。你只要把其中一个地方做得过于草率，另外两端迟早会被拖垮。

一个很典型的例子是后台数据看板。这个项目后续已经开始把经营口径和资金口径拆开，不再用一个模糊的“营业额”包打天下。经营成交额、净营业额、微信实收、余额支付、充值入账、退款影响，本来就不是同一个概念。能把这些概念拆清楚，说明这个项目已经不只是“订单增删改查”，而是开始进入真实运营系统的范畴。

三端闭环里，最容易被忽略的是契约一致性

很多项目的三端问题，不是缺功能，而是每一端对同一件事理解不同。

栖光是明确把 tsoa / OpenAPI 当成接口契约源，然后再给 Admin 和小程序生成对应客户端。这样做的意义不是“技术看起来高级”，而是把三端的协作成本降下来：

• 后端改了字段或接口，契约会同步变化。
• Admin 不需要手写一套类型猜接口。
• 小程序也不用靠口口相传理解订单和用户结构。

对一个真实业务系统来说，这种契约一致性是闭环的一部分。因为闭环不只是用户链路跑通，还包括后续迭代时三端能不能持续一起演进。

这篇文章真正想证明什么

如果把栖光简单介绍成“一个微信小程序 + React 后台 + Node.js 后端项目”，其实会把它说小了。

它更准确的价值在于：

• 我不是只做了页面，而是做了一条完整的顾客交易链路。
• 我不是只写了接口，而是把订单、支付、退款、地址、优惠券、积分和看板放进同一套业务模型里。
• 我不是只做了一个管理后台，而是做了一个门店运营真正能用的工作台。
• 我不是只让系统能跑，而是开始让它能维护、能扩展、能继续交付。

当然，这个项目也还没到可以无限拔高的程度。现有文档里仍然保留了一些待确认项，比如生产微信支付商户配置和公网回调的真实联调结果，还没有在现有资料里完全闭环。所以这篇文章最稳妥的表达方式，不是吹成“已经完整商业上线”，而是把它写成一个已经具备真实业务结构和持续演进能力的三端系统样本。

这恰好也是我觉得它值得写成文章的原因。它不是“我会三个技术栈”的证明，而是“我知道怎样让三类角色围绕同一套业务对象协同工作”的证明。