--- 一、从0开始的完整流程时间顺序0立项先定“能赚钱的最小闭环” 先别谈技术先定这4件事1. 卖什么实物/虚拟2. 卖给谁B2C/B2B3. 怎么收钱微信/支付宝/银行卡4. 第一版必须上线哪些功能MVP MVP最小闭环 - 注册登录 - 商品列表/详情 - 购物车 - 下单 - 支付 - 我的订单 - 后台商品和订单管理 常见疑难杂症 - 病症一开始要“全功能平台” 后果半年还没上线 解法第一版只做交易闭环营销玩法后置 ---1需求阶段把“想法”变成“可开发规格” 输出这3份东西1. 用户流程图浏览-加购-下单-支付-发货-售后2. 业务规则表库存、优惠、退款、超时规则3. 用例清单正常流程 异常流程 常见疑难杂症 - 病症需求写“支持优惠券”没写叠加规则 后果开发、测试、运营理解全不一样 解法把规则写成“可判定语句”可叠加/不可叠加/优先级 - 病症不定义“支付超时多久取消” 后果库存长期锁死 解法明确超时策略比如30分钟自动关单并解锁库存 ---2架构设计系统蓝图先画清2.1模块拆分 - 用户中心 - 商品中心SPU/SKU - 库存中心 - 交易中心订单 - 支付中心 - 履约中心发货物流 - 售后中心 - 运营后台2.2技术栈PHP常见 - PHP8.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 - refunds3.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. 权限越权 -服务端强校验 RBAC13. 活动期间崩溃 -预热、压测、熔断降级预案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%的大坑都能提前避开。