Webhook 部署实践：历史配置与可靠发布改进

这是一份宝塔 WebHook 2.5 的历史部署记录，重点保留“事件触发如何连接到发布流程”及原方案暴露的问题。它不是当前 VitaLogos 的部署操作手册，也不应把旧服务器地址、密钥和目录照搬到新环境。

原实践的流程

GitHub push → Webhook HTTP 请求 → 宝塔回调脚本 → Git 获取代码 → 更新站点

当时先安装插件、创建命名 Hook，再在代码托管平台填写回调信息。下面两张图仅保留管理界面说明：

历史回调地址和密钥截图已由文字说明替代。回调地址用于指向接收服务，认证信息用于验证请求来源；真实值属于服务配置，不应写入公开笔记或截图。

为什么旧脚本不宜继续照抄

原做法	问题	改进方向
设置 HOME=/root 并操作全局/系统 Git 配置	混淆运行身份，扩大影响范围	使用明确应用账户和仓库级配置
在在线网站根目录 reset --hard origin/main	可能丢弃本地修改，并让读者看到更新一半的目录	独立构建不可变 release，通过链接切换激活
递归修改整个目录所有权	可能误改凭据、上传内容或其他业务文件	事先限定需要写入的目录和账户
禁用 TLS 证书验证	掩盖证书问题，失去服务器身份校验	检查域名、证书链、到期时间与网络，保持验证开启
订阅全部事件	无关请求也可能触发部署	仅订阅所需事件并校验仓库、事件类型、分支

原文“打开 SSL 后配置失败”的记录只说明当时验证没有通过，不能据此得出应关闭验证的结论。

一个可审查的接收与发布过程

接收端应验证平台提供的签名，并对原始请求体计算校验值；不要只相信一个可转发、可被日志记录的 URL 参数。请求中的分支名和其他字段不能直接拼成 shell 命令。验证成功后将任务放入队列，尽快响应 HTTP；再由受限应用账户处理部署。

发布任务记录事件标识和明确提交，重复事件应能识别；构建测试成功后激活对应产物，健康检查失败时恢复旧版。与在线编辑器共享工作区时，还应先阻止新写入并排空正在保存的操作，而不是重启时强行中断。

参见 GitHub Webhook 最佳实践 与 验证 Webhook 请求。具备上述验证逻辑才可视为可靠发布；在插件中点击“测试”成功，只证明某次请求到达。