必须放在业务 handler 里，因 multipart 请求调用 parsemultipartform 后会消费请求体，导致后续无法读取原始字节验签；需在 handler 开头用 io.readall 一次性读取并重置 r.body。
签名校验该放在 HTTP 中间件还是业务 handler 里
必须放在业务 handler 里，不能依赖中间件统一拦截。因为文件上传请求（multipart/form-data）一旦调用 r.ParseMultipartForm() 或 r.FormValue()，底层会自动读取并消费请求体，后续再想读取原始字节做签名验证就失败了——http: request body is empty 或校验值不一致是常见现象。
实操建议：
- 在 handler 开头立即用
io.ReadAll(r.Body)一次性读取原始请求体，保存为[]byte - 用
bytes.NewReader(bodyBytes)构造新io.ReadCloser，赋给r.Body，再调用r.ParseMultipartForm() - 从
r.MultipartForm中提取file字段和signature字段（或其他约定字段名） - 签名原文 =
bodyBytes（不含边界符）或按协议约定剔除 multipart 头部（见下一条）
如何从 multipart 请求体中安全提取原始 payload 做签名
multipart 请求体含 boundary 分隔符和字段头（如 Content-Disposition: form-data; name="file"; filename="a.txt"），这些不是业务数据，不应参与签名。但 Go 标准库不提供“裸 payload”提取接口，需手动剥离。
实操建议：
- 签名原文应为：所有非文件字段的
key=value拼接（按字母序排序），加上文件字段的name和filename（不含文件内容）——这是常见服务端约定，避免因文件内容过大或流式上传导致签名不可靠 - 若协议强制要求对整个
bodyBytes签名，则必须确保客户端生成签名时使用的 boundary 与服务端收到的一致（boundary 是随机生成的，不可预测）；此时客户端需显式传入固定 boundary 或使用application/octet-stream替代 multipart - 更稳妥做法：让客户端把签名所需字段（如
timestamp、file_hash、file_size）放在 URL query 或 header 中，body 只传文件，签名基于这些元数据计算
Go 中常用签名算法的实现要点（HMAC-SHA256 为例）
别直接拼接字符串后算 hmac.Sum(nil)，容易因空格、换行、编码不一致导致验签失败。
实操建议：
- 签名密钥用
[]byte存储，避免从字符串隐式转换（尤其含非 ASCII 字符时） - 签名原文先做标准化：去除首尾空白、统一换行符为
\n、URL decode 所有字段值（如果字段来自 form） - 使用
hmac.New(sha256.New, secretKey)，写入原文后调用sum := hmac.Sum(nil)，取sum[:]得到字节数组，再hex.EncodeToString()或base64.StdEncoding.EncodeToString()输出——必须和服务端约定一致 - 注意：Go 的
crypto/hmac不自动处理 key 长度，若len(secretKey) > blocksize（SHA256 是 64），需先 hash 再作为实际 key
测试时绕过 multipart 解析直接构造请求体
单元测试签名校验逻辑时，不要依赖真实文件上传流程。否则每次都要构造 multipart.Writer，耦合重、易出错。
实操建议：
- 用
bytes.Buffer+multipart.Writer构造合法 body，但只保留buf.Bytes()用于测试 - 手写一段符合 multipart 格式的 raw body（含固定 boundary），用
strings.NewReader()包装后传给httptest.NewRequest("POST", ...) - 在 test 中 mock 掉文件存储逻辑，专注验证
verifySignature(bodyBytes, formValues, secret)函数返回是否正确 - 特别加一个 case：把 signature 字段故意改错一位，确认返回
401 Unauthorized而不是 panic 或 500
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
