WePush 5.0.9 已发布。这个版本没有堆叠大量新功能，而是把重点放在消息通道的调用方式上：多家短信服务从依赖第三方 Maven SDK，调整为直接调用服务商接口；钉钉相关调用也同步减少第三方 SDK 依赖。
对于一个专注批量推送的小工具来说，这类改动很实际。依赖更少，通常意味着更轻的构建结果、更少的版本冲突，以及更容易排查的网络请求链路。
这次更新改了什么
短信通道改为直连调用
5.0.9 优化了多家短信通道的依赖方式，涉及阿里云、百度云、腾讯云、七牛云、云片等短信服务。根据更新说明，相关调用改为直接访问服务商接口，并移除了对应的 Maven 依赖。
这里的“直连调用”可以理解为：应用不再主要通过服务商提供的 Java SDK 完成请求，而是自行组装 HTTP 请求、签名参数和请求体，再调用服务商的开放 API。
这种方式的价值主要体现在几个方面：
- 减少项目依赖数量，降低传递依赖冲突的概率。
- 避免 SDK 升级节奏与应用自身节奏不一致。
- 请求、响应和异常处理更容易统一封装。
- 在批量推送场景下，更方便增加重试、限流和日志记录。
但代价也很明确：签名算法、时间戳、编码方式、错误码和接口版本需要由项目自己维护。直连并不等于更简单，而是把原本由 SDK 隐藏的工作显式放回了应用层。
钉钉调用减少第三方 SDK
钉钉相关调用也进行了优化，目标同样是减少第三方 SDK 依赖。对于消息推送工具，这种调整有助于把不同渠道的调用统一到更清晰的 HTTP 适配层中。
一个较稳妥的设计是为每个通道保留独立适配器，例如：
MessageChannel
├── SmsAliyunChannel
├── SmsTencentChannel
├── SmsYunpianChannel
└── DingTalkChannel
每个适配器只负责三件事：准备认证信息、发送 HTTP 请求、把服务商响应转换成统一结果。上层的批量任务则只关心“发送成功、失败、是否可重试”等业务状态。
直连 HTTP 调用可以怎样落地
下面是一个可改造的 curl 示例，用于说明短信服务直连调用的基本形态。不同服务商的 URL、签名字段、请求头和参数名称并不相同，因此这不是某一家服务商的官方命令，运行前需要替换为对应平台的接口定义。
#!/usr/bin/env bash
set -euo pipefail
SMS_ENDPOINT="https://sms-provider.example.com/v1/messages"
API_KEY="replace-with-api-key"
SIGNATURE="replace-with-generated-signature"
curl --fail-with-body --silent --show-error \
--request POST "$SMS_ENDPOINT" \
--header "Authorization: Bearer ${API_KEY}" \
--header "X-Signature: ${SIGNATURE}" \
--header "Content-Type: application/json" \
--data '{
"mobile": "13800000000",
"template_id": "login_code",
"template_params": {
"code": "123456"
}
}'
接入真实通道时，建议把这段流程拆成可测试的步骤：
- 根据服务商文档生成时间戳、随机数和签名。
- 使用明确的字符集序列化请求参数，避免签名和发送内容不一致。
- 设置连接超时与读取超时，不能让单个通道阻塞整个批量任务。
- 区分网络错误、认证错误、参数错误和业务拒绝。
- 对明确可重试的错误使用退避策略，避免重复发送短信。
例如，批量推送服务不应把所有异常都简单转换为“发送失败”然后立即重试。认证失败通常需要告警，参数错误需要修复模板或手机号，而临时网络错误才适合有限次数重试。
依赖减少之后，工程上要补什么
移除 SDK 后，项目需要补回一些原本由 SDK 提供的能力。可以在通道公共层统一配置以下内容：
push:
http:
connect-timeout-ms: 3000
read-timeout-ms: 5000
max-retries: 2
retry-backoff-ms: 500
logging:
request-id: true
mask-mobile: true
record-provider-response: false
这份配置只是一个实践示例，具体配置项需要根据 WePush 的部署方式和现有配置结构调整。尤其要注意日志脱敏：手机号、Access Key、签名和短信内容都不应直接写入普通业务日志。
还可以为每个通道设计统一的返回对象，例如：
public record PushResult(
boolean success,
boolean retryable,
String providerCode,
String message,
String requestId) {
}
这样，上层批量任务无需理解阿里云、腾讯云或云片的具体错误码，只需要根据 success 和 retryable 决定是否记录、重试或告警。真正的服务商错误码仍应保留在 providerCode 中，方便排查问题。
升级到 5.0.9 时的检查清单
如果正在使用旧版本，升级后可以重点检查下面几项：
- 构建文件中是否仍然残留不再需要的短信或钉钉 SDK 依赖。
- 各通道的 Access Key、Secret、签名和模板配置是否能正常读取。
- 测试环境能否完成一条真实但低风险的短信发送。
- 网络超时、服务商限流和无效参数是否有清晰日志。
- 批量发送失败后，重试任务是否可能造成重复消息。
- 生产环境是否设置了请求超时、并发上限和敏感信息脱敏。
小结
WePush 5.0.9 的核心变化是一次依赖治理和调用链路优化：短信通道改为直连调用，钉钉调用减少第三方 SDK。对于批量推送工具，这种调整有助于保持项目轻量，也让各通道的 HTTP 行为更透明。
采用这类版本时，不能只关注 Maven 依赖数量是否下降，还要同步检查签名、超时、重试、错误码映射和日志安全。把服务商差异封装在独立适配器中，才能在减少 SDK 的同时，避免把复杂度扩散到整个推送系统。