不吃章鱼烧1. 电商系统全景图：为什么需要理解业务实体与生命周期？
干了十年电商系统开发，我见过太多团队在需求评审会上鸡同鸭讲的场景。产品经理说"这个促销模块要支持阶梯满减"，技术负责人问"用户优惠券核销的幂等性怎么保证"，而运营同事更关心"预售商品的库存到底算不算在总库存里"。这种沟通断层往往源于各方对电商业务实体及其生命周期的理解不一致。
电商系统本质上是由数十个核心业务实体及其交互关系构成的复杂网络。就像搭积木，如果连基础模块的形状和接口都不清楚，怎么可能构建出稳固的系统？以我参与过的某跨境电商平台重构为例，前期由于对"订单"实体在不同状态下的库存占用规则定义模糊，导致大促期间出现了超卖和库存死锁，直接损失了300多万的GMV。
理解业务实体和生命周期不是画几个UML图那么简单，而是要掌握每个模块从生到死的完整轨迹。比如一个简单的"商品"实体，就涉及创建草稿、审核上架、销售中、违规下架、手动下架、自动售罄等十多个状态变迁，每个状态变更都会触发库存、价格、营销等关联系统的连锁反应。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 商品中心：电商的基石如何运作？
2.1 商品实体的DNA解析
商品模块远不止是前端展示的那张图片和价格标签。在技术实现层面，一个完整的SPU（Standard Product Unit）包含以下核心属性组：
- 基础信息：类目、品牌、规格参数（如手机的内存/颜色）
- 销售属性：计价单位（件/套/箱）、是否支持无理由退货
- 物流属性：重量体积、禁运地区、温层要求
- 财务属性：成本价、税率编码、结算周期
- 扩展属性：3D展示参数、AR试穿锚点
特别提醒：商品类目体系的设计直接影响后续所有业务逻辑。某母婴电商曾因将"奶瓶消毒器"错误归类到小家电而非母婴用品，导致无法参与跨品类满减活动。
2.2 商品生命周期的状态机设计
下图是经过多个项目验证的商品状态流转模型：
mermaid复制stateDiagram-v2
[*] --> 草稿
草稿 --> 待审核: 提交
待审核 --> 已驳回: 审核不通过
已驳回 --> 待审核: 重新提交
待审核 --> 已上架: 审核通过
已上架 --> 已下架: 手动下架/自动售罄
已下架 --> 已上架: 重新上架
已上架 --> 违规下架: 风控触发
违规下架 --> 已删除: 申诉失败
关键状态处理逻辑：
- 上架状态需要同步更新ES索引和CDN缓存
- 违规下架需触发用户补偿流程
- 删除操作必须确保没有关联订单才能执行
3. 库存管理：如何避免超卖与死锁？
3.1 库存实体的多层次建模
电商库存不是简单的"总数-已售=剩余"算术题。成熟的库存系统需要区分：
- 总库存（逻辑库存）：供应商承诺的可售总量
- 可用库存：总库存 - 预占库存 - 锁定库存
- 预占库存：已下单未支付的库存（15-30分钟TTL）
- 锁定库存：活动预留、售后换货预留等特殊库存
某3C电商的惨痛教训：没有区分"预售库存"和"现货库存"，导致双11期间2000多笔预售订单无法按时发货，平台被迫赔付20%的违约金。