EdgeOne Webhook Pusher 开发日志专题
如果你用过 Server酱、PushDeer 或者企业微信机器人，你大概能体会一个矛盾：
- 我只想“发条微信通知”，但要么要付费，要么要把数据交给第三方。
- 我也可以自己搭服务，但“为了一个通知系统买台服务器/备案/维护证书”，性价比太低。
edgeone-webhook-pusher 想解决的就是这个矛盾：用尽可能低的运维成本，把推送能力变成你自己的基础设施。
这个项目到底是什么
一句话：
你得到一个带管理后台的 webhook 服务：
curl一下，就能发微信。
最常见的使用方式是：
- NAS 下载完成通知
- CI/CD 部署通知
- HomeAssistant 告警
- 脚本/爬虫结果
先把关键约束讲清楚
这个项目之所以“看起来简单，但实现并不 trivial”，核心原因是边缘环境的约束：
- Node Functions 不直接读 KV：需要 Edge Functions 代理 KV（这是架构最关键的一刀）。
- 微信 API 强依赖 token：要缓存、要重试、要把错误变成可理解的状态。
- 绑定流程是事件驱动：扫码/关注回调的不确定性，决定了你必须写幂等。
一张图理解整体数据流
flowchart LR
subgraph Caller[调用方]
S["脚本/系统
NAS/CI/HA"] -->|"GET/POST"| SEND["/send/appKey/"] end subgraph EdgeOne[EdgeOne] SEND --> NF["Node Functions
业务 API"] NF -->|"HTTP"| EF["Edge Functions
/api/kv/*"] EF <--> KV["(KV Storage)"] end NF -->|"WeChat API"| WX["微信/企业微信"]
NAS/CI/HA"] -->|"GET/POST"| SEND["/send/appKey/"] end subgraph EdgeOne[EdgeOne] SEND --> NF["Node Functions
业务 API"] NF -->|"HTTP"| EF["Edge Functions
/api/kv/*"] EF <--> KV["(KV Storage)"] end NF -->|"WeChat API"| WX["微信/企业微信"]
核心概念（建议先记住这 5 个名词）
- Channel：推送渠道（微信测试号/企业微信等），决定你“用哪套 API 发消息”。
- App：对外暴露的应用，一个 App 对应一个
appKey。 - OpenID：接收者身份（微信侧的用户标识）。
- BindCode：把用户身份“交回系统”的桥梁（绑定码/场景值）。
- Message：推送历史（用于追踪、排障、未来的重试/统计）。
系列文章怎么读（按你要解决的问题）
-
你只关心能跑起来：
-
你要二开/扩平台：
-
你想把它当“架构案例”复用：
- 重点看 KV 代理这一刀（Node->Edge 调用）
- 重点看 token 状态维护（把外部不确定性变成内部可观测状态）
- 重点看绑定流程的幂等设计（事件驱动系统的基本功）
这套东西的启发（写给未来的自己）
- 把“不稳定外部世界”翻译成“稳定内部模型”：比如 token 状态、消息结果落库。
- 边缘架构最怕“隐式环境假设”：比如 baseUrl 推断失败，所以要
KV_BASE_URL。 - 对外接口越简单，内部就越要有边界：send 路由越“傻瓜”，越需要良好校验、隔离与观测。
约定
- 日期：本专题文章日期统一为
2026-01-25，用于一次性整理输出。 - 聚合方式：统一使用
project: edgeone-webhook-pushercategories: ['EdgeOne Webhook Pusher']tags标注模块关键词