需用原始请求体字节计算HMAC-SHA256并与X-Hub-Signature-256头校验：先提取sha256=后hex解码，密钥为原始secret字节，读一次body存为[]byte后分别用于验签和JSON解析。
Go Webhook接收器怎么验证GitHub的HMAC签名
GitHub发来的Webhook请求必须校验X-Hub-Signature-256头，否则可能被伪造。Go标准库没直接封装这个逻辑，得自己算HMAC-SHA256再比对。
关键点是：GitHub用sha256算法 + 你配置在仓库里的secret（字符串）对原始payload字节做HMAC，不是对JSON解析后的结构，也不是对字符串化后的空格/换行敏感版本——必须用http.Request.Body原始字节流。
- 别用
json.Unmarshal后再json.Marshal去重算，会因字段顺序、空格、浮点数精度丢失导致签名不匹配 - 别用
io.ReadAll(r.Body)后又想重复读r.Body——HTTP Body是单次读取流，后续json.Decode会失败 - 推荐先
io.ReadAll一次，存成[]byte，再分别用于签名验证和JSON解析
为什么hmac.New和crypto/hmac验证总失败
常见错误是密钥处理不对：GitHub后台填的secret是纯字符串，比如my-webhook-secret，但有人误当成base64或hex解码后再传给hmac.New。它要的是原始[]byte，直接[]byte("my-webhook-secret")就行。
另一个坑是签名头格式：GitHub发的是sha256=abcdef123...，得先按=切开，取第二段，再用hex.DecodeString转成字节；不能直接拿整个字符串比对，也不能漏掉sha256=前缀校验（防止攻击者伪造sha1=等弱算法）。
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 检查
r.Header.Get("X-Hub-Signature-256")是否为空，GitHub只在有secret时才发这个头 - 用
strings.HasPrefix(sig, "sha256=")确认算法，再strings.TrimPrefix(sig, "sha256=") -
hex.DecodeString失败要返回400，不是忽略——非法签名格式本身就是异常请求
Go里怎么安全读两次Body（验签+解析JSON）
HTTP Body不能反复读，但验签和JSON解析都需要完整payload。最轻量做法是读一次到内存：body, err := io.ReadAll(r.Body)，然后用bytes.NewReader(body)构造两个新Reader分别给验签和json.NewDecoder用。
注意别用strings.NewReader(string(body))——UTF-8非ASCII字符（比如中文、emoji）会被破坏；也别用bytes.Buffer额外封装，徒增分配。
- 如果payload可能很大（>1MB），得加长度限制，避免OOM：
http.MaxBytesReader(nil, r.Body, 5 - 验签前确保
Content-Type: application/json，GitHub Webhook固定这个类型，其他类型直接拒收 - 别在验签前调用
r.ParseForm()或r.FormValue()——它们会偷偷消费Body
实际部署时net/http服务要注意什么
默认http.Server没有超时控制，恶意客户端可能发超长payload或慢速攻击拖垮服务。Webhook本质是短时、高可靠性的回调，必须设硬性超时。
GitHub文档写明：收到请求后10秒内没响应，它会重试（最多3次）。所以你的Handler必须在10秒内完成验签、业务逻辑、返回2xx。别让它卡在外部API调用上。
- 用
context.WithTimeout(r.Context(), 8*time.Second)包住所有下游操作，留2秒缓冲 - 别用
log.Fatal或panic——会导致整个HTTP服务器崩溃，要用http.Error返回400/401/500 - 签名失败统一返回
http.StatusUnauthorized（401），别暴露“密钥错”还是“格式错”，防侧信道
验签逻辑看着简单，但Body读取顺序、编码一致性、上下文超时这三处，线上最容易出 silent failure —— 请求没了，日志也没报错，只发现GitHub重试队列在涨。
