Medusa订单处理从pending到completed订单要过哪3道关【免费下载链接】medusaThe worlds most flexible commerce platform for agents and developers项目地址: https://gitcode.com/GitHub_Trending/me/medusa一笔Medusa订单处理请求执行完订单往往并不是结束了——后台里停在pending状态的订单是常态关键在于分辨它是正常流转中还是真的卡住了。这篇文章跟着代码走一遍一笔订单的旅程把它经过的3道关拆开看。pending什么时候不算卡住OrderStatus在 common.ts 里只定义了6个值pending、completed、draft、archived、canceled、requires_action。pending表示订单已创建但库存确认和履行还没发生。创建入口是createOrderWorkflow工作流id叫create-orders代码在 create-order.ts内部依次做定位region、找或建客户、校验行项目价格、确认库存足够然后落库。落库后status就是pending——订单刚离开发令枪没被处理本来就是它该有的样子先别急着报警。库存履行环节最容易踩的坑⚠️ create-order.ts 的注释里有一句很直白的提醒这个workflow只校验库存够不够并不会为订单商品创建库存预留reservation。后果是如果变体开了manage_inventory你直接拿createOrderWorkflow造出来的订单去履行createOrderFulfillmentWorkflow会因为没有对应reservation而报错。正确姿势是先跑createReservationsWorkflow给每个预留带上line_item_id履行workflow靠它把预留找到。履行workflow的校验逻辑写得相当死板create-fulfillment.ts订单不能是canceled、items必须真实存在于订单里、items要按shipping requirement分组任何一条不满足直接抛错。通过后它会并行做几件事调整库存水位adjustInventoryLevelsStep、清掉用掉的reservation最后registerOrderFulfillmentStep把履行记录写进订单行项目的fulfilled_quantity也是在这一步更新的。要改订单别直接改字段订单的增删改查集中在OrderServiceorder-service.ts但注意它不会直接改动一笔已创建的订单。v2里改单走的是订单变更机制——用createOrderChangeWorkflow建一个order change它的状态机OrderChangeStatus有5个值requested、pending、confirmed、declined、canceled只有confirmed之后变更才会真正落进订单同时订单的version加一。OrderDTO里那个version字段不是摆设每次confirmed的变更都会递增它对账和排查这单怎么变成这样时靠它就能回溯到某一时刻的订单快照。退货之后数量去哪了客户退回商品不是简单扣一个数字。退货有独立的一套workflow在 packages/core/core-flows/src/order/workflows/return/ 目录下而订单模块的action层把每个数量变化都拆成了专门的文件fulfill-item.ts管fulfilled_quantitydeliver-item.ts管签收ship-item.ts管发货——都放在 packages/modules/order/src/utils/actions/ 里想核对某个字段何时变去那里按文件名找就行。换货exchange同理在旁边的exchange/目录。接下来读哪3个地方状态与DTO定义packages/core/types/src/order/common.ts全部订单workflowpackages/core/core-flows/src/order/workflows/一个文件一个流程create、fulfill、complete、cancel、return、exchange都在里面订单模块服务与模型packages/modules/order/src/services/ 和 models/想本地跑起来验证先克隆仓库git clone https://gitcode.com/GitHub_Trending/me/medusa建议从 integration-tests/http/tests/order/ 下的用例入手配合源码读create-fulfillment这个workflow——它的校验和预留逻辑理顺了剩下那套状态机基本就是顺水推舟的事。【免费下载链接】medusaThe worlds most flexible commerce platform for agents and developers项目地址: https://gitcode.com/GitHub_Trending/me/medusa创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Medusa订单处理：从pending到completed，订单要过哪3道关
Medusa订单处理从pending到completed订单要过哪3道关【免费下载链接】medusaThe worlds most flexible commerce platform for agents and developers项目地址: https://gitcode.com/GitHub_Trending/me/medusa一笔Medusa订单处理请求执行完订单往往并不是结束了——后台里停在pending状态的订单是常态关键在于分辨它是正常流转中还是真的卡住了。这篇文章跟着代码走一遍一笔订单的旅程把它经过的3道关拆开看。pending什么时候不算卡住OrderStatus在 common.ts 里只定义了6个值pending、completed、draft、archived、canceled、requires_action。pending表示订单已创建但库存确认和履行还没发生。创建入口是createOrderWorkflow工作流id叫create-orders代码在 create-order.ts内部依次做定位region、找或建客户、校验行项目价格、确认库存足够然后落库。落库后status就是pending——订单刚离开发令枪没被处理本来就是它该有的样子先别急着报警。库存履行环节最容易踩的坑⚠️ create-order.ts 的注释里有一句很直白的提醒这个workflow只校验库存够不够并不会为订单商品创建库存预留reservation。后果是如果变体开了manage_inventory你直接拿createOrderWorkflow造出来的订单去履行createOrderFulfillmentWorkflow会因为没有对应reservation而报错。正确姿势是先跑createReservationsWorkflow给每个预留带上line_item_id履行workflow靠它把预留找到。履行workflow的校验逻辑写得相当死板create-fulfillment.ts订单不能是canceled、items必须真实存在于订单里、items要按shipping requirement分组任何一条不满足直接抛错。通过后它会并行做几件事调整库存水位adjustInventoryLevelsStep、清掉用掉的reservation最后registerOrderFulfillmentStep把履行记录写进订单行项目的fulfilled_quantity也是在这一步更新的。要改订单别直接改字段订单的增删改查集中在OrderServiceorder-service.ts但注意它不会直接改动一笔已创建的订单。v2里改单走的是订单变更机制——用createOrderChangeWorkflow建一个order change它的状态机OrderChangeStatus有5个值requested、pending、confirmed、declined、canceled只有confirmed之后变更才会真正落进订单同时订单的version加一。OrderDTO里那个version字段不是摆设每次confirmed的变更都会递增它对账和排查这单怎么变成这样时靠它就能回溯到某一时刻的订单快照。退货之后数量去哪了客户退回商品不是简单扣一个数字。退货有独立的一套workflow在 packages/core/core-flows/src/order/workflows/return/ 目录下而订单模块的action层把每个数量变化都拆成了专门的文件fulfill-item.ts管fulfilled_quantitydeliver-item.ts管签收ship-item.ts管发货——都放在 packages/modules/order/src/utils/actions/ 里想核对某个字段何时变去那里按文件名找就行。换货exchange同理在旁边的exchange/目录。接下来读哪3个地方状态与DTO定义packages/core/types/src/order/common.ts全部订单workflowpackages/core/core-flows/src/order/workflows/一个文件一个流程create、fulfill、complete、cancel、return、exchange都在里面订单模块服务与模型packages/modules/order/src/services/ 和 models/想本地跑起来验证先克隆仓库git clone https://gitcode.com/GitHub_Trending/me/medusa建议从 integration-tests/http/tests/order/ 下的用例入手配合源码读create-fulfillment这个workflow——它的校验和预留逻辑理顺了剩下那套状态机基本就是顺水推舟的事。【免费下载链接】medusaThe worlds most flexible commerce platform for agents and developers项目地址: https://gitcode.com/GitHub_Trending/me/medusa创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 RELATED READING
延伸阅读
更多一线实战笔记与深度复盘，助您持续精进
