TG咨询推送消息到达率在不同网络出口下的对照测试，第一步不是换线路，而是先确认“出口”指哪一段：服务端访问推送平台的出口，还是手机接收消息时使用的网络。两者影响的链路不同，混在一起比较，结果就难以解释。
先划清测试边界
以服务端出口为例，应用后台通过不同公网出口连接 Apple APNs、Firebase Cloud Messaging（FCM）或华为 Push Kit。出口可能影响平台接口的连接成功率、响应时间和重试情况，但平台接受请求不等于手机已经收到通知。设备侧还会受到系统状态、网络连接、通知权限和厂商策略等因素影响。
如果比较的是用户网络，应记录设备接入的网络类型或运营商，并尽量固定服务端出口。不要把“服务端请求成功率”“推送平台受理率”和“设备确认送达率”统称为到达率；它们是不同指标。
按统一口径搭建对照
- 定义结果。将“到达”设为设备端收到消息并上报确认；另行记录服务端请求结果、平台返回状态及设备确认时间。若设备端没有可靠回执，只能报告可观测指标，不能据此断言所有消息均已送达。
- 固定条件。使用相同应用版本、消息内容、发送优先级和目标设备范围。记录系统版本、通知权限、设备是否在线等信息；测试期间避免同时调整重试规则或消息频率。
- 分配出口。将请求按设备或独立测试批次分到出口 A、出口 B。尽量让两组在相近时段运行，并采用轮换顺序，避免某个出口恰好只赶上网络繁忙时段。确认各出口的 DNS、代理、证书和防火墙配置一致，差异项单独记录。
- 设置观察窗。预先规定发送后多久算及时送达，例如选定数分钟的观察窗口；同时保留更长时间的迟到记录。窗口应结合消息用途确定，不要在看到结果后再改标准。
- 重复并核查。分多个时段重复测试，分别统计请求数、平台受理数、设备确认数、超时数和延迟分布。排查重复消息、设备离线、令牌失效及回执丢失，避免把数据采集故障误判为出口问题。
结果怎样比较才有意义
统一计算口径后，可用“观察窗口内设备确认数 ÷ 有效发送数”计算确认到达率，并同时报告样本量和时间范围。按系统、网络类型和出口分层查看，比只给一个总百分比更容易发现差异。延迟可报告中位数及较慢分位值；平均值容易被少数长时间延迟拉高。
例如，出口 A 的平台受理率较高、设备确认率却相近，差异可能发生在平台受理之后，不能直接归因于出口。若 A、B 的接口失败和超时反复呈现稳定差别，再检查出口到平台的路由、代理和连接复用设置。样本少或时段不一致时，百分比波动可能只是偶然；先增加重复批次，再判断是否值得切换线路。
常见问题
平台返回成功，为什么手机没显示？
平台受理通常只说明请求通过相应接口，不代表设备已接收或展示。还需核对设备端确认、通知权限、网络状态和消息有效期。
每组要测多少条消息？
没有适用于所有系统的固定数量。先做小批次验证日志和回执完整，再按业务风险和可接受误差扩大样本；消息量较小时，应明确结果仅供初步判断。
两组到达率不同，就该更换出口吗？
不一定。先确认差异是否跨时段重复出现，并检查请求失败、设备侧确认和样本构成。只有差异稳定且能定位到出口链路时，调整出口才有依据。
归根结底，比较时要分开看平台受理与设备确认，控制设备和消息条件，并保留分出口、分时段的记录。这样得到的结果才能说明差异出现在哪一段，而不只是显示两个数字不同。