技术选型：自研、开源还是SaaS，先算清楚这笔账
很多业务方在项目启动时，习惯性认为“先做出来再说”，但电商系统的技术底座一旦定错，后期迁移成本极高。建议在需求评审前，先明确平台模式：是纯前端展示+第三方支付跳转，还是需要完整的库存、会员、促销引擎？
如果是标准零售场景，成熟的开源系统（如基于PHP或Java的电商框架）配合定制开发，性价比通常优于完全自研。但若涉及复杂的B2B阶梯价、多供应商分账或跨境税率计算，自研或深度定制反而能减少长期维护的隐性成本。业务方需要和研发负责人一起，把未来3年的订单量预估、并发峰值、商品SKU规模写成量化指标，而不是只说“我们流量很大”。
支付与结算：不只是“接入微信和支付宝”这么简单
支付环节最容易出现“验收时才发现逻辑对不上”的问题。业务方需要确认的不只是支付渠道列表，还包括：
- 退款原路返回的时效：用户发起退款后，银行处理周期是T+1还是T+0？系统是否需要支持部分退款、多次退款？
- 对账文件格式：财务系统能否自动解析支付宝/微信的结算账单？还是需要人工导出再处理？
- 分账与代发：如果是平台型电商，涉及商户结算，需要确认资金是“先到平台再分账”还是“直接分账到商户”，这直接影响税务和合规方案。
建议在开发前，让财务负责人和研发一起走一遍“用户下单→支付→发货→确认收货→结算”的完整资金流，把异常场景（如支付成功但库存扣减失败）的补偿机制写进需求文档。
库存管理：超卖不是技术问题，是业务规则问题
很多业务方默认“库存减一”是理所当然的，但电商场景下至少有三种库存模型：下单减库存、支付减库存、发货减库存。每种模型对用户体验和运营策略的影响完全不同。
例如，秒杀活动通常采用“预占库存”模式，但若用户15分钟内未支付，库存是否自动释放？释放后是否通知排队用户？多仓发货时，库存是共享还是独立？这些细节如果不提前定，开发过程中会频繁返工。更关键的是，需要明确“超卖”的容忍度——是严格不允许超卖，还是允许1%-2%的容错由客服人工处理？这决定了技术方案的复杂度。
商品规格与SKU设计：隐藏的“数据炸弹”
看似简单的“颜色+尺码”规格，在数据库层面可能意味着SKU数量爆炸式增长。业务方需要想清楚：商品是否支持多级规格（如服装的“颜色-尺码-版型”）？是否支持自定义规格项（如定制刻字）？规格变更时，历史订单的快照如何保存？
一个常见的坑是：运营在后台手动添加了300个SKU，但未考虑每个SKU的独立图片、条码和重量。导致后期物流对接时，快递单无法自动打印。建议在需求阶段，就要求运营整理一份“典型商品”的完整数据样例，涵盖单规格、多规格、无规格三种类型。
营销活动与优惠计算：优先级比折扣力度更重要
满减、优惠券、会员价、限时秒杀……这些功能单独看都不复杂，但叠加起来时，计算顺序稍有差错就会导致资损。业务方必须确认：
- 优惠券是否与满减叠加？叠加时先算满减还是先算券？
- 秒杀价商品是否参与店铺级满赠？
- 分摊规则：整单优惠如何按比例分摊到每个商品上，以便后续退款时按比例退回？
建议在开发前，由运营写出至少10个“组合优惠”的测试用例（例如：满300减50 + 店铺券20 + 会员95折），并让研发确认计算引擎是否支持规则可配置，而不是写死在代码里。
物流与履约：接口联调比想象中更耗时
电商系统不是孤岛，需要与快递鸟、菜鸟、顺丰等物流平台对接。业务方需要提前确认：电子面单是否需要对接？是否支持多物流商切换？物流轨迹是主动推送还是轮询拉取？
特别要注意的是“拆单发货”场景：一个订单包含不同仓库的商品，是拆成多个包裹，还是合并后由总仓代发？这直接影响前端展示的物流单号和用户通知逻辑。另外，若涉及同城配送或自提点，还需要考虑超时未取件的逆向流程。
数据埋点与权限设计：等上线后再补就晚了
很多业务方在开发时忽略后台权限管理，直到员工离职或出现数据泄露才补救。需在开发前确认：
- 客服能否查看用户手机号？能否导出订单明细？
- 运营人员的操作日志是否需要留存？敏感操作（改价、退款）是否需要二次审批？
- 数据看板需要实时还是T+1？是否需要按渠道、地区、SKU维度钻取？
如果未来有分销或代理商体系，还需要提前设计角色隔离，避免不同层级看到相同价格体系。
总结：把“技术细节”当业务决策来做
以上7个细节，表面上是技术问题，实质是业务规则和风险偏好的选择。建议业务方在项目启动前，组织一次“技术+运营+财务”三方对齐会议，用一整天时间逐项过清单。哪怕暂时无法给出最终答案，也要明确“由谁在什么时间点前确认”。电商开发最怕的不是需求变更，而是变更发生在系统上线后——那时每一行代码的修改，都可能牵动支付、库存、对账的连锁反应。