WePush 5.1.2 延续了“小而美”的定位，重点围绕消息类型、平台覆盖和批量推送效率进行更新。这一版本既补齐了多个常见通知场景，也将推送网络层升级为 HTTP/2，让批量发送时的连接复用更高效。
这次更新覆盖了什么
支持更多消息类型
本次更新不是简单增加一个平台入口，而是扩展了多个平台的消息表达能力：
- 新增飞书群自定义机器人消息支持。
- 企业微信新增小程序通知消息类型。
- 公众号客服消息新增图片、语音、视频和音乐类型。
- 修复公众号客服消息的素材上传问题。
- 钉钉 Markdown 消息支持变量替换。
这些能力对应的是实际推送流程中的常见需求。文本消息适合简单告警，Markdown 适合带结构的发布通知，小程序、媒体和音乐消息则可以承载更丰富的业务内容。
网络层升级为 HTTP/2
批量推送通常会连续请求多个平台或多个机器人接口。网络层升级到 HTTP/2 后，可以更好地利用连接复用和并发传输，减少重复建立连接带来的开销。对于需要一次性发送大量通知的任务，这类底层优化比单纯增加界面选项更直接。
不过，HTTP/2 并不会自动解决所有推送问题。服务端限流、接口超时、失败重试、素材上传耗时和第三方平台配额，仍然需要在任务设计中单独处理。
变量替换让 Markdown 通知更适合批量发送
钉钉 Markdown 消息支持变量替换后，可以使用同一份模板生成不同项目、环境或版本的通知。例如，模板可以写成：
## 发布通知
- 项目：${project}
- 环境：${environment}
- 版本：${version}
- 状态：${status}
发送前将变量替换为实际值，就能避免为每个项目维护一份几乎相同的 Markdown 内容。可以这样实践：将模板保存在版本库中，把 project、environment 和 version 作为构建任务的参数，在推送阶段生成最终消息。
需要注意变量来源和转义问题。外部输入直接写入 Markdown 时，可能破坏消息格式；如果变量来自用户提交或构建系统，应在生成消息前做长度限制和必要的字符处理。
可复制的推送测试示例
下面是一个用于测试飞书群自定义机器人消息的 curl 示例。它使用 HTTP/2 发起请求，适合验证网络环境和消息体格式。示例中的地址是假设值，运行前请替换为自己的机器人 Webhook 地址。
#!/usr/bin/env bash
set -euo pipefail
WEBHOOK_URL="https://open.feishu.cn/open-apis/bot/v2/hook/replace-with-your-token"
PROJECT="demo-service"
VERSION="v5.1.2"
payload=$(PROJECT="$PROJECT" VERSION="$VERSION" python3 - <<'PY'
import json
import os
print(json.dumps({
"msg_type": "text",
"content": {
"text": f"项目 {os.environ['PROJECT']} 已发布 {os.environ['VERSION']}"
}
}, ensure_ascii=False))
PY
)
curl --fail --silent --show-error --http2 \
-H 'Content-Type: application/json' \
-d "$payload" \
"$WEBHOOK_URL"
这个例子只验证一个机器人接口。实际使用 WePush 进行批量推送时，可以把项目名称、版本号和发布状态作为统一参数，再分别生成飞书、企业微信、钉钉或公众号客服所需的消息格式。媒体类消息还需要额外关注素材上传是否成功，以及素材 ID 是否已经正确写入后续消息。
升级时的检查清单
升级到 5.1.2 前后，可以按下面几项检查现有推送任务：
- 确认飞书机器人地址、签名配置和权限仍然有效。
- 为企业微信小程序通知补齐小程序 AppID、页面路径等业务参数。
- 检查公众号客服消息使用的图片、语音、视频和音乐素材是否能正常上传。
- 检查钉钉 Markdown 模板中的变量名称是否与发送任务保持一致。
- 在生产环境观察 HTTP/2 连接、超时和第三方限流情况。
- 为批量推送保留失败记录，避免网络抖动导致通知静默丢失。
WePush 5.1.2 的价值在于把常见平台的消息能力继续做深，同时改善批量推送的网络基础。对于已经使用 WePush 管理多个通知渠道的团队，这次升级适合先在测试群验证新消息类型，再逐步迁移生产模板，并结合失败重试和限流策略评估整体稳定性。