配推送这事，卡人的地方基本不在代码。Xcode 里 Push Notifications 的 capability 勾了， didRegisterForRemoteNotificationsWithDeviceToken 也实现了，真机跑起来——没反应。查了半天，十有八九是两类问题：要么推送证书压根没做对、没跟 Bundle ID 绑上，要么证书做对了，但沙盒和生产环境搞混了。我自己头一回配的时候，就是栽在环境这一步，消息明明显示"发送成功"，手机屏幕一片安静（苦笑）。

这篇就按顺序走一遍 iOS 推送证书（APNs）怎么制作、怎么跟 Bundle ID 绑定，再用 Appuploader 自带的推送平台直接发一条测试推送验证——不用你先去搭一套服务端。末了再跟几种常见的推送测试方式对比一下，省得你以为只有一条路。

第一步：签发一张 APNs 推送证书

推送证书跟你平时打包用的开发/发布证书是两码事，得单独做一张。前提是你有一个已付费（99 美元/年）的苹果开发者账号，并且登录好了。

在 Appuploader 的「证书」页面签发一张 APNs 推送证书，类型按用途选：应用只在开发测试阶段，就做开发类型；要上架，就做发布类型。签发时会让你给证书的 .p12 设一个导出密码——这个密码后面建推送通道还要用，记牢，别回头又忘了（这密码丢了没法找回，只能重做）。

推送证书的核心是跟某个 Bundle ID 绑定的，一张证书服务一个 App，别指望拿一张到处用。

第二步：给 Bundle ID 打开推送能力

证书做完还没完，得保证描述文件证书和推送证书绑在同一个 Bundle ID 上。

在 Appuploader 的 Bundle ID 设置里，找到你的 App 对应的那个 ID，把推送（Push Notifications）这项能力打开，然后重新生成一次描述文件。这一步很容易漏——不少人证书做好了却忘了回来开能力，或者开了能力没重新生成描述文件，用的还是旧的那份，装到真机上能力其实没生效。

改动了 Bundle ID 的能力之后，一定要重新生成并重新下载描述文件。旧描述文件不带新能力，哪怕你本地看着证书齐全，真机上推送也注册不上。

第三步：建推送通道，拿 App Key

证书和描述文件备齐，接下来进 Appuploader 的推送模块。它是一套独立于 App Store Connect 的运营推送平台，分推送通道、设备库、发送、历史四个标签页。先从通道开始。

点「新建通道」，选刚才那张 APNs 推送证书（列表为空说明证书还没签发，回第一步），输入 .p12 的导出密码——证书在云端有备份的话，输密码就能取出私钥。再填个通道名字，比如"营销推送"，然后选环境：生产，还是沙盒。

这个环境选择是整条链路里最容易踩的坑，单独拎出来说。

沙盒和生产是两套完全独立的推送通道，互不相通，连 device token 都不通用。 开发调试、Ad Hoc、TestFlight 装的包，走沙盒；App Store 正式下载的包，走生产。选错了不会报错，发送记录照样显示"成功"，但设备就是收不到。表现跟证书失效、token 没上报特别像，很容易被误判成"推送坏了"。

通道建好，在「接入代码」里能看到给开发同学的接入说明和 App Key。App Key 就是你的 App 上报设备 token 时要带的身份标识。

第四步：App 端接入，把 device token 上报上来

这一步在你自己的工程里做。先在 Xcode 的 Signing & Capabilities 里加上 Push Notifications，然后在 AppDelegate 里把拿到 token 的回调接上。大致是这样：

1func application(_ application: UIApplication,2    didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data) {3    let token = deviceToken.map { String(format: "%02x", $0) }.joined()4    // 把 token POST 给接入说明里给出的上报接口，带上 App Key5    reportToken(token, appKey: "你的 AppKey")6}

把接入说明里给的那段上报方法放进去，App 拿到 APNs token 之后调一次上报接口，这台设备就自动进「设备库」了。测试的时候记得选手机所在的局域网地址，保证手机跟你电脑在同一个 Wi-Fi 下，不然上报请求发不过去。

设备库这一页能按备注、token、标签搜，也能手动加设备——token 带空格或者尖括号它会自己清理掉，这点还挺省事。每台设备会显示是有效还是失效、最近啥时候上报的。

设备库里一直看不到设备？先查这几处

接入代码接好、App 也跑起来了，设备库却空着——这是这一环最常见的卡点。按下面几处挨个看，基本能定位：

• 没申请通知权限：App 得先调一次 registerForRemoteNotifications()，而且用户要在系统弹窗里点了允许。还有一点容易忘：模拟器拿不到真实 APNs token，这步必须真机。
• Push 能力漏开，或描述文件还是旧的：回第二步确认 Bundle ID 的推送开了、描述文件是重新生成后重新装进去的，别用着改能力之前的那份。
• 手机和电脑不在同一个 Wi-Fi：上报接口走的是局域网地址，手机要是连了别的网、或者干脆用着蜂窝数据，请求压根到不了你本机。
• 回调根本没触发：真机上 didRegisterForRemoteNotificationsWithDeviceToken 一直不进、反而走了 didFailToRegisterForRemoteNotificationsWithError，那多半是证书或描述文件这一环的问题，错误信息里会给线索，顺着回第一、二步查。

我自己排这类问题的顺序是从后往前：先看回调进没进，进了再看上报请求通没通，实在排不掉才回去查证书——反过来从证书查起，容易把时间浪费在没问题的地方。

第五步：发一条测试推送，看投递报告

到这儿就能真发了。进「发送」页，选好通道，填标题、内容、提示音、角标数字；想测复杂点的结构，切「高级模式」直接写原始 JSON Payload，比如：

1{2  "aps": {3    "alert": { "title": "新工单", "body": "有一条待处理的工单" },4    "sound": "default",5    "badge": 16  }7}

发送目标可以选全部设备、按标签、或者指定某几台。系统会先告诉你这条会发往多少台有效设备，确认了再点「立即发送」。发完直接给你成功/失败的设备数。

最有用的其实是「历史」页的投递报告。 每条发送记录点进详情，能看到逐台设备的投递结果——成功、失败、已投递，失败的还给原因。某台设备没收到，是 token 失效了还是环境没对上，这里一看就清楚，不用瞎猜。想重发某条历史记录，直接点重发就行。

顺带提一句，删通道要谨慎：这个通道下的设备库和发送历史会一起删掉，App Key 立刻失效，而且撤不回来。

跟其他推送测试方式比一下

发测试推送当然不止 Appuploader 这一条路，看你手头有啥、图什么：

• Xcode + 自建服务端：最正规，但你得先写一套调 APNs 的服务端代码，光为了测一条推送，成本有点高；
• curl 直接调 APNs HTTP/2 接口：轻，适合验证证书本身通不通，但得自己拼 JWT 或者带证书，命令一长串，设备 token 还得想办法先弄到手；
• NWPusher 这类 Mac 端工具：好用，可惜是 Mac 的，Windows 上没得选；
• 极光、个推这些第三方推送平台：功能全、能做大规模运营，但要接 SDK、注册账号，为了测几条就接一套 SDK 略重。

Appuploader 的位置其实挺清楚：证书在它这儿做的，做完顺手就能建通道发测试，证书到发送是连着的，中间不用倒腾服务端；而且它是跨平台的，Windows 上也能把这套走完。真要做高并发的正式运营推送，该上专门的推送平台还是得上，这点它不抢那个活儿。

小结

iOS 推送证书（APNs）配置的坑，多半集中在证书没绑对 Bundle ID、能力开了没重新生成描述文件、沙盒生产环境选反这三处。拿 Appuploader 走的话，证书签发、Bundle ID 开能力、建通道发测试是一条线下来的，发完还能在投递报告里逐台核对结果。按这五步配一遍，下次再遇到"显示成功但收不到"，你大概知道问题所在了。