Go语言无内置请求参数解密机制，须在handler或中间件中手动处理：从RawQuery或ReadAll(Body)获取原始密文，base64解码后用crypto/aes+CBC/GCM解密，校验PKCS7填充与UTF-8有效性，并通过KMS安全管理密钥。
Go 语言没有自动解密请求参数的机制，所有解密逻辑必须由你手动在 http.Handler 或中间件里完成——不是框架帮你做，而是你决定从哪读、怎么解、校验什么。
从 RawQuery 读加密 query 参数，别碰 URL.Query()
前端如果把整个参数值（比如 ?data=SGVsbG8=）用 base64 + AES 加密过，你就不能用 r.URL.Query().Get("data")，因为 Go 已经对 value 做了 URL decode，而加密前的原始字节很可能含非法 URL 字符，二次 decode 会破坏密文。
正确做法是：
- 用
r.URL.RawQuery拿到完整原始 query 字符串（如data=SGVsbG8%3D） - 手动解析 key-value，提取
data对应的 raw value（注意保留%3D这类编码，不要提前 decode） - 再用
base64.StdEncoding.DecodeString()解码，得到密文字节 - 最后用
crypto/aes+crypto/cipher解密
POST body 加密时，只读一次 r.Body，别调 ParseForm 或 json.Decode
常见错误：先调 r.ParseForm()，再想从 r.PostFormValue("encrypted") 取值——这会直接读空 r.Body，后续 io.ReadAll(r.Body) 返回空 slice 或 io.EOF。
立即学习“go语言免费学习笔记（深入）”；
必须严格按顺序操作：
- 用
body, err := io.ReadAll(r.Body)一次性读完原始字节 - 解密后得到明文 JSON 字节，再用
json.Unmarshal(body, &v)解析结构体 - 或解密后是普通表单格式，用
url.ParseQuery(string(decrypted))手动解析 - 切勿再调
r.ParseForm()、r.FormValue()或任何会再次读r.Body的方法
解密后必须校验 UTF-8 和填充，否则 panic 风险高
AES-CBC 等模式依赖 PKCS#7 填充，解密失败时可能返回乱码字节；若直接转成 string 再传给 json.Unmarshal，遇到非法 UTF-8 会 panic。
建议加两层防护：
- 用
utf8.Valid(decryptedBytes)快速检查是否为合法 UTF-8 字符串 - 对 CBC 模式，手动验证末尾填充字节是否符合 PKCS#7 规则（如末字节为
0x05，则倒数 5 字节都应为0x05） - GCM 模式虽自带 AEAD 校验，但也要确保 nonce/IV 正确传递，否则
cipher.NewGCM().Open()直接返回 error
密钥千万别硬编码，优先走 KMS 或环境隔离加载
看到 var key = []byte("thisisasecret1234") 就该警觉——这种写法在 Git、日志、内存 dump 中极易泄露。
生产环境应：
- 用 KMS（如阿里云 KMS、AWS KMS）调用
Decrypt接口动态获取密钥，避免密钥落地 - 若用本地密钥文件，确保文件权限为
0600，且仅由运行用户可读 - 密钥长度必须匹配算法要求：AES-128 要 16 字节，AES-256 要 32 字节；少一字节都会导致
cipher.NewCipher()panic
最常被跳过的点：IV（初始化向量）必须和加密端完全一致，且不能复用；很多前端传参只带密文不带 IV，后端就得从固定位置（如密文前 16 字节）拆出来——这个约定一旦出错，解密永远失败，还很难定位。
