需求遗漏一：商品规格与库存逻辑的“隐藏分支”
大多数电商项目在需求阶段都会讨论“规格（SKU）”，但讨论往往停留在“颜色、尺码”这类基础维度。真正容易遗漏的是规格组合下的库存扣减逻辑，以及预售、补货、锁定库存等边界状态。
例如，一个服装商家可能有“单独购买上衣”和“上衣+裤子组合套餐”两种销售方式。若未提前定义“组合套餐扣减的是哪个仓库的库存”“用户下单未付款时是否锁定库存”，开发完成后极易出现超卖或库存显示不一致的问题。
建议做法：在需求文档中，至少明确以下三点：
- 库存扣减时机：是“提交订单”时扣，还是“支付成功”时扣？
- 多仓库逻辑：是否按区域分仓？是否支持“拆单发货”？
- 异常处理：库存不足时，是允许下单后取消，还是直接禁止购买？
这三点若不确认，后期返工成本极高，且直接影响用户体验。
需求遗漏二：营销活动的“叠加规则”与“逆向流程”
“满减”“优惠券”“会员折扣”是常见需求，但开发前最容易被忽略的是优惠叠加规则和退款时的优惠分摊。
举例：用户使用“满300减50”的店铺券，同时享受“会员95折”，那么是先减50再打95折，还是先打95折再减50？如果用户申请部分退款（比如只退其中一件商品），优惠金额如何从退款中扣除？
很多项目上线后出现“退款金额大于实付金额”的漏洞，正是因为需求阶段没有定义清楚优惠分摊优先级。
建议做法：在需求评审时，用一张表格列出所有促销类型（满减、秒杀、拼团、优惠券、积分抵扣），并明确：
- 哪些可以叠加，哪些互斥？
- 计算顺序是什么（先单品级、再订单级）？
- 退款时，按比例分摊还是按固定金额退回？
需求遗漏三：售后流程中的“状态机”设计
售后不只是“申请退款”一个按钮。真正复杂的在于售后状态流转：用户申请退货→商家审核→用户寄回→商家收货→质检→退款。每一步都可能出现超时、拒绝、修改申请等分支。
不少团队在开发前只写了“用户可申请退款”，却遗漏了以下细节：
- 用户申请后，商家多久不处理是否自动同意？
- 退货物流单号填写后，系统如何追踪“签收”事件？
- 换货场景下，新订单如何生成？是否占用原订单的库存？
- 退款是原路退回，还是退到账户余额？手续费谁承担？
这些状态若不在开发前画成状态流程图，开发中就会出现“用户点击退货无反应”或“商家无法关闭售后单”等低级Bug。
需求遗漏四：非功能需求——并发与数据一致性
很多业务方只关注“功能能跑通”，但忽略了高并发下的表现。比如秒杀场景，或某款爆品短时间内被大量下单，系统能否保证库存不超卖？
这属于非功能需求，但必须在开发前确认：
- 预计峰值并发是多少？是否需要引入队列或缓存？
- 订单号生成策略是否全局唯一？是否支持分库分表？
- 敏感操作（如支付回调）是否做了幂等处理？
如果等到上线后才发现数据库锁表或订单号重复，再改架构就非常痛苦。建议在需求文档中单独列出“性能指标”章节，哪怕只是“预估日单量1万，峰值QPS 100”这样的粗略数字，也能帮助技术团队提前设计。
需求遗漏五：后台管理的“权限粒度”与“操作日志”
前台用户看到的只是商品和订单，但后台管理系统才是运营每天使用的工具。最容易被遗漏的是权限控制和操作留痕。
例如：运营人员可以修改商品价格，但“修改前价格”和“修改后价格”是否记录？客服能否直接修改用户订单金额，还是需要主管审批？供应商（如果有B2B功能）能否看到所有订单，还是只能看到自己供货的订单？
建议做法：在需求阶段，按角色（管理员、运营、客服、财务、供应商）列出权限矩阵，并明确关键操作（改价、退款、删除商品）是否需要二次验证或日志留存。这不仅是管理规范，也是日后排查问题的重要依据。
总结：需求确认不是“过流程”，而是“找死角”
以上五个遗漏点，本质上是业务规则边界和系统状态流转的问题。电商系统看似简单，实则由大量“异常分支”构成。建议在开发前组织一次“找茬会议”，让运营、客服、财务、技术一起，针对每个流程提问：“如果用户这样做，系统该怎么反应？”
提前花一天时间讨论这些边界情况，远比上线后花一周修复漏洞更高效。如果您的项目正处于需求阶段，不妨对照本文清单逐项自查，把遗漏点补上，再进入开发不迟。