Go语言调用短信API需安全封装：用自定义http.Client设超时，分网络/HTTP/业务三类错误处理，敏感信息外置注入，客户端限流+去重+有节制重试。
Go 语言本身不内置短信发送能力，必须调用第三方 HTTP API（如阿里云、腾讯云、Twilio 或国内聚合平台）。关键不在“能不能发”，而在于如何安全、健壮地封装调用逻辑——尤其是错误分类处理、重试控制和敏感信息隔离。
用 net/http 调用短信 API 的最小可靠结构
别直接裸写 http.Post，它无法细粒度控制超时、重定向和错误类型。应显式构造 *http.Client 并设置 Timeout：
client := &http.Client{
Timeout: 10 * time.Second,
}常见坑：
-
http.DefaultClient没有默认超时，网络卡住会永久阻塞 goroutine - 未检查
resp.StatusCode就直接json.Unmarshal响应体，导致 401/403/502 等错误被误判为“成功解析” - 请求头漏设
Content-Type: application/json，部分服务（如腾讯云）直接返回 415
区分三类错误并分别处理
短信调用失败不能只用 error != nil 判断。必须拆解为：
立即学习“go语言免费学习笔记（深入）”；
-
网络层错误：如
context.DeadlineExceeded、net.OpError—— 可重试 -
HTTP 状态码错误：如
400（参数错）、401（密钥失效）、429（限流）—— 多数不可重试，需记录日志并告警 -
业务响应错误：API 返回
200但 JSON body 中code != 0（如阿里云的"Code":"isv.BUSINESS_LIMIT_CONTROL"）—— 属于服务商侧限制，需降级或告警
示例判断逻辑：
if err != nil {
var netErr net.Error
if errors.As(err, &netErr) && netErr.Timeout() {
// 网络超时，可重试
}
return err
}
if resp.StatusCode >= 400 {
// HTTP 错误，读取 body 做进一步分类
}敏感参数必须外部注入，禁止硬编码或从全局变量读
AccessKey、Secret、签名模板 ID 这些绝不能写死在代码里。推荐方式：
- 通过环境变量加载：
os.Getenv("SMS_ACCESS_KEY")，启动时校验非空 - 使用配置文件（如
config.yaml），配合spf13/viper加载，并设viper.AutomaticEnv()允许环境变量覆盖 - 若用云服务（如阿里云 SMS），优先走
credentials.NewEnvironmentVariableProvider()（aliyun-go-sdk-core v3+）自动识别环境变量
硬编码密钥一旦提交到 Git，风险不可逆。
避免并发调用压垮自身或触发服务商限流
高频发短信（如注册验证码）必须加限流。不要依赖服务商的“每秒 N 次”限制做兜底：
- 用
golang.org/x/time/rate.Limiter在客户端做前置限流，例如rate.NewLimiter(rate.Every(1*time.Second), 5)控制每秒最多 5 次 - 对同一手机号做短时间去重（如 60 秒内不重复发送），用
redis.SetNX或本地sync.Map+ TTL 实现 - 失败时不要无休止重试，建议最多 2 次，且第二次间隔 1 秒以上（用
time.Sleep或带 jitter 的指数退避）
服务商限流返回的错误码（如阿里云 isv.BUSINESS_LIMIT_CONTROL）要单独捕获并记录，这是容量瓶颈信号。
真正难的不是调通接口，而是让失败可追溯、重试有节制、密钥不泄露、并发不越界——这些细节没处理好，上线后第一波用户涌入就会暴露问题。
