小程序 + 管理后台 + API 的典型架构怎么设计？

工程现场：一条预约或订单链路怎么守住

小程序只是入口，真正复杂的是后端同时面对用户点击、员工操作、支付回调、订阅消息和后台任务。我们会把预约或订单建成明确状态机，例如待确认、已确认、服务中、已完成、已取消，并限制每个角色能执行的转换。页面按钮只是状态机的表现，最终判断必须在后端。

微信身份不能直接等同于业务账号

openid 用于识别微信用户，但同一客户可能有多个联系方式，员工也可能同时属于不同门店。系统需要自己的用户、会员、员工、门店和角色模型，再把微信身份作为登录凭证绑定。敏感接口使用短期会话或令牌，后台管理员采用独立登录和更严格的权限策略，不能因为拿到 openid 就拥有业务权限。

支付回调必须幂等并以服务端结果为准

客户端显示支付成功不代表系统已确认收款。后端需要校验回调签名、商户号、金额和订单号，以支付流水号或订单号建立唯一约束。重复回调只返回成功，不重复改状态、发券或通知。退款同样记录申请、渠道流水和最终状态，并通过对账任务发现长时间未确认的异常交易。

消息通知是可失败的副作用

订单落库和消息发送不要放在一个长事务中。核心状态提交后写入待发送事件，由后台任务调用订阅消息、短信或企业微信；失败按规则重试并保留原因。模板缺失、用户未授权、第三方限流都不应该让订单创建失败，但后台必须能看到哪些通知没有送达。

发布要考虑多版本客户端并存

小程序审核和用户更新并非同时发生，接口需要兼容一段时间内的新旧客户端。新增字段尽量保持可选，状态枚举不要随意复用旧值，破坏性变更通过新接口版本过渡。上线前除了功能测试，还要验证弱网、重复点击、返回重进、支付中断和后台改状态等场景。

一笔预约从小程序到后台的完整技术链路

微信身份与业务账号要分开建模

登录接口用临时 code 换取平台标识，但 openid 不是业务主键。系统建立 user、external_identity 和 customer_profile 的映射，记录 appid、openid、unionid 与绑定时间；手机号变更或多个渠道合并时，订单仍归属同一个业务用户。服务端签发自己的短期会话，前端不保存平台密钥，也不把 openid 当成可随意传入的可信参数。

预约名额要在数据库里防止超卖

时间段表保存容量与版本，用户提交后先创建短时 reservation，再确认订单。扣减容量与写预约单放在同一事务，使用行锁、乐观锁或唯一约束保证并发下只成功一次。前端显示“还有一个名额”只是提示，最终判断必须在服务端完成；重复点击通过 client_request_id 返回第一次结果。

支付回调必须幂等并校验业务金额

回调入口先验签，再以渠道交易号和事件类型做唯一约束，核对商户号、订单号、币种与金额后才推进订单状态。状态迁移只能从待支付进入已支付，已取消订单收到迟到回调则进入人工或自动退款流程。接口先快速应答，通知、积分和报表通过 outbox 异步处理，避免渠道因超时反复推送。

后台操作和用户通知都要可追溯

改期、取消、核销和退款分别定义权限动作，并记录操作前后状态、操作人和原因。订阅消息写入通知任务表，按业务事件发送，失败可重试但不重复触达。API 变更采用兼容字段或版本策略，监控按订单号串联小程序请求、后台操作、支付回调和消息发送，客服才能快速解释一笔订单发生了什么。