gin需在handler中手动解密rsa密文：先用c.getrawdata()获取原始字节，base64解码后调用rsa.decryptpkcs1v15（或decryptoaep）解密，再json.unmarshal；私钥须启动时加载并校验，避免硬编码与格式错误。
怎么让Gin接收前端RSA加密的请求体
Gin本身不处理RSA加解密，它只负责HTTP层收发。你得自己在路由 handler 里手动解密请求体——不能依赖 ShouldBindJSON 直接解析，因为前端传来的不是原始 JSON，而是用RSA公钥加密过的 Base64 字符串。
常见错误现象：json: cannot unmarshal string into Go value of type map[string]interface{}，这是因为你试图把一串密文当 JSON 解析了。
- 先用
c.GetRawData()拿到原始字节流（别用c.Request.Body，它只能读一次） - Base64 解码后，用私钥调用
rsa.DecryptPKCS1v15解密（注意：必须和前端加密时用的填充方式一致，通常是PKCS1v15或OAEPSHA256） - 解密结果是 UTF-8 字节数组，再用
json.Unmarshal解析成结构体 - 务必检查解密失败的 error，比如
crypto/rsa: decryption failed，这通常意味着前后端密钥不匹配或填充方式不对
Gin里怎么安全加载RSA私钥文件
别把私钥硬编码进代码，也别用 os.ReadFile 每次都读——既不安全又低效。推荐在应用启动时一次性加载并缓存到内存里，且确保私钥文件权限为 0600（仅属主可读写）。
容易踩的坑：panic: x509: failed to parse private key，大多是因为私钥格式不对。OpenSSL 默认生成的是 PKCS#1 格式（以 -----BEGIN RSA PRIVATE KEY----- 开头），而 Go 的 x509.ParsePKCS1PrivateKey 只认这个；如果用 openssl pkcs8 -topk8 转成了 PKCS#8（-----BEGIN PRIVATE KEY-----），就得换用 x509.ParsePKCS8PrivateKey。
- 用
ioutil.ReadFile（Go 1.16+ 改用os.ReadFile）读取私钥文件 - 用
pem.Decode提取 block，再根据 header 判断是 PKCS#1 还是 PKCS#8 - 私钥加载后立即校验：用它签名一段测试数据，再用对应公钥验证，确保没加载错
如何避免Gin中RSA解密的性能瓶颈
RSA 解密比对称加密慢两个数量级以上，尤其在高并发场景下，每请求都解密会成为明显瓶颈。不能把它放在每次请求的 handler 里重复初始化 cipher 实例。
关键点在于复用和隔离：解密操作本身无法并行加速，但你可以把私钥和 cipher 初始化提到全局或单例里，避免每次调用都重新解析 PEM、生成 *rsa.PrivateKey 对象。
- 把
*rsa.PrivateKey存为包级变量或注入到 handler 闭包中，不要在 handler 内部重复x509.Parse... - 不要在解密前做耗时操作（如查数据库、远程调用），否则会放大阻塞时间
- 如果业务允许，考虑改用混合加密：前端用 RSA 加密一个随机 AES 密钥，再用该 AES 密钥加密实际数据，Gin 只需解 RSA 部分，再用缓存的 AES cipher 解主体——这样能显著提升吞吐量
前端传来的RSA密文为什么Gin总解不开
90% 的问题出在两端参数不一致，而不是代码逻辑错。RSA 看似简单，但公私钥格式、填充方案、编码方式、字节序任何一个环节对不上，都会静默失败。
最常被忽略的细节：前端加密时用了 TextEncoder.encode('utf-8')，而 Go 解密后直接当字符串打印，却忘了 Go 的 string 类型默认是 UTF-8 编码——但如果前端加密的是含 BOM 的文本、或用了不同编码（如 GBK），解密后字节流就乱了。
- 统一约定：前端加密前先
JSON.stringify原始对象，再转成 UTF-8 字节数组；Gin 解密后直接json.Unmarshal，跳过中间字符串转换 - 调试时，在解密前后分别打印字节长度：
len(cipherText)和len(plainBytes)，RSA-2048 解密后明文最大长度是 245 字节（PKCS#1v15），超长会直接报错 - 前端若用 Web Crypto API，确认
encrypt传的是{name: 'RSA-OAEP', hash: 'SHA-256'}，后端就得用rsa.DecryptOAEP配合sha256.New()，不能混用PKCS1v15
真正卡住人的地方，往往不是“怎么写”，而是“两端谁在悄悄改默认值”——比如 OpenSSL 生成私钥时默认用 PKCS#1，但某些前端库导出公钥时自动转成 PKCS#8；又比如 Node.js 的 crypto 模块默认 padding 是 pkcs1_oaep，而浏览器 Web Crypto 默认是 RSA-OAEP 但 hash 是 SHA-1，不显式指定就会和 Go 对不上。这些细节不打日志、不抓原始字节，根本没法定位。
