---                                                                                                                     一、从0开始的完整流程（时间顺序）
                                                                                                                          0）立项：先定“能赚钱的最小闭环”

  先别谈技术，先定这4件事：

  1. 卖什么（实物/虚拟）
  2. 卖给谁（B2C/B2B）
  3. 怎么收钱（微信/支付宝/银行卡）
  4. 第一版必须上线哪些功能（MVP）

  MVP最小闭环：
  - 注册登录
  - 商品列表/详情
  - 购物车
  - 下单
  - 支付
  - 我的订单
  - 后台商品和订单管理

  常见疑难杂症

  - 病症：一开始要“全功能平台”
  后果：半年还没上线
  解法：第一版只做交易闭环，营销玩法后置

  ---
  1）需求阶段：把“想法”变成“可开发规格”

  输出这3份东西：

  1. 用户流程图（浏览->加购->下单->支付->发货->售后）
  2. 业务规则表（库存、优惠、退款、超时规则）
  3. 用例清单（正常流程 + 异常流程）

  常见疑难杂症

  - 病症：需求写“支持优惠券”，没写叠加规则
  后果：开发、测试、运营理解全不一样
  解法：把规则写成“可判定语句”（可叠加/不可叠加/优先级）
  - 病症：不定义“支付超时多久取消”
  后果：库存长期锁死
  解法：明确超时策略（比如30分钟自动关单并解锁库存）

  ---
  2）架构设计：系统蓝图先画清

  2.1 模块拆分

  - 用户中心
  - 商品中心（SPU/SKU）
  - 库存中心
  - 交易中心（订单）
  - 支付中心
  - 履约中心（发货物流）
  - 售后中心
  - 运营后台

  2.2 技术栈（PHP常见）

  - PHP 8.2 + Laravel/Symfony
  - MySQL
  - Redis
  - RabbitMQ/Kafka（异步）
  - Elasticsearch（复杂搜索）
  - Nginx + Docker + CI/CD

  常见疑难杂症

  - 病症：小团队一开始就微服务十几个
  后果：排障成本爆炸
  解法：先模块化单体，流量上来再拆核心域

  ---
  3）数据设计：电商最容易翻车的地方

  3.1 核心表

  - users, user_addresses
  - products, product_skus
  - carts, cart_items
  - orders, order_items
  - payments
  - shipments
  - refunds

  3.2 关键规则

  - 金额用整数“分”（BIGINT）
  - 订单号/支付单号唯一索引
  - 状态字段用枚举，不要随便字符串
  - 核心查询字段加索引（user_id/status/created_at）

  常见疑难杂症

  - 病症：金额用float
  后果：对账永远对不齐
  解法：全链路金额用分，统一四舍五入规则
  - 病症：索引乱建
  后果：写入慢、查询也慢
  解法：按真实查询场景建组合索引，用慢SQL日志反推优化

  ---
  4）核心链路开发（交易闭环）

  4.1 下单流程（标准）

  1. 校验用户/地址
  2. 校验商品可售
  3. 后端重算价格
  4. 锁库存
  5. 创建订单+订单项
  6. 创建支付单
  7. 返回支付参数

  4.2 支付回调（最关键）

  1. 验签
  2. 幂等校验（重复回调只处理一次）
  3. 金额校验
  4. 更新支付状态
  5. 推进订单状态
  6. 投递后续任务（发货、通知）

  4.3 取消与回补

  - 超时未支付 -> 自动关单 -> 解锁库存
  - 退款成功 -> 回补库存（按业务规则）

  常见疑难杂症

  - 病症：前端传多少钱就按多少钱扣
  后果：改包篡改金额
  解法：后端重算，前端金额只展示
  - 病症：支付回调非幂等
  后果：重复扣库存、重复发货
  解法：唯一约束 + 状态机防重 + 幂等键

  ---
  5）并发与性能：大促才不会炸

  5.1 必做

  - Redis缓存商品详情/类目
  - 热点Key防击穿（互斥更新）
  - 过期时间加随机值（防雪崩）
  - 消息队列削峰
  - 限流熔断降级

  5.2 秒杀场景（高并发）

  - Redis预扣库存（Lua原子）
  - 先拿资格后落库
  - 异步下单
  - 失败补偿任务兜底

  常见疑难杂症

  - 病症：库存只在DB扣减
  后果：行锁冲突、DB打满
  解法：前置缓存扣减 + 异步落库 + 最终一致性校验
  - 病症：缓存和DB不一致
  后果：页面显示有货但下单失败
  解法：统一更新策略（先改DB再删缓存 or 订阅变更事件刷新）

  ---
  6）安全：电商是高攻击面系统

  6.1 基础安全

  - SQL预编译防注入
  - XSS输出转义
  - CSRF token
  - 密码argon2/bcrypt
  - 上传文件白名单+大小+MIME校验

  6.2 交易安全

  - 支付验签
  - 关键操作二次验证
  - 防刷限频（登录/领券/下单）
  - 后台RBAC权限与审计日志

  常见疑难杂症

  - 病症：后台“管理员共用一个账号”
  后果：出事无法追责
  解法：一人一账号、全操作审计

  ---
  7）测试：不是“点通页面”就算完

  必测清单

  - 并发抢最后1件
  - 重复点击下单
  - 回调延迟/重复/乱序
  - 优惠叠加边界
  - 部分退款/全额退款
  - 订单取消与支付成功同时发生

  常见疑难杂症

  - 病症：只测正常流程
  后果：线上全是边界bug
  解法：测试用例里异常场景占至少50%

  ---
  8）上线与灰度：最容易“临门一脚翻车”

  上线前硬检查

  - DB脚本可回滚
  - 配置分环境
  - 支付/短信生产密钥确认
  - 监控告警全开
  - 值班与应急预案到人

  灰度

  - 5% -> 20% -> 50% -> 100%
  - 盯：下单成功率、支付成功率、错误率、慢SQL、队列积压

  常见疑难杂症

  - 病症：全量直上
  后果：故障影响全部用户
  解法：必须灰度，异常立即回滚

  ---
  9）运营期：真正的长期战场

  每天必看

  - GMV、转化率、客单价
  - 下单/支付成功率
  - 退款率、取消率
  - 库存异常数
  - 服务错误率

  常见疑难杂症

  - 病症：只看业务，不看技术健康
  后果：技术债积累到某次大促爆炸
  解法：每期固定比例工时还技术债（比如20%）

  ---
  二、你要的“全部疑难杂症”总表（高频故障 -> 对应解法）

  1. 超卖 -> 锁库存 + 并发控制 + 幂等
  2. 重复下单 -> 幂等token + 防重提交
  3. 支付成功但订单未更新 -> 回调重试 + 补偿任务
  4. 库存负数 -> 原子扣减 + 异常扫描修复
  5. 优惠算错 -> 统一价格引擎 + 快照落单
  6. 慢SQL暴增 -> 索引优化 + 读写分离 + 分页优化
  7. 缓存雪崩 -> 过期错峰 + 多级缓存
  8. 消息积压 -> 扩consumer + 死信队列 + 限流
  9. 对账不平 -> 日对账任务 + 差异工单
  10. 发货状态乱 -> 物流状态机 + 回调去重
  11. 退款卡死 -> 退款状态机 + 超时补偿
  12. 权限越权 -> 服务端强校验 + RBAC
  13. 活动期间崩溃 -> 预热、压测、熔断降级预案
  14. 日志看不懂 -> 全链路trace_id统一
  15. 线上修复慢 -> 标准化应急手册 + 演练机制

  ---
  三、从0到上线的最小执行路线（可直接照做）

  1. 锁定MVP边界（3天）
  2. 完成需求规则表+流程图（5天）
  3. 完成架构图+ER图+API定义（5天）
  4. 开发核心闭环（4-6周）
  5. 联调+测试+压测（2-3周）
  6. 灰度上线（3-7天）
  7. 监控运营+迭代（持续）

  ---
  最核心一句：
  电商项目不是“功能堆出来”，而是“钱、单、库存”三件事永远一致，再把稳定性做出来。
  只要你把交易正确性、幂等、状态机、补偿机制这四块打牢，90%的大坑都能提前避开。