在TP5.1中初始化JPush客户端需封装为单例服务类,从config/jpush.php读取appkey和master_secret,避免硬编码;使用thinkContainer绑定或控制器手动实例化,确保HTTP连接复用。
TP5.1 项目接入 JPush,核心在于服务端调用 SDK 发起推送、客户端上报设备标识(如 registration_id),并用别名(alias)建立用户与设备的稳定映射。状态回执不是默认开启的,必须显式配置回调地址并处理极光返回的 msg_id 和后续的回执事件。
别直接 new Client,得封装成可复用的服务类,并确保密钥不硬编码。
appkey 和 master_secret 必须从配置文件读取(如 config/jpush.php),避免泄露到代码中JPushClient 实例,防止重复创建 HTTP 连接池thinkContainer 绑定服务curl_setopt 或 SSL 验证失败,会抛出 APIConnectionException
alias 不是“注册一次就永久有效”,它本质是设备级绑定,一个 alias 最多关联 10 个 registration_id;且需客户端主动调用 JPushInterface.setAlias() 上报,服务端无法强制设置。
registration_id 的第一时间调用 setAlias,参数为用户唯一标识(如 uid_12345)audience => ['alias' => ['uid_12345']],不能写成字符串 'uid_12345',否则报错 Invalid audience format
deleteAlias 清理旧绑定,否则可能出现消息推送给错误账号400 Bad Request
TP5.1 本身不提供回执监听能力,必须靠极光的「推送结果回调」机制,即你提供一个公网可访问的 URL,极光在消息送达/点击后 POST 数据过来。
options => ['sendno' => time(), 'apns_production' => true, 'time_to_live' => 86400],其中 sendno 是你自己生成的唯一序号,用于后续匹配回执/api/jpush/callback),协议必须是 HTTPS,且需校验 X-JPUSH-SIGNATURE 请求头msg_id(极光内部 ID)、sendno(你传的序号)、status(received/clicked)、platform、registration_id
input('post.') 获取原始 POST 数据,再用 file_get_contents('php://input') 解析 JSON,避免自动解析破坏签名验证别名推送失败往往不是代码问题,而是环境或配置断点卡住。
setAlias 或调用失败(检查 Logcat / Xcode 控制台是否有 JPush: Set alias failed)registration_id(Android 设备重装 App 或厂商通道限制会导致 ID 变更)X-JPUSH-SIGNATURE 是 sha256(appkey + master_secret + json_body),注意 body 必须是原始字节流,不能先 decode 再 encode真正麻烦的是 alias 生命周期管理和回执数据去重。一个用户可能有多个设备,每次登录都重新 setAlias,但旧设备不会自动解绑;回执可能重复到达,需要按 msg_id + registration_id + status 做幂等写入。