一次订单在 Medusa 后台经历了什么【免费下载链接】medusaThe worlds most flexible commerce platform for agents and developers项目地址: https://gitcode.com/GitHub_Trending/me/medusa在 Medusa 里买家点下支付后订单不会落库就安静下来——它会开始在一串状态和工作流之间流转后台的每次变化都是状态迁移。下面以一笔订单为主线走一遍下单 → 改单 → 发货 → 退货的四个阶段并附上对应的工作流与源码位置。读完之后你能回答三个实际问题订单状态从哪来、修改订单该调哪个工作流、处理退货时要盯住哪些状态。订单状态定义一共 6 个取值订单状态集中定义在OrderStatus这一个类型里文件是订单类型定义type OrderStatus | pending // 已创建未处理 | completed // 已完成 | draft // 草稿 | archived // 已归档 | canceled // 已取消 | requires_action // 需进一步操作串起来看pending表示订单已创建但还没被处理requires_action比较特殊说明流程卡住了需要人或支付再走一步draft和archived用于草稿与历史数据canceled与completed则是两个终态。下单createOrderWorkflow 与 OrderService创建订单由工作流createOrderWorkflow牵头它一口气处理商品校验、价格计算和促销应用然后把订单写进初始的pending状态真正的持久化与查询逻辑交给OrderService源码在 order-service.ts。 避坑支付未完成时订单会停在requires_action而不是pending。写监控逻辑时优先处理这个状态别假设新订单都还在排队。改单中途订单变更状态机创建后要增删商品或换配送方式别直接改订单字段走createOrderChangeWorkflow它和其余订单工作流一起放在订单工作流目录下。订单变更有自己的一套状态OrderChangeStatusrequested、pending、confirmed、declined、canceled。关键点是变更提出后并不立刻生效要等到confirmed才写入订单待结算差额记录在pending_difference字段里。从发货到完结最后两推发货由createOrderFulfillmentWorkflow负责先核对库存再更新订单行项目的已履行数量。全部商品出库后completeOrderWorkflow执行最后的库存冲销与财务落账订单状态随之推进到completed。退货与换货两个异常分支退货和换货被建模为挂在订单上的独立动作分别由对应的工作流目录处理退货ReturnStatus取值为requested、received、partially_received、canceled。注意partially_received不是终态别提前关单换货由exchange目录下的步骤执行完成后生成新的行项目并关联回原订单。下一步看源码git clone https://gitcode.com/GitHub_Trending/me/medusa【免费下载链接】medusaThe worlds most flexible commerce platform for agents and developers项目地址: https://gitcode.com/GitHub_Trending/me/medusa创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考