订单与促销计算
电商系统容易被做成“能下单的商城”。活动一开，库存超卖、优惠算错、支付成功但订单没生成、退款原路退不回去，客服和仓库同时炸。我们做电商，先把中间那本账立住：SKU 库存是唯一事实，下单占库、支付超时释放、发货扣减、退货回库，状态机写清楚，不允许后台手工改库存当常规手段。商品、价格、运费模板、活动规则在后台可配，但计算顺序要在方案里定死——满减、券、会员价、秒杀谁先谁后，对账时才不会各说各的。
线上生意的系统压力集中在两端：前端要快、要能做活动，后端要能对账、能履约。中间的库存和订单状态是两端的共同事实。
电商系统容易被做成“能下单的商城”。活动一开，库存超卖、优惠算错、支付成功但订单没生成、退款原路退不回去，客服和仓库同时炸。我们做电商，先把中间那本账立住：SKU 库存是唯一事实，下单占库、支付超时释放、发货扣减、退货回库，状态机写清楚，不允许后台手工改库存当常规手段。商品、价格、运费模板、活动规则在后台可配，但计算顺序要在方案里定死——满减、券、会员价、秒杀谁先谁后，对账时才不会各说各的。
多渠道是电商的日常，不是加分项。自有小程序、视频号、平台店铺如果订单和库存不汇合，仓库会按三个世界发货。我们会把渠道订单收进同一履约队列，库存共享或按渠道配额，售后按原单原渠道退。支付要对渠道、对商户号、对退款单；对账差异生成待处理清单，而不是财务每月导出三份 Excel 对通宵。
履约比页面更决定复购。客户记住的不是首页动画，而是什么时候发货、物流到哪、少件怎么赔。订单状态要对仓库、对快递、对客户可见；缺货、拆包、延迟发货要有原因和通知。促销页可以每周改，履约规则不能上周一个样这周一改。客服需要的是按订单能看到优惠明细、支付流水、发货记录，而不是让客人把聊天记录截图过来。
客服工具要按订单看到优惠明细、支付流水、发货记录和售后进度，而不是让客人把聊天记录截图过来。预售、定金膨胀、换购、赠品缺货这些活动形态，状态机要比普通现货多几个节点，否则仓库会按普通单去拣不存在的货。发票、跨境税费、货到付款如果在范围内，要在下单时就算清，避免发货后财务再拦。
上线前必须用真实活动规则压一轮：高并发下单、重复支付、部分退款、优惠券超发。验收标准写的是这些路径，不是“商城功能清单打勾”。前端要快，但快建立在库存和订单状态正确之上。电商系统做成了，运营能自己配活动，仓库能按单一本账发货，财务能按日对上支付——这三件事同时成立，才叫能跑的线上生意。
自有商城承接复购和会员，平台订单同步进来统一发货和售后。
秒杀、拼团、预售各有占库规则，活动结束自动释放未付款订单。
支付、退款、分账在系统里留凭据，与平台流水按日对账。
活动一上量就超卖，库存扣减靠后台补救
下单即预占、超时释放，秒杀走独立库存池，扣减规则写进接口而不是靠人盯。
订单分散在几个平台，客服要开五个后台
订单统一汇总到一处处理，来源标记保留，售后和物流查询在同一界面完成。
退款和分账对不上，财务月底加班补账
支付流水与订单一一对应，退款按原路径留痕，分账规则可配置并生成对账文件。
SKU、规格、活动库存池与预占释放。
多来源订单、拆单合单、发货与签收。
多渠道支付、部分退款、分账留痕。
等级、积分、优惠券、拼团与秒杀。
退换货、补发、客诉跟踪。
日对账文件、转化与复购分析。
把渠道、活动类型、履约方式和售后路径列全，分清本阶段要打通的下单、支付、发货、退款范围。
定 SKU 库存状态机、优惠计算顺序和支付对账口径，确认仓储、快递、支付渠道的接口方式。
用真实活动和库存压测下单、重复支付、部分退款。超卖防护和对账差异清单作为验收项提前写好。
先小流量活动验证履约，再放开大促。运营配活动、仓库按单发货、财务按日对账，后续按渠道迭代。