解密逻辑必须手动注入handler，框架不自动做：go无内置参数解密机制，需在http.handler或中间件中显式处理query（用rawquery提取未decode密文）和body（只读一次body后解密），并校验utf-8与填充。
解密逻辑必须手动注入 handler，框架不自动做
Go 没有内置参数解密机制，http.ServeMux、gin、echo 等框架都不会帮你解密。所有解密动作必须显式写在 http.Handler 或中间件里——从哪读、用什么算法、校验哪些项，全由你控制。
常见错误是以为“框架解析完参数我就直接能用”，结果发现 r.URL.Query().Get("data") 返回乱码或空值。这是因为前端加密后的 base64 字符串（如 SGVsbG8%3D）含 URL 编码字符，而 URL.Query() 已提前做了 decode，破坏了原始密文字节。
- 正确做法：用
r.URL.RawQuery拿到完整 query 字符串，再用url.ParseQuery手动解析，保留%3D等编码 - POST 场景下，绝不能先调
r.ParseForm()，否则r.Body被读空，后续io.ReadAll(r.Body)返回nil或io.EOF - 解密入口统一放在中间件里，但注意：中间件也得遵循“只读一次 body”原则
query 和 body 解密路径必须分开处理
query 参数和 POST body 的解密起点不同，混用会出错。前者来自 URL 字符串，后者来自请求体流，二者生命周期和读取方式完全隔离。
比如微信小程序的 encryptedData 通常走 POST body，而某些风控接口把密文塞在 query 里（如 ?payload=xxx）。你不能用同一套逻辑去处理它们。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- query 解密：提取
r.URL.RawQuery→ 找到目标 key 对应的 raw value（未 decode）→base64.StdEncoding.DecodeString()→ AES-CBC/GCM 解密 - body 解密：先
body, err := io.ReadAll(r.Body)→ 解密得到明文字节 → 再用json.Unmarshal(body, &v)或url.ParseQuery(string(decrypted))解析结构 - 别在解密前调
r.FormValue()或r.PostFormValue()，它们内部会触发ParseForm()，导致 body 不可重复读
解密后必须校验 UTF-8 和填充，否则 panic 风险高
AES-CBC 等模式依赖 PKCS#7 填充，解密失败时返回的可能是随机字节；若直接转成 string 传给 json.Unmarshal，遇到非法 UTF-8 会直接 panic。
这不是“偶尔出错”，而是稳定复现的问题——尤其当密钥错、IV 错、密文被篡改或截断时。
- 解密后先用
utf8.Valid(decryptedBytes)检查有效性 - 对 CBC 模式，需手动剥离 PKCS#7 填充：取最后一个字节值
n，检查末尾n字节是否都等于n，再截断 - GCM 模式虽自带认证标签，但也要检查
gcm.Open()返回的 error，不能忽略 - 建议封装一个
safeUnmarshalJSON函数：先校验 UTF-8，再json.Unmarshal，错误时返回明确提示而非 panic
密钥和 IV 管理不能硬编码，KMS 或环境变量优先
生产环境里，把密钥写死在代码里或配置文件中是严重安全隐患。哪怕用 AES-GCM，密钥泄露也意味着所有历史密文可被批量解密。
Go 标准库本身不提供密钥存储服务，你需要自己对接外部方案。
- 优先使用云厂商 KMS（如 AWS KMS、阿里云 KMS），通过 IAM 角色获取解密权限，密钥永不落地
- 次选方案：密钥存于环境变量（
os.Getenv("AES_KEY")），启动时注入，避免进 Git - IV 必须每次加密时随机生成（用
crypto/rand.Read），且随密文一起传输；绝不能复用 IV，否则 CBC/GCM 安全性崩塌 - 如果用 PBKDF2 衍生密钥，盐值（salt）必须随密文存储，且每次加密用新 salt
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
