商城类的项目我们做过不少，最典型的一种返工是：功能都开发完了，上线前测试时发现库存会超卖、退款金额算不对、售后申请提交后订单状态卡住。追下去，问题都出在方案阶段——商品、订单、支付、售后这四块只画了界面，没有画数据怎么流。
这篇按我们实际项目的顺序，说清楚这四块在方案阶段该定到什么颗粒度。
商品的难点在规格。一件 T 恤有颜色和尺码，一个手机只有颜色，一个生鲜商品可能按重量分档。如果按「一个商品一条库存记录」来设计，多规格商品就会出问题。
正确的拆法是三层：SPU（商品）、SKU（规格组合）、库存（按 SKU 存）。下单扣减的是 SKU 库存，展示在列表页的是 SPU 的价格区间。很多团队一开始把价格和库存都放在商品表上，做到第二个品类就推倒重来。
库存扣减的时机也要定。行业通用做法是下单时预占、支付时扣减、超时未支付释放。预占和释放要有定时任务兜底，不然用户拍下不付款，库存一直挂在那。
订单不是一个「状态」字段能解决的，它是一套状态流转。待支付、已支付待发货、已发货、已签收、已完成、已取消、退款中、退款完成，每个状态谁能操作、下一步能去哪，都要在方案里画成图。
有个细节经常被漏掉：拆单。一个订单里有三个商家的商品，或者有现货和预售混合，发货时必然会拆成多个包裹。订单主表和发货子表要分开，物流单号挂在子表上，不然一个订单只能填一个快递单号，用户看到的就是错的。
另一个是订单快照。商品价格、规格、优惠都要在下单那一刻存一份快照，后面商家改价、改规格，历史订单不能跟着变。
支付对接本身是标准动作，微信支付、支付宝都有成熟接口。真正需要设计的是三件事：
一是支付回调的幂等。微信可能重复回调，接口必须用订单号加交易号做唯一约束，重复回调直接返回成功，不能重复加钱。
二是退款。原路退回是最基本的要求，部分退款、多次退款、运费不退这些规则要在方案里写清。有分销或平台分账的，退款还要能反向扣回分账金额，这个复杂度经常在项目后期才被发现。
三是对账。每天定时拉取支付平台的账单，与系统订单逐笔比对，差异单独出一张表。没有对账，出了资金问题只能人工翻流水。
正向流程是下单付款发货，逆向流程是退货、换货、退款、部分退。逆向流程的难点在于状态多、责任方多、金额算法多。
常见的售后方案包含这几步：用户提交申请（选原因、上传凭证）→ 商家审核（同意/拒绝/协商）→ 用户寄回（填物流单号）→ 商家收货确认 → 退款或换货发出。每一步都要有超时自动流转的规则，比如商家 48 小时不处理，系统自动同意。
金额算法是最容易出纠纷的地方：优惠券怎么摊、满减怎么摊、运费谁承担。行业做法是按商品实付金额比例分摊优惠，运费单独处理。这套规则要在方案里写成公式，开发照着实现，测试照着验。
日订单几百单、SKU 几千个的规模，用成熟的开源商城框架（比如 CRMEB、Mall4j 这类）二次开发最划算，五到十五万，八到十二周。
有多商户、分销、直播带货、多门店自提的，建议自研核心模块或者基于框架深度定制，二十万到六十万，工期三到五个月。
如果只是试水，先上 SaaS 模板商城，一年几千到几万，把品类和流量跑通再考虑自建，能省掉大量试错成本。
压测下单和支付接口，模拟大促并发；跑一遍超卖测试，用脚本同时下单最后一件商品；走一遍完整退款，含部分退和多次退；检查所有金额字段有没有用浮点数（必须用整数分或定点小数）；最后，把售后和客服的话术与系统状态对齐，别让客服看到的状态和用户看到的不一样。
博纳网络在深圳做商城系统与电商平台开发 13 年，从商品结构到售后逆向流程都按项目规范落地。需要评估商城方案或做现有系统改造，电话 0755-82538016 / 13828753662（微信同号）。
[声明]本网转载网络媒体稿件是为了传播更多的信息，此类稿件不代表本网观点，本网不承担此类稿件侵权行为的连带责任。故此，如果您发现本网站的内容侵犯了您的版权，请您的相关内容发至此邮箱【qin@198bona.com 】，我们在确认后，会立即删除，保证您的版权。