直接调用第三方SDK易失控，因各厂商签名逻辑、参数结构、错误码体系差异大，硬编码导致业务层冗余处理非业务字段、渠道切换成本高、单元测试覆盖不足；应定义统一SmsRequest和SmsSender接口抽象核心业务语义，并在适配层标准化手机号、映射模板变量、转换错误为标准Go错误，同时通过环境变量或K8s Secret安全注入密钥。
为什么直接调用第三方 SDK 容易让业务代码失控
因为不同短信服务商（如阿里云、腾讯云、华为云）的 SendSms 接口签名逻辑、参数结构、错误码体系完全不同，硬编码调用会导致：业务层反复处理 AccessKeyId、SignatureMethod、Timestamp 等非业务字段；一旦切换渠道，要改遍所有调用点；单元测试只能 mock 整个 SDK，覆盖不到参数拼装逻辑。
定义统一的短信发送接口和抽象模型
核心是把「发给谁、说什么、用哪个模板、附带什么变量」从渠道细节里剥离开。推荐定义一个最小契约：
type SmsRequest struct {
Phone string `json:"phone"`
TemplateCode string `json:"template_code"`
Params map[string]string `json:"params,omitempty"`
}
type SmsSender interface {
Send(*SmsRequest) error
}
注意：Params 用 map[string]string 而不是 []string，因为各厂商对模板变量的占位符命名不一致（阿里云用 {code}，腾讯云用 ${code}），靠上层传入键值对，由具体实现决定如何映射。
各厂商 SDK 的关键适配差异点
不是简单包装 SDK，而是解决三类实际问题：
立即学习“go语言免费学习笔记（深入）”；
- 签名方式：阿里云强制
HMAC-SHA256，腾讯云默认HMAC-SHA1，华为云支持SHA256和SM3—— 必须在初始化时显式指定，不能依赖 SDK 默认值 - 手机号格式：阿里云要求
+8613800138000，腾讯云接受13800138000或8613800138000，华为云要求86-13800138000—— 统一在SmsSender.Send入口做标准化（建议转成8613800138000） - 错误处理：阿里云返回
Code: "InvalidParameter"，腾讯云返回ErrorCode: 1014，华为云返回result_code: "6001001"—— 不要直接透出，应统一转为 Go 标准错误，例如：errors.New("sms: invalid phone number")
如何安全注入配置并避免硬编码密钥
别把 SecretKey 写死在代码或 JSON 配置里。推荐组合方案：
- 开发环境：从
.env文件读取，用godotenv.Load(".env")，但确保.gitignore包含该文件 - 生产环境：通过环境变量注入，比如
ALIYUN_SMS_SECRET_KEY=xxx，Go 中用os.Getenv("ALIYUN_SMS_SECRET_KEY") - K8s 场景：用
Secret挂载为文件，再读取/etc/secrets/aliyun/sms_secret_key—— 这比环境变量更安全，避免被ps aux泄露
初始化 sender 时，检查必要字段是否为空，否则 panic 或返回 error，不要等到第一次 Send 才报错。
最常被忽略的是模板审核状态同步 —— 封装层可以加一个 CheckTemplateStatus(templateCode string) (bool, error) 方法，但别自己轮询，应该只提供钩子，让业务方在上线前调用一次校验。真正难的是多通道降级策略，比如主通道失败后自动切到备用通道，这需要额外的状态管理，不属于基础封装范畴。
