sm2签名验签不一定必须在gin中间件里做，但强烈建议放在中间件，以便统一拦截验签失败请求并返回标准错误码（如401），同时校验timestamp防重放、重置request.body避免读取为空，并规范处理sm2/sm3/sm4数据格式与密钥管理细节。
政务系统对接国密算法，Gin 本身不参与加解密，真正要动的是你处理请求/响应的中间件和业务逻辑层。直接在 Gin 路由里调用 gmsm 就能跑通，但生产环境里最容易翻车的地方不是算法调用，而是密钥管理、签名验签顺序、以及 SM2/SM3/SM4 混用时的数据格式错位。
SM2 签名验签必须在 Gin 中间件里做吗？
不一定，但强烈建议放在中间件。因为政务接口通常要求所有请求携带 sign、timestamp、nonce 等字段，验签失败必须统一拦截并返回标准错误码（比如 401 Unauthorized），而不是让请求进到业务 handler 再报错。
- 验签前必须先校验
timestamp是否在允许窗口内（如 ±5 分钟），否则直接拒绝，防止重放攻击 -
sign字段通常是 base64 编码的 ASN.1 格式签名，要用x509.ParseSm2PublicKey解析公钥，不能直接用sm2.PublicKey的裸结构体 - Gin 的
c.Request.Body是单次读取流，验签时如果用了ioutil.ReadAll，后续业务逻辑再读就会得到空内容——得用c.Request.Body = io.NopCloser(bytes.NewBuffer(bodyBytes))重置
SM4 加密响应体时，ECB 模式到底能不能用？
能用，但只限于极小、固定长度的字段（比如一个 16 字节的交易流水号），且必须确认上下游系统明确约定使用 ECB+PKCS5。政务系统里绝大多数场景应该用 CBC 或 GCM 模式，ECB 因为相同明文块加密后密文完全一致，会暴露数据模式。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
gmsm/sm4默认不提供 ECB 模式封装，得自己套crypto/cipher.BlockMode，而sm4.NewCipher返回的是cipher.Block，不是BlockMode - 如果你硬要用 ECB，填充必须手动实现 PKCS5（不是 PKCS7）：补字节数 =
16 - len(data)%16，每个填充字节值等于补字节数 - CBC 模式需要 IV，IV 必须随密文一起传输（比如拼在密文前 16 字节），且每次加密必须用新 IV；GCM 模式则需额外处理认证标签（
Tag）
SM3 哈希计算怎么避免被绕过？
常见错误是只对原始 JSON 字符串哈希，但不同语言序列化 JSON 的空格、字段顺序、浮点数精度可能不同，导致哈希不一致。政务系统对接常因这个细节联调失败。
- 不要直接
json.Marshal后哈希，先用json.Compact去掉空格和换行 - 确保 key 按字典序排序（
map本身无序，得转成[]string手动排序后再拼接） - 时间字段统一用 RFC3339 格式（
"2006-01-02T15:04:05Z"），避免本地时区差异 - SM3 输出是 32 字节二进制，对外传输务必用 hex 或 base64 编码，别直接当字符串传
最麻烦的其实是密钥轮换和证书链验证——gmsm 支持 x509 模块解析 SM2 证书，但政务 CA 颁发的证书常带私有扩展字段，x509.ParseCertificate 会忽略它们，而业务逻辑可能依赖这些字段做权限控制。这时候得用 asn1.Unmarshal 手动解析原始 TBSCertificate 结构。这不是算法问题，但卡住联调的往往是这种“非标准”细节。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
