本文介绍在 go 中通过 go-gcm 库发送 xmpp 推送通知时，针对连接超时等网络异常的正确错误处理策略，重点推荐指数退避重试机制，并提供可落地的实现方案与注意事项。
本文介绍在 go 中通过 go-gcm 库发送 xmpp 推送通知时，针对连接超时等网络异常的正确错误处理策略，重点推荐指数退避重试机制，并提供可落地的实现方案与注意事项。
在基于 go-gcm 的 XMPP 推送服务中，SendXmpp() 调用频繁出现 write: connection timed out 错误，本质是底层 TCP 连接因网络抖动、服务端响应延迟或客户端连接池老化而失效。此时简单重启进程虽能临时恢复，但违背高可用设计原则——真正的健壮性应由客户端主动应对瞬态故障（transient failures）。
核心解决方案：指数退避（Exponential Backoff）重试
不应手动管理 XmppClient 的生命周期（如显式 Close + 重建），因为 go-gcm 的 XmppClient 并未暴露连接控制接口，且 XMPP 连接本身状态复杂（含 SASL 认证、流初始化等）。更合理的方式是将 SendXmpp() 封装为幂等可重试操作，并配合退避策略自动恢复：
import (
"context"
"time"
"github.com/google/go-gcm"
)
// 使用第三方库（如 backoff/v4）实现标准退避
func sendWithBackoff(client *gcm.XmppClient, msg *gcm.Message) error {
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
defer cancel()
// 配置指数退避：初始间隔 100ms，最大重试 5 次，上限 2s
b := backoff.WithContext(
backoff.NewExponentialBackOff(),
ctx,
)
b.MaxInterval = 2 * time.Second
b.MaxElapsedTime = 15 * time.Second
var lastErr error
err := backoff.Retry(func() error {
if ctx.Err() != nil {
return ctx.Err()
}
if err := client.SendXmpp(msg); err != nil {
lastErr = err
// 仅对可重试错误退避（如 I/O timeout、connection reset）
if isTransientError(err) {
return err
}
return backoff.Permanent(err) // 不可重试错误，立即终止
}
return nil
}, b)
return err
}
func isTransientError(err error) bool {
if netErr, ok := err.(net.Error); ok && netErr.Timeout() {
return true
}
if strings.Contains(err.Error(), "connection refused") ||
strings.Contains(err.Error(), "i/o timeout") ||
strings.Contains(err.Error(), "connection reset") {
return true
}
return false
}
关键注意事项：
- ✅ 避免无限制重试：必须设置 MaxElapsedTime 或最大重试次数，防止雪崩；建议上限 ≤ 15 秒；
- ✅ 区分错误类型：仅对网络层瞬态错误（timeout、connect reset）重试；认证失败、无效 token 等应直接返回，避免浪费资源；
- ✅ 集成上下文取消：通过 context.Context 支持请求级中断，防止 goroutine 泄漏；
- ⚠️ 不依赖连接复用修复：go-gcm 的 XmppClient 并非线程安全，且未提供连接健康检查机制，强行 Close/Reconnect 可能引发竞态；退避策略天然规避了该问题；
- ? 监控与告警：记录重试次数、最终失败原因，当某设备持续失败时，应触发 token 失效检查（可能已卸载 App）。
综上，指数退避不是“绕过问题”，而是以工程化方式承认分布式系统的不确定性。它显著提升推送成功率（实测可将超时类失败率降低 90%+），同时保护下游 GCM/XMPP 服务免受突发重试冲击，是生产环境必备的容错实践。
