workerman仅作实时通信管道，支付对账与语音播报需拆解为支付回调、业务逻辑、终端触发三环节；回调须用独立http接口，推送需绑定商户uid，语音优先走硬件音响，对账依赖t+1异步比对与差异告警。
Workerman 本身不处理支付对账或语音播报，它只负责「实时通信管道」。真正实现支付成功后实时对账 + 商户端语音播报，必须拆解为三个独立但协同的环节：支付网关回调、服务端业务逻辑（含对账校验）、以及终端播报触发。直接把语音逻辑塞进 Workerman 进程里，90% 的情况会卡死或漏播。
支付回调必须走独立 HTTP 接口，不能走 WebSocket
微信/支付宝的支付结果通知是单向、不可重连的 HTTP POST 请求，强制要求 5 秒内返回 200。如果你把回调入口写在 Workerman 的 WebSocket 服务里（比如监听 onMessage），根本收不到——因为支付平台不会主动连你的 WebSocket。
实操建议：
- 用 ThinkPHP 原生控制器（如
app\controller\PayNotify.php）暴露一个普通 HTTP 接口，路径类似/api/v1/pay/callback - 该接口收到回调后，立刻验签、查订单、更新数据库状态，并触发后续动作
- 不要在回调里做耗时操作（如调语音 API、发短信），只做原子性事务：验签 → 更新订单状态 → 写日志 → 发消息到
Workerman的 Gateway 进程
用 GatewayWorker 绑定商户 UID，避免广播错人
多个商户共用一套后台时，语音播报必须精准推给对应门店或收银员。直接 Gateway::sendToAll() 会全网喊话，极其危险。
关键点在于绑定时机和 UID 来源：
- 商户登录后台时，前端通过
socket.emit('init', {id: 'mch_123456'})向Workerman发送初始化请求 -
Events.php中的onMessage收到init类型消息后，调用Gateway::bindUid($client_id, $uid)，其中$uid必须来自你自己的商户表（不是微信sub_mch_id） - 支付回调验证通过后，用
Gateway::sendToUid('mch_123456', json_encode(['type'=>'voice', 'amount'=>'28.50']))推送 - 前端 socket 监听该消息，再调用浏览器
AudioAPI 或外链语音文件播放
语音播报别依赖浏览器 Audio，优先走硬件音响
浏览器 new Audio().play() 在 iOS、部分 Android、后台标签页下大概率静音或被拦截。商户真实场景中，99% 的语音播报失败都源于此。
更可靠的做法：
- 前端收到
Workerman推送后，不自己播，而是向本地局域网内一台专用语音盒（如树莓派 + USB 音响）发 HTTP 请求，例如：fetch('http://192.168.1.100/speak?text=收款28元5角') - 或者让语音盒主动轮询一个轻量接口（如
/api/v1/voice/pending），服务端把待播报消息存 Redis，语音盒取到就播并标记已处理 - 如果必须用浏览器播，至少加 fallback：检测
audio.play()是否被拒绝，若拒绝则弹出桌面通知 + 播放系统提示音（Notification.requestPermission()需用户授权一次）
对账不是“实时推送”，而是异步比对 + 差异告警
很多人误以为“实时对账”就是支付成功立刻核对金额。实际上，微信/支付宝回调可能延迟、重复、甚至丢失。真正的对账是周期性拉取对账单（T+1），与本地订单库逐笔比对。
Workerman 在这里只承担一个角色：当对账脚本发现差异（比如某笔订单本地有、微信无），立即通过 Gateway::sendToUid() 推送给财务人员，而不是等人工查日志。
注意两个硬性条件：
- 对账脚本（如
php think pay:reconcile --date=2026-05-21）必须脱离Workerman进程运行，用 Linuxcron调度 - 差异记录要写进数据库，同时触发
Workerman推送；不要在脚本里直接 new Worker 或启动 Gateway 实例 - 推送内容必须包含原始对账单行号、订单号、差额、平台来源（微信/支付宝），方便人工溯源
Workerman 一把抓。
