Scenario 23: Payment System 支付系统
V1 — 1人用：纯前端模拟支付
Section titled “V1 — 1人用：纯前端模拟支付”你想理解支付流程的基本交互，做一个模拟支付Demo。
你要解决什么
Section titled “你要解决什么”- 支付表单页面（卡号、有效期、CVV）
- 支付状态流转动画（输入→处理中→成功/失败）
- localStorage记录支付历史
- 基本的卡号格式校验
给AI的Prompt
Section titled “给AI的Prompt”用HTML+CSS+JS做一个模拟支付页面。包含：1)订单信息展示（商品名、金额） 2)支付表单（卡号自动加空格格式化、有效期MM/YY格式、CVV 3位） 3)点击支付后显示loading动画（3秒），随机80%成功20%失败 4)成功页展示订单号和支付时间，失败页提供重试按钮。 支付历史存localStorage，历史页面展示所有支付记录（时间、金额、状态）。 Luhn算法校验卡号格式。
- 卡号自动格式化（4位加空格）
- Luhn算法校验卡号
- 支付状态流转动画流畅
- 支付历史正确记录和展示
你学到了什么
Section titled “你学到了什么”- 表单格式化与校验 → Module: 表单处理
- 状态机UI展示 → Module: 交互设计
- Luhn算法 → Module: 数据校验
V2 — 10人用：订单+支付记录
Section titled “V2 — 10人用：订单+支付记录”需要真实的订单和支付记录管理，模拟支付网关回调。
你要解决什么
Section titled “你要解决什么”- 订单表+支付记录表
- 支付流程：创建支付单→模拟网关→回调确认
- 支付状态机（pending→processing→success/failed）
- 简单的对账功能
给AI的Prompt
Section titled “给AI的Prompt”Go+Gin后端，SQLite。订单表（id, amount, status, created_at）， 支付表（id, order_id, amount, method, status, gateway_txn_id, created_at）。 支付流程：POST /api/pay 创建支付单(pending)，模拟调用支付网关 （内部goroutine延迟3秒后回调），POST /api/callback 处理网关回调 （验签+更新状态）。网关回调带签名（HMAC-SHA256），后端验签。 支付状态查询API（前端轮询）。简单对账：比对支付表和模拟网关记录，列出差异。
- 支付单正确创建，状态为pending
- 模拟回调后状态更新为success
- 签名验证拒绝伪造回调
- 对账能发现不一致记录
你学到了什么
Section titled “你学到了什么”- 支付状态机 → Module: 状态机设计
- Webhook回调处理 → Module: 异步通信
- HMAC签名验证 → Module: 安全认证
V3 — 100人用：真实支付集成+幂等
Section titled “V3 — 100人用：真实支付集成+幂等”接入真实支付渠道，必须保证不重复扣款。
你要解决什么
Section titled “你要解决什么”- Stripe/支付宝沙箱环境集成
- Webhook可靠处理（重试+幂等）
- 支付幂等性（同一订单不重复扣款）
- 掉单处理（主动查询补偿）
给AI的Prompt
Section titled “给AI的Prompt”集成Stripe（沙箱模式）。创建PaymentIntent时带idempotency_key（用order_id）， 防止重复创建。Webhook处理：验证Stripe签名，payment_intent.succeeded事件 更新订单状态。幂等处理：Webhook可能重复投递，用payment_intent_id做幂等键， 重复事件直接返回200。PostgreSQL存储，支付记录加唯一索引（gateway_txn_id）。 掉单补偿：定时任务每5分钟扫描pending超过10分钟的支付单， 主动调用Stripe API查询状态，更新本地记录。
- Stripe沙箱支付成功走通
- 重复Webhook不重复处理
- 同一订单重复支付请求不重复扣款
- 掉单5分钟内被补偿任务修复
你学到了什么
Section titled “你学到了什么”- 支付网关集成 → Module: Stripe API
- 幂等性设计模式 → Module: 分布式系统
- 补偿机制 → Module: 最终一致性
V4 — 1000人用：退款+对账系统
Section titled “V4 — 1000人用：退款+对账系统”需要完善的退款流程和每日对账保证资金安全。
你要解决什么
Section titled “你要解决什么”- 退款流程（申请→审核→执行→确认）
- 每日对账Job（本地 vs 网关）
- 异常订单告警
- 资金流水记录
给AI的Prompt
Section titled “给AI的Prompt”退款流程：用户申请退款（POST /api/refund, 带reason），管理员审核通过后 调用Stripe Refund API，Webhook确认退款成功后更新状态。部分退款支持。 退款状态：requested→approved→processing→refunded/failed。 每日对账：凌晨2点Job拉取Stripe前一天的所有交易，与本地支付记录逐条比对。 差异类型：本地有网关无（掉单）、网关有本地无（漏记录）、金额不一致。 差异记录存表，金额差异>0自动告警（发邮件）。 资金流水表：每笔资金变动（收入/退款/手续费）记录，余额可追溯。
- 退款流程完整，部分退款金额正确
- 对账Job正确发现差异
- 金额差异触发告警
- 资金流水余额与实际一致
你学到了什么
Section titled “你学到了什么”- 退款流程设计 → Module: 支付逆向流
- 对账系统 → Module: 资金安全
- 资金流水 → Module: 账务系统
V5 — 1万人用：多渠道+熔断降级
Section titled “V5 — 1万人用：多渠道+熔断降级”单一支付渠道不够可靠，需要多渠道路由和容错。
你要解决什么
Section titled “你要解决什么”- 多支付渠道（银行卡/微信/支付宝）
- 智能路由（成功率、成本、用户偏好）
- 渠道熔断降级（失败率高自动切换）
- 支付渠道监控Dashboard
给AI的Prompt
Section titled “给AI的Prompt”支付网关抽象层：统一的PaymentGateway接口（CreatePayment, QueryPayment, Refund）， 实现Stripe、模拟微信、模拟支付宝三个适配器。 支付路由：根据规则选择渠道——用户选择>历史偏好>成功率最高>成本最低。 熔断器：统计每个渠道最近100次请求的失败率，>30%触发熔断（10分钟内不发请求）， 10分钟后半开状态放10%流量试探，成功率恢复则关闭熔断。 降级策略：主渠道熔断后自动切换备选渠道。 Dashboard：各渠道实时成功率、响应时间P99、熔断状态。
- 三个渠道都能正常支付
- 路由策略按优先级选择渠道
- 熔断器正确触发和恢复
- 降级自动切换到备选渠道
你学到了什么
Section titled “你学到了什么”- 策略模式+适配器模式 → Module: 设计模式
- 熔断器模式 → Module: 容错设计
- 支付路由 → Module: 支付架构
V6 — 10万+用户：资金账户+风控引擎
Section titled “V6 — 10万+用户：资金账户+风控引擎”平台需要内部账户体系、分账和实时风控。
你要解决什么
Section titled “你要解决什么”- 内部账户体系（用户余额、商户余额、平台账户）
- 余额充值/消费/提现
- 分账系统（订单金额按规则分给多方）
- 实时风控引擎
给AI的Prompt
Section titled “给AI的Prompt”账户系统：每个用户/商户有内部账户（id, owner_type, owner_id, balance, frozen_balance）。 转账用双记账法：每笔交易生成两条记录（借方、贷方），保证总额不变。 充值：外部支付→增加余额。消费：余额支付（先冻结→确认扣除/释放）。提现：T+1到银行卡。 分账：订单支付后按规则分账（平台5%手续费→平台账户，商户95%→商户账户）， 分账记录可追溯。风控引擎：实时规则（单日累计>5万需二次验证、 异地登录支付需短信验证、频率异常(1分钟>5次)拦截），风控结果：通过/拦截/人工审核。 风控日志全量记录，可回溯分析。
- 双记账法借贷平衡
- 余额冻结→扣除/释放流程正确
- 分账金额精确到分，无精度丢失
- 风控规则实时拦截异常交易
- 所有资金变动可审计追溯
你学到了什么
Section titled “你学到了什么”- 复式记账 → Module: 账务系统设计
- 余额系统 → Module: 资金账户
- 风控引擎 → Module: 实时风控