pusher 的 v4 转向：从一个微信渠道，到一张渠道注册表

状态说明：v4 正在开发中，尚未正式发布。公开仓库的现行版本见项目介绍。这篇写的是这次重构的判断与进展，属于本专栏的「分析」类文章。

旧问题：每加一个渠道，就多一份胶水代码

pusher 最早只有微信一个渠道。用户很快开始要更多：Bark（iOS 推送）、企业微信机器人、Telegram、Server酱……每个渠道的接入方式都不一样——有的要签名，有的要特定的 JSON 结构，有的 token 放在路径里。

如果按「一个渠道一个模块」堆下去，代码里会长满形状各异的胶水：参数校验一份、错误处理一份、后台表单一份。渠道越多，维护面越不可控。更麻烦的是**「支持」二字没有标准**：文档里写着能发，真实环境里到底能不能发，没人验证过。

v4 的答案：注册表驱动，实测为准

v4 把渠道层重构成一张注册表：

• 每个渠道是一个注册项，声明自己的参数结构、签名方式、请求构造与响应判定；
• 后台的渠道配置表单由服务端的渠道描述（descriptors）自动生成，加渠道不用再写一遍前端表单；
• 推送主流程只面对统一的渠道接口，不关心对面是微信还是 Bark。

目前注册表上有 11 个推送目标，包括 ntfy、带签名的通用 Webhook、Server酱 Turbo、企业微信机器人、Bark、iLink 中继等。重点是它们进入注册表的方式：每一个都经过真实请求验证（live probe）才算数——不是照着文档写完就宣称支持，而是实际发出去、确认到达。渠道矩阵文档里给每个渠道标了证据等级，测过就是测过，没测的不会混进来充数。

iLink：把个人微信这条线走通

个人微信推送是国内开发者的高频需求，也是最难的一条：官方路径限制多，第三方服务又经手内容。v4 里接入了 iLink 扫码登录的微信机器人通道——用户扫码授权，通道以机器人形态收发，个人微信直达。在多渠道架构里，它只是注册表上的一行，但这一行是同类项目里最少见的。

MCP v4：工具面收敛到「一个应用」

现行版本的 MCP 工具面偏散。v4 做了一次收敛：工具绑定单个应用，参数面变小，语义变明确。对调用方（AI 编程工具）来说，工具越少越不容易选错；对维护方来说，行为边界也更容易测试。这次调整的取向是：MCP 不是把后台 API 原样暴露出去，而是为 AI 调用重新设计的一层薄接口。

为什么说这是「转向」而不只是升级

因为定位变了。旧定位是「一个好用的微信推送工具」；v4 之后，它是「一张经过实测的渠道网络 + 一个为 AI 设计的调用面 + 一次点击就能完成的托管部署」。截至 2026 年 10 月的同类项目调研里，同时具备个人微信通道、EdgeOne 一键托管、渠道逐个实测这三项的，仍然只有它一个。单点功能容易复制，验证过的渠道矩阵和部署体验复制起来要慢得多——这就是把重构押在这里的原因。

v4 的发布会走一个严格的对账流程：私有开发仓与公开仓的增量逐项核对、全部测试与渠道探针复跑、历史 issue 逐项给出处理口径，然后才合入公开仓发布。对账完成之前，这篇就只是分析，不是发布公告。