无法匹配GitHub Webhook SHA256签名，找不到正确的Payload计算格式

• 所有计算偏差的根源，是参与哈希运算的原始文本选择错误。GitHub计算签名的基准既不是Webhook设置页展示的带缩进美化的预览JSON，也不是你把JSON解析成结构化对象后重新拼接生成的序列化字符串，而是GitHub发送POST请求时，HTTP请求体携带的未经任何加工的原始字节流。
• 网页上看到的带换行、缩进、空行的格式化JSON，是前端为了方便阅读自动渲染的效果，这些内容根本不存在于真实发送的请求体里，哪怕多一个空格、少一个换行，最终哈希值都会完全不同。

你已经验证过基础哈希计算逻辑在简单测试字符串上结果准确，说明算法实现本身没有问题，偏差完全来自输入文本的格式差异。

• 使用计算工具时粘贴的是预览界面的格式化JSON：这类内容携带了大量前端添加的可读性空白，和真实请求体的字节序列完全不一致。
• 接收到请求后先把body解析成JSON对象，再通过JSON.stringify、json.dumps等方法重新生成字符串参与计算：这类序列化操作可能会调整字段顺序、添加默认空格、改变特殊字符的转义规则，最终生成的字符串和GitHub发送的原始内容存在细微差异。
• 混淆了普通SHA256哈希和HMAC-SHA256计算逻辑：GitHub的签名不是单纯对内容做SHA256哈希，而是以你配置的Webhook专属密钥作为HMAC的计算密钥，对原始请求体内容做HMAC-SHA256运算，最终把十六进制结果加上sha256=前缀后写入请求头。

• 接收到GitHub的POST请求时，第一时间从原始请求流读取完整body内容，存储为原始字符串，在完成签名校验之前不要对这个字符串做任何JSON解析、格式调整、内容修改。
• 以Webhook密钥为HMAC密钥，以原始body字符串为计算消息，执行HMAC-SHA256运算，将结果转换为小写十六进制字符串。
• 将计算结果和请求头中X-Hub-Signature-256字段去掉sha256=前缀的内容做常量时间字符串比对，完成校验。

复现提示：你可以把当前案例里展示的格式化JSON，手动删掉所有缩进、换行、多余空格，压缩成无冗余内容的紧凑单行JSON，再用配置的密钥1234567890计算HMAC-SHA256，就能得到和请求头中完全匹配的签名值。

内容的提问来源于stack exchange，提问作者Frankie