gin本身不内置rsa加解密能力，必须自己封装或引入第三方库；用rsa直接加密http请求体是典型误用，性能差且有长度限制，正确做法是「rsa加密aes密钥 + aes加密业务数据」的混合模式。
直接说结论：Gin本身不内置RSA加解密能力，必须自己封装或引入第三方库；用RSA直接加密HTTP请求体是典型误用，性能差且有长度限制，正确做法是「RSA加密AES密钥 + AES加密业务数据」的混合模式。
为什么不能直接用rsa.EncryptPKCS1v15加密整个请求体
RSA加密对明文长度有严格限制（比如2048位密钥最多加密245字节），而实际API请求体动辄几KB。强行调用会触发crypto/rsa: message too long错误，且每次加密耗时是AES的百倍以上，高并发下CPU迅速打满。
- 前端若用JavaScript的
jsrsasign或Web Crypto API，也受限于importKey后只能加密短数据 - 后端用
rsa.DecryptPKCS1v15解密长数据会panic，不是返回错误而是直接崩溃 - Gin中间件里做全量RSA解密，等于把每个请求都变成CPU密集型任务，吞吐量断崖下跌
如何在Gin中安全集成RSA+AES混合加密
核心思路是把RSA当作“钥匙配送员”，只用来加密随机生成的AES密钥；真正的业务数据由AES加密后传输。Gin层只需负责解析、验证、解密密钥，再交由AES服务处理。
- 前端生成随机AES密钥（如
AES-256-GCM），用服务端提供的public_key.pem加密该密钥，得到encrypted_aes_key - 用该AES密钥加密原始请求体，得到
ciphertext，连同iv、auth_tag（GCM必需）一并放入请求头或JSON body - Gin中间件提取
encrypted_aes_key，用private_key.pem解密出原始AES密钥 - 调用AES解密函数还原请求体，再交给后续Handler处理
- 务必校验
auth_tag，防止密文被篡改（GCM模式下缺失校验等于裸奔）
gin.HandlerFunc里实现RSA密钥解密的常见坑
很多人直接在中间件里读取private_key.pem文件并反复调用rsa.DecryptPKCS1v15，这会导致两个问题：文件I/O阻塞、私钥未缓存引发性能抖动。
- 私钥必须预加载进内存：
privateKey, _ := ioutil.ReadFile("private_key.pem")放在init()或main()里，避免每次请求都读磁盘 - 解密前必须校验密文长度是否匹配密钥位数，否则
rsa.DecryptPKCS1v15会返回crypto/rsa: decryption error而非具体原因 - 不要用
PKCS1v15填充——它已被证明存在Bleichenbacher攻击风险；生产环境强制用OAEPSHA256（即rsa.DecryptOAEP） - Gin的
c.Request.Body是单次读取流，解密密钥后需用io.MultiReader把body重置，否则后续绑定JSON会失败
前端JS和Gin后端的密钥格式兼容要点
Go的crypto/rsa默认读取PEM格式，但前端常用Base64编码的DER或JWK格式公钥，直接传过去会解密失败。
- 服务端分发公钥时，必须提供标准PEM格式（以
-----BEGIN PUBLIC KEY-----开头），而非-----BEGIN RSA PUBLIC KEY-----（旧格式，Go不认） - 前端若用
Web Crypto API，导入公钥时format参数必须为"spki"，不是"jwk"或"pkcs8" - Go侧解析私钥时，若用
ParsePKCS1PrivateKey只能读老式RSA私钥；新生成的PEM私钥（含-----BEGIN PRIVATE KEY-----）必须用ParsePKCS8PrivateKey - 密钥长度建议统一为2048位以上，1024位在2026年已不满足PCI DSS等合规要求
最易被忽略的是密钥生命周期管理：RSA密钥对绝不能长期复用，尤其私钥一旦泄露，所有历史加密流量都可被回溯解密。生产环境必须建立密钥轮换机制，比如每90天自动生成新密钥对，并保留旧私钥用于解密存量请求，同时前端需支持动态拉取最新公钥。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
