共 13 篇文章
记录一次“先保微信不回归、再上企业微信”的重构规划：用桥接模式解耦 Channel/App，用策略模式做运行时选择，用模板方法固定发送流程。
基于新架构（桥接/策略/模板方法）落地企业微信渠道：corpId/corpSecret/agentId、userId/departmentId 目标、text/textcard 消息与错误处理。
edgeone-webhook-pusher 开发日志专题目录页，包含按模块划分的文章入口与推荐阅读顺序。
介绍管理后台 API 的整体路由划分、管理员令牌的校验方式，以及统一错误处理/响应包装带来的维护收益。
详解推送入口的 URL 设计、GET/POST 兼容、CORS、参数校验、以及通过 AppKey 进行“弱认证”的实现方式。
解释 edgeone-webhook-pusher 为什么要拆成 3 层运行形态（前端 Pages、Node Functions、Edge Functions），以及 Node Functions 访问 KV 的代理方案与边界约束。
渠道是推送能力的“底座”。本文聚焦渠道配置模型、校验逻辑、以及微信/企业微信 API 的差异如何在服务层被隔离。
拆解“生成绑定码 -> 扫码关注/触发回调 -> 写入 OpenID -> 绑定完成”的全链路，并说明测试号/服务号权限差异下的实现取舍。
App 是对外暴露的推送入口。本文说明 AppKey 生成与索引、推送模式（single/subscribe）和消息类型（custom/template）的组合如何影响推送流程。
讲清 push.service 的编排逻辑：从 AppKey 查 App/Channel/OpenIDs，到按推送模式选目标，再到调用微信 API 并落库 Message 历史。
解释 wechat-msg 路由如何处理 GET 验证与 POST 消息回调；包括签名校验、XML body 解析、以及关注/扫码等事件如何驱动绑定流程。
总结 EdgeOne 一键部署的关键配置项：5 个 KV 命名空间、KV_BASE_URL、内部鉴权 key，并给出最常见的“KV 访问失败”排障思路。
按模块/领域拆解 edgeone-webhook-pusher（0成本自建微信推送）的功能实现与开发要点，方便回顾架构决策与关键坑位。
