webhook接收端需按平台校验签名：github用x-hub-signature-256与hmac-sha256比对，gitlab直接比对x-gitlab-token；部署须用绝对路径、设超时、禁拼接输入；本地测试推荐smee.io；go适合做原子部署操作而非替代ci。
Webhook 接收端怎么写才不会被 GitHub / GitLab 拒绝
Go 服务收到 400 Bad Request 或直接超时，大概率是没按平台要求校验签名。GitHub 发请求带 X-Hub-Signature-256，GitLab 用 X-Gitlab-Token，二者完全不兼容，不能混用一套逻辑。
- GitHub：用
hmac.NewSHA256算出签名，和 header 中的X-Hub-Signature-256（去掉sha256=前缀）比对，注意必须用bytes.Equal防时序攻击 - GitLab：直接比对
X-Gitlab-Token和你配置的 token 字符串，大小写敏感，别 trim 空格 - 所有 Webhook 路由必须支持
POST，且Content-Type是application/json；如果用了中间件自动 decode body，记得在签名校验前读一次原始io.ReadCloser，否则 body 流已关闭
收到推送后怎么安全触发部署命令
直接 exec.Command("git", "pull") 是高危操作：工作目录不确定、权限不对、没有超时控制，容易卡死进程或污染环境。
- 用绝对路径指定项目目录，比如
/var/www/myapp，不要依赖os.Getwd() - 部署命令必须设
cmd.Dir、cmd.Env（至少保留PATH），并加cmd.WaitDelay = 30 * time.Second - 禁止拼接用户输入（如 branch 名）进 shell 命令；分支名从 payload 解析后，只允许匹配
^[a-zA-Z0-9._-]+$再使用 - 建议把部署逻辑封装成独立二进制（如
deployer），Webhook 服务只负责调用它，降低主进程风险
为什么本地测试 Webhook 总是失败
本地没公网地址，GitHub/GitLab 发不出请求；但更隐蔽的问题是：用 curl -X POST 手动模拟时，忘了设 -H "Content-Type: application/json" 或签名头，导致 Go 服务解析失败或跳过校验。
- GitHub 官方推荐用
smee.io转发 webhook 到localhost:8080，比 ngrok 更轻量 - GitLab 自带 “Test” 按钮，但只发一次，且 payload 是简化版；真要测完整流程，得用
git push触发真实事件 - 本地调试时，在 handler 开头加一行
log.Printf("raw body: %s", string(body))，确认收到的是合法 JSON，而不是空字符串或 HTML 错误页
CI/CD 流水线里该不该用 Go 写部署脚本
可以，但别把它当 CI 工具用。Go 编译快、二进制无依赖，适合做“最后一步”的原子操作（比如 reload systemd 服务、切换 symlink），不适合替代 .gitlab-ci.yml 或 GitHub Actions 的多阶段构建。
立即学习“go语言免费学习笔记（深入）”；
- CI 阶段该做的事：单元测试、构建二进制、推镜像——这些用现成 CI runner 更稳
- Webhook 阶段该做的事：拉代码、校验 checksum、重启服务——用 Go 写更可控，也方便加日志和告警
- 别让 Go 程序自己去
git clone整个仓库；部署机上应预置好 bare repo，只做git --work-tree=/path pull
真正麻烦的是权限和上下文切换：systemd 服务默认没权限写 web 目录，用 sudo 又引入配置复杂度。最简方案是让部署程序以专用系统用户运行，并用 setgid 组保证文件写入权限一致。
