beego 中必须手动解密，框架不提供自动解密钩子；需显式读原始字节→解密→校验utf-8与pkcs#7填充→反序列化，且密钥iv须环境变量或kms加载、禁用parseform()、区分请求类型读密文。
Beego 中必须手动解密，框架不提供自动解密钩子
Beego 没有类似 Spring Boot 的 @RequestBodyAdvice 或 Express 的 body-parser 插件机制来统一拦截并解密请求体。所有 AES 解密逻辑必须由你显式写在 controller 或中间件里——不是“配置一下就行”，而是“读原始字节 → 解密 → 校验 → 反序列化”四步全手动控制。
从哪里读加密数据：别碰 ParseForm() 和 URL.Query()
常见错误是先调 r.ParseForm() 或用 c.GetString("encrypted")，结果 r.Body 已被读空，后续 io.ReadAll(r.Body) 返回空 slice 或 io.EOF。正确路径取决于请求类型：
- JSON POST：
body, err := io.ReadAll(c.Ctx.Request.Body)一次性读取原始密文，绝不能调c.ParseForm() - GET 加密参数（如
?request=KXBUFIFtuVbqNtpLMe/yVg==）：r.URL.RawQuery拿完整 query 字符串，再手动提取request=xxx的 value（保留%3D等编码），最后base64.StdEncoding.DecodeString() - 表单 POST（
application/x-www-form-urlencoded）：同样禁用ParseForm()，改用io.ReadAll(r.Body)读原始 body，再用url.ParseQuery(string(decrypted))解析明文表单
AES 解密后必须校验 UTF-8 和 PKCS#7 填充
解密失败时，AES-CBC 可能返回乱码字节；若直接转成 string 传给 json.Unmarshal()，遇到非法 UTF-8 会 panic。两层防护不可少：
- 用
utf8.Valid(decryptedBytes)快速检查是否为合法 UTF-8 字符串 - 对 CBC 模式，手动验证末尾填充字节：若末字节为
0x05，则倒数 5 字节都应为0x05；否则说明密钥/IV 错或密文被篡改 - GCM 模式虽自带 AEAD 校验，但
cipher.NewGCM().Open()会直接返回 error，必须检查 err 是否为 nil
密钥和 IV 绝不能硬编码，且要区分环境加载
看到 var key = []byte("thisisasecret1234") 就该立刻删掉——这种写法会让密钥出现在 Git 历史、日志输出甚至内存 dump 中。实际做法：
- 密钥走环境变量或 KMS（如 AWS KMS / 阿里云 KMS），启动时解密加载
- IV 必须每次请求随机生成（前端传入），服务端不复用；若前端没传，后端应拒绝请求，而不是 fallback 到固定 IV
- 证书类密钥文件（如 RSA 私钥）不要放
static/下，建议放在conf/certs/并设权限600
最易被忽略的是：解密后的明文 JSON，仍需走标准 json.Unmarshal(body, &req) 流程，而非直接赋值给结构体字段。跳过这步会导致嵌套字段、类型转换、omitempty 等行为全部失效。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
