开发日志索引：edgeone-webhook-pusher（目录页）

开发日志索引：edgeone-webhook-pusher

这个系列写给两类人：

想要 0 成本自建推送的人：希望“复制粘贴 + 一键部署”就能跑起来。
想看工程取舍的人：关心为什么这样拆、哪些坑最容易踩、哪些模式值得复用到你的项目里。

项目目标很简单：把“微信推送”变成一个你的私有能力——像调用 webhook 一样调用它，而不是把数据交给第三方。

一张图先建立直觉

你可以把系统理解成一个“边缘上的三层结构”：

flowchart TB U["你的脚本/系统
NAS/CI/HomeAssistant"] -->|"HTTP GET/POST"| SEND["Node Functions
/send/appKey"] UI["Web UI
管理后台"] -->|"HTTP"| API["Node Functions
管理 API"] SEND --> PUSH["Push Service
编排推送"] API --> SVC["Domain Services
Channel/App/OpenID/Message"] PUSH -->|"WeChat API"| WX["微信/企业微信"] SEND -->|"HTTP 调用"| KVAPI["Edge Functions
/api/kv/*"] API -->|"HTTP 调用"| KVAPI KVAPI <--> KV[("EdgeOne KV
5 个命名空间")]

读完整个系列，你应该能回答：

为什么 Node Functions 不能直接读 KV，以及这对你的架构意味着什么。
为什么推送入口要做成“弱认证 AppKey”，风险在哪里、怎么兜底。
为什么“绑定用户”是整个系统里最容易写崩的部分（以及如何让它幂等）。

读这个系列的方式

如果你只想用：优先读 send、部署配置 两篇。
如果你要二开：优先读架构、绑定流程、push 编排。

开发日志索引：edgeone-webhook-pusher（目录页）