订单状态机如何设计？mern-marketplace订单管理从“Not processed“到“Delivered“完整指南-育师

订单状态机如何设计？mern-marketplace订单管理从"Not processed"到"Delivered"完整指南

【免费下载链接】mern-marketplaceA MERN stack based online marketplace application [Full-Stack React Projects]项目地址: https://gitcode.com/gh_mirrors/me/mern-marketplace

如果你正在用MERN 技术栈（MongoDB + Express + React + Node.js）搭建在线商城，一定会遇到这个问题：订单状态机如何设计？开源项目 mern-marketplace 给出了一个非常值得学习的实战答案——它没有把状态放在"订单"整体层面，而是把订单状态管理下放到订单内的每一个商品项上，用 5 个英文状态Not processed → Processing → Shipped → Delivered（外加Cancelled分支）完整覆盖电商履约全流程。本文带你彻底看懂这套设计。

为什么"按商品"追踪状态更聪明？

传统电商中，一个订单往往只包含一家店铺的商品，整单一个状态就够了。但在 mern-marketplace 这类多店铺集市（marketplace）里，一个订单可能横跨多个商家。如果整单共用一个状态，就会出现尴尬局面：A 店已发货、B 店还在备货，整单状态该写什么？

mern-marketplace 的做法是在数据模型层面就解决了这个问题——订单（Order）由一组子文档（CartItem）组成，每个 CartItem 拥有独立的status字段。你可以在 server/models/order.model.js 中看到这个核心定义：

字段	说明
`product`	关联的商品 ID
`shop`	关联的店铺 ID（多店铺场景的关键）
`quantity`	购买数量
`status`	该商品项的履约状态，默认`Not processed`

💡 这就是状态机设计的精髓：把状态的"主体"定义清楚。主体是"订单中的商品项"，而不是"订单"。

订单状态机全景图：5 个状态的完整流转

状态取值被硬编码在 Mongoose Schema 的enum中（见 server/models/order.model.js），数据库层面自动拦截一切非法值：

Not processed ──► Processing ──► Shipped ──► Delivered │ └────────► Cancelled（终态，库存回补）

状态	含义	触发动作	联动逻辑
📥 Not processed	未处理（默认值）	下单时自动写入	库存已预扣减
⚙️ Processing	备货中	店主手动更新	自动触发 Stripe 扣款
🚚 Shipped	已发货	店主手动更新	仅更新状态
✅ Delivered	已送达	店主手动更新	仅更新状态
🚫 Cancelled	已取消	店主手动更新	自动恢复商品库存

注意这张表里最有趣的一点：状态流转不是"随便改"的，不同状态背后绑定着完全不同的业务逻辑——这正是"状态机"区别于"普通字符串字段"的地方。

状态机落地的三个关键设计

1️⃣ 状态值由后端统一下发，前端零硬编码

店主后台的状态下拉框不是写死在 React 组件里的，而是通过接口/api/order/status_values从后端拉取。后端控制器 server/controllers/order.controller.js 直接从 Mongoose Schema 的enumValues中读取：

好处：前后端永远一致。将来在 Schema 里加一个新状态（比如Refunded），前端一行代码都不用改，下拉框自动出现新选项。
前端调用入口在 client/order/api-order.js 的getStatusValues。

2️⃣ 状态变更路由"按状态分流"，业务逻辑与状态强绑定

这是整个状态机最精妙的设计。路由文件 server/routes/order.routes.js 把"更新状态"拆成了3 条独立路由，前端在 client/order/ProductOrderEdit.js 中根据用户选择的状态决定调用哪一条：

用户选择的状态	调用路由	路由上的中间件链	业务效果
`Cancelled`	`/api/order/:shopId/cancel/:productId`	鉴权 → 店主校验 →`increaseQuantity`→`update`	库存回补 + 状态更新
`Processing`	`/api/order/:orderId/charge/:userId/:shopId`	鉴权 → 店主校验 →`createCharge`→`update`	Stripe 扣款 + 状态更新
其他	`/api/order/status/:shopId`	鉴权 → 店主校验 →`update`	仅状态更新

其中库存联动逻辑分别位于 server/controllers/product.controller.js：

下单时decreaseQuantity用bulkWrite批量扣减（多商品一次完成）；
取消时increaseQuantity用findByIdAndUpdate精确回补对应商品。

⚡ 状态 + 副作用（扣款、库存）被打包在同一条路由中间件链里，保证了"改了状态，钱和库存一定同步变"，不会出现状态与业务脱节的脏数据。

3️⃣ 状态更新使用 MongoDB 定位更新，精准不伤及兄弟节点

状态最终由 server/controllers/order.controller.js 的update落库：以products._id为条件，只修改products.$.status这一个路径。一张订单里改 A 商品的状态，绝不会影响 B、C 商品——这依赖第 1 节中"状态挂在子文档上"的模型设计。