€3.29月租的服务器不会替你挡生产环境的子弹。Medusa v2确实进步了——无头架构、工作流引擎、新版管理API都比v1强一截。但文档只覆盖80%的场景，剩下的20%专门吞噬周末。这是我在nadiapoe.co.uk商城里撞上的三个Bug，修复都简单，但没有一个修复是显而易见的。
Bug 1：运费规则的隐式类型陷阱
店铺有两个配送选项，设计意图是用小额激励推动稍大额的印刷订单：
• 标准配送——£4.50，始终可用
• 免费配送——£0，购物车小计≥£60时可用
测试发现：£100的购物车，免费配送消失了，系统自动选中标准配送。刷新、清空、重试——结果一样。更诡异的是：£10的测试购物车反而能正确显示免费配送。规则配置没错，数据库数据看起来也对。问题藏在中间层。
问题埋在@medusajs/fulfillment/dist/utils/index.js里。gte/lt规则的比较器这样写：
const left = Date.parse(a)
const right = Date.parse(b)
if (!isNaN(left) && !isNaN(right)) {
return new Date(left) < new Date(right) // 日期分支
}
return Number(a) < Number(b) // 数值分支
看起来合理，直到你想起Date.parse对裸整数字符串的处理：
Date.parse("60") // → -315619200000（1960年——两位数年份扩展）
Date.parse("100") // → -59011459125000（公元100年）
Date.parse("60.00") // → NaN
£100购物车，cart_subtotal = "100"，规则值是"60"。评估变成Date(公元100年) < Date(1960年)→ true。"当小计低于£60时显示此选项"的条件，在购物车价值接近阈值两倍时触发了。免费配送被剥离。
修复只需一个toFixed(2)。在api/src/workflows/shipping-options-context.ts：
import {
listShippingOptionsForCartWorkflow,
listShippingOptionsForCartWithPricingWorkflow,
} from "@medusajs/medusa/core-flows"
import { StepResponse } from "@medusajs/framework/workflows-sdk"
const injectCartSubtotal = async ({ cart }: { cart: any }) =>
new StepResponse({ cart_subtotal: (cart.item_total ?? 0).toFixed(2) })
listShippingOptionsForCartWorkflow.hooks.setShippingOptionsContext(injectCartSubtotal)
listShippingOptionsForCartWithPricingWorkflow.hooks.setShippingOptionsContext(injectCartSubtotal)
数据库存储的规则值必须匹配同样格式——"60.00"而非"60"。混合格式会让修复失效。
热门跟贴