开发前少想一步，上线后多改三版
做过电商项目的人都有体会：页面设计可以反复调，支付接口可以慢慢联调，但有些功能细节一旦在开发前没想清楚，等到上线后再补，代价往往是重构级的。轻则改数据库字段，重则推翻整个购物流程。
根据多个电商项目的复盘经验，以下五个功能细节最容易被忽略，但它们恰恰决定了用户是否愿意完成支付、客服是否会被重复问题淹没、运营能否高效管理商品。
一、库存扣减的“并发场景”不是技术题，是业务题
很多团队在开发前讨论库存，只想到“商品详情页显示库存数量”。但真正需要确认的是：库存扣减的时机和超卖处理规则。
常见问题
- 用户加入购物车时锁库存，还是提交订单时锁？
- 支付超时后，库存何时释放？
- 同一商品同时被100人下单，系统如何保证不超卖？
如果开发前不定义清楚，开发人员通常会按“最简单的方式”实现——也就是下单减库存。这会导致用户占用库存却不付款，热销商品被“锁死”，真正想买的人买不到。建议在需求文档中明确：采用“预扣库存+超时自动释放”机制，并设定合理的支付时限（如15分钟）。同时，要预留人工干预入口，方便运营在异常时手动调整库存。
二、商品规格的“组合属性”远比你想的复杂
“颜色+尺码”这种双规格是入门级。实际电商场景中，商品可能存在“颜色+尺码+材质”三维规格，甚至同一规格下不同SKU的价格、库存、图片都不同。
开发前最容易忽略的是：规格变更时，价格、库存、SKU编码、商品图片是否联动更新？ 例如，用户选择“红色”后，图片自动切换为红色款；选择“XL”后，库存显示该尺码剩余数量。如果开发前未定义规格与SKU的映射关系，前端交互会非常生硬，用户每次选择都要刷新页面。
建议在开发前绘制规格矩阵图，明确每个SKU的属性组合、独立库存和价格，并确认前端是否支持异步刷新。
三、售后流程的“状态机”必须提前画出来
很多电商项目在开发时，把售后简单做成“用户申请→商家同意→退款”。但真实场景中，售后状态至少包括：待审核、审核通过待退货、退货待收货、退款中、退款失败、拒绝售后、用户取消申请。
更复杂的情况是：部分退款、换货、补偿优惠券、仅退款不退货。如果开发前不定义好状态流转规则，开发人员会自行发挥，导致用户看到的售后进度与商家后台不一致，客服需要频繁手动修改订单状态。
建议在开发前用流程图画出所有可能的售后路径，并明确“哪些状态允许用户主动取消”“哪些状态需要商家手动操作”。这项工作看似琐碎，但能避免后期大量返工。
四、运费模板：不是“满99包邮”那么简单
运费计算是电商开发中隐藏的深水区。不同地区运费不同、按件数计费还是按重量计费、偏远地区加价、多商品合并结算时运费如何取最优——这些规则如果不提前定义，开发出来的运费模块只能应付“全场包邮”的简单场景。
尤其要注意多商品混合购物车的运费计算逻辑：是取最高运费，还是累加运费，还是按店铺合并？如果是平台型电商，还需要考虑多店铺订单拆分的运费归属。建议开发前整理一份运费规则表，覆盖至少3种典型场景：单商品多件、多商品不同运费模板、跨店铺结算。
五、订单列表的“筛选条件”决定客服工作量
后台订单管理界面的筛选功能，往往被当成“次要功能”延后开发。但运营和客服每天有大量时间消耗在查找订单上。如果筛选条件不够细，比如只能按订单号搜索，无法按“商品名称”“买家昵称”“支付时间范围”“订单状态”组合筛选，客服效率会非常低。
更关键的是订单导出功能。财务对账、物流批量发货、营销活动复盘都依赖导出数据。开发前要确认导出字段是否包含商品明细、优惠分摊、支付渠道流水号等。如果漏了这些，后期再增加导出字段，往往需要改动底层查询逻辑，成本不低。
总结：开发前的“功能清单”比UI设计更重要
以上五个细节，表面上看是技术实现问题，本质上都是业务规则的定义问题。建议在项目启动时，由运营、客服、财务、开发共同参与一次“功能细节评审会”，逐条确认：
- 库存扣减时机与超时规则
- SKU规格矩阵与联动展示
- 售后状态流转图
- 运费计算规则表
- 订单筛选字段与导出模板
这些内容不需要写进高深的架构文档，但必须写进产品需求说明中。电商开发最怕的不是技术难，而是“当初没人提这个需求，现在要加”。提前花半天时间把这些细节聊透，上线后能省下数周的修改时间。