Hyperf 在企业级支付系统中必须使用，因其协程非阻塞架构可应对每秒数百笔并发回调，避免传统 PHP-FPM 因同步阻塞导致的资金错账、重复扣款等严重问题。
Hyperf 在企业级支付系统中不是“能用”，而是必须用——单体 PHP-FPM 架构在支付回调、幂等校验、分布式锁、异步通知等环节根本扛不住每秒数百笔的并发冲刷，稍有延迟就会引发资金错账或重复扣款。
支付回调接口为什么必须用协程非阻塞？
传统 FPM 模式下，一个支付回调请求会独占一个 PHP 进程，而支付宝/微信回调常带重试（最多 5 次）、且需同步验签 + 查库 + 更新订单 + 发送 MQ + 调用风控服务。若某环节卡顿（如 Redis 网络抖动），整个进程就挂住，后续回调排队堆积，超时后第三方平台反复重发，形成雪崩。
-
handle()方法里不能调用sleep()、file_get_contents()或任何同步阻塞 I/O - 所有 DB 查询必须走 Hyperf 的协程 MySQL 客户端（
Hyperf\Database\Connection），而非 PDO 原生驱动 - 验签、解密等 CPU 密集操作建议用
Hyperf\Utils\Coroutine::create()卸载到独立协程，避免阻塞事件循环 - 回调入口务必加
@AutoController+@Middleware（用于快速拒绝非法来源 IP 或重复请求）
如何保证支付幂等性不靠数据库唯一索引硬扛？
仅靠 UNIQUE(order_no) 在高并发下会触发大量主键冲突异常，日志刷屏且无法区分是真重复还是网络重传。Hyperf 应该用「内存锁 + 数据库双校验」策略。
- 先用
Redis::set($key, $value, ['NX', 'EX' => 60])获取 60 秒业务锁，$key为"pay:callback:{$out_trade_no}" - 锁获取失败直接返回
200 OK（微信/支付宝要求必须成功响应，否则持续重推） - 拿到锁后，再查数据库确认该订单是否已处理完成；若已存在，跳过执行，仅记录日志
- 释放锁必须用 Lua 脚本原子执行：
EVAL "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end" 1 pay:callback:xxx xxx_uuid
异步通知和结果落库为什么不能放同一个队列？
支付成功后要做的事太多：更新订单状态、扣减库存、发 Kafka 通知、触发营销活动、写审计日志……如果全塞进一个 order_pay_success 队列，某个下游服务（比如短信网关）抖动，整个队列就卡死，导致资金状态长期滞留“支付中”。
- 按 SLA 分离队列：
pay_status_sync（强一致，DB 更新 + 分布式锁）→pay_notify（最终一致，MQ/Kafka）→pay_audit（低优先级，归档用） - 每个队列配置不同
concurrent.limit：状态同步设为 20，通知设为 50，审计设为 5 - 失败任务不要无脑重试，
max_attempts设为 3，第 3 次失败后投递到failed:pay_notify专用死信队列，由人工干预或定时补偿 - 避免在 Job 里 new Service 实例，全部通过
@Inject注入，确保容器管理的生命周期和连接池复用
分布式锁选 Redis 还是 ZooKeeper？
支付核心链路（如订单创建、余额扣减）必须用 ZooKeeper，Redis 锁在主从切换瞬间可能丢失锁，造成资金超付——这不是理论风险，是真实发生过的生产事故。
- Redis 锁只用于非资金类场景：缓存预热、限流计数、日志去重
- ZooKeeper 锁路径必须带业务标识，例如
/locks/payment/order_create/{order_id}，避免跨业务争抢 - ZK 客户端初始化耗时较高，务必在
Process或Command中提前建立连接，不要每次请求都 new - Hyperf 的
Hyperf\ZooKeeper\ZooKeeper默认使用 session timeout 30s，生产环境建议调大到 60s，防止网络抖动误失连接
真正难的不是写通支付流程，而是让每一笔钱在 100ms 内完成「验签 → 锁定 → 落库 → 通知」闭环，且不出错。Hyperf 提供了协程、连接池、分布式组件这些砖，但怎么砌成防资金泄漏的墙，得靠对每处超时、每个重试、每次锁释放的死磕。
