Go语言中基于哈希签名函数的API请求防篡改与完整性校验

签名验签失败？九成问题出在signingString上

签名验签失败主因是signingString不一致：必须严格按小写method、EscapedPath、秒级timestamp、nonce、字典序标准化query、body_hash六项顺序，用\n分隔，且密钥为[]byte、hmac.New传函数指针、验签用hmac.Equal并先解码。

说实话，签名验签失败这件事，90%都不是算法写错了——而是客户端和服务端拼出来的signingString根本对不上。字段顺序、编码方式、body的读取时机、时间戳单位，差一个字符就全盘皆输。下面把这几个最容易踩的坑掰开揉碎讲清楚。

signingString拼接必须严格按六项顺序，且用\n分隔

服务端还原签名原文时，必须和客户端保持一致：小写HTTP方法 + \n + r.URL.EscapedPath() + \n + 秒级X-Timestamp值 + \n + X-Nonce + \n + 标准化query字符串 + \n + body hash（如果存在）。顺序不能调换，末尾不加\n。

• r.URL.Path已经被自动decode了，必须用r.URL.EscapedPath()拿原始路径编码
• query要从r.URL.RawQuery解析，手动排序键名（字典序），每个value先url.PathEscape()再拼接；千万不要用url.Values.Encode()——它会加空格、打乱顺序、还会忽略重复key
• body hash必须基于原始字节：bodyBytes, _ := io.ReadAll(r.Body)，之后用bytes.NewReader(bodyBytes)重建r.Body；别在json.Unmarshal后拼字符串再算hash
• 所有字段间统一用\n分隔，不是&也不是空格；大小写全小写（比如post，不是POST）

hmac.New参数传错，轻则签名不变，重则panic

hmac.New的第一个参数必须是哈希构造函数（比如sha256.New），第二个参数必须是[]byte类型密钥。参数学错了，轻则签名恒定不变，重则编译失败甚至panic。

• ❌ 错误写法：hmac.New(sha256.New(), key) —— sha256.New()返回的是实例，不是函数指针
• ✅ 正确写法：hmac.New(sha256.New, key) —— sha256.New后面没有括号
• 密钥从环境变量加载后直接转[]byte：[]byte(os.Getenv("API_SECRET"))；如果密钥本身是base64编码的，必须先base64.StdEncoding.DecodeString()，别在运行时重复decode
• 每次签名都必须新建hmac.Hash实例，不能缓存复用——它非线程安全，高并发下会串值
• 算完必须调h.Sum(nil)拿结果，不能直接读h.Sum字段（那是内部缓冲区）

验签前必须做三重校验，只比对签名值等于没签

只验证X-Signature是否匹配？攻击者截包重放一次就能无限刷。必须同步校验时间戳、nonce和签名，三者缺一不可。

• 时间戳校验用abs(reqTime - time.Now().Unix()) > 300（±5分钟），两端都用UTC时间；别混用time.Now().Unix()和time.Now().In(loc).Unix()
• nonce必须用Redis SETEX 300去重，不能用内存map——多实例部署时内存map会失效；key可以设为api:nonce: + fmt.Sprintf("%d:%s", ts, nonce)
• 签名比对必须用hmac.Equal(sig1, sig2)，不是==或bytes.Equal——否则存在时序攻击风险；而且必须先hex.DecodeString()客户端签名，再与本地mac.Sum(nil)结果比对
• 如果hex.DecodeString失败（长度非64、含非法字符），直接返回401，不进入比对逻辑；解码失败和比对失败不要返回不同的状态码

body读取后必须重置r.Body，否则后续解析全挂

HTTP请求体是单次读取流。io.ReadAll(r.Body)读完后，r.Body就空了。后续调用json.Unmarshal或框架绑定（比如Gin的c.ShouldBindJSON）会得到EOF或空数据。

• 正确做法：读出原始字节 → 计算签名 → 用io.NopCloser(bytes.NewReader(bodyBytes))重建r.Body
• 必须在任何业务层解析前完成重置，顺序不能颠倒
• 如果body可能很大（超过1MB），应提前用http.MaxBytesReader包裹原始r.Body，防止内存耗尽
• 别用c.GetRawData()（Gin）：它只能调一次，而且调用后c.Request.Body就不可再用了

最后说一句，最容易被忽略的其实就三点：签名原文中query的编码方式、body的原始字节读取时机、nonce在多实例下的去重存储方式。这三点一旦出错，验签永远失败，但错误日志里看不出任何异常。从这入手排查，基本能解决九成以上的签名验签问题。