gin后端需用crypto/rsa手动解密：前端用pkcs#1 v1.5填充+base64编码传输密文，gin接收后base64解码再调用rsa.decryptpkcs1v15；私钥须pem格式、正确解析为*rsa.privatekey，且长度匹配（如2048位密钥对应256字节密文）。
前端用 RSA 公钥加密，Gin 后端怎么解密？
Gin 本身不提供 RSA 解密能力，必须手动用 crypto/rsa 包处理。关键不是“Gin 怎么解”，而是“你传来的密文是否符合 Go 的 rsa.DecryptPKCS1v15 要求”。常见失败原因是前端加密时用了错误填充或编码格式。
- 前端必须使用 PKCS#1 v1.5 填充（不是 OAEP），且密文需是原始二进制 → Base64 编码后传输
- Gin 接收后先
base64.StdEncoding.DecodeString还原为字节，再调用rsa.DecryptPKCS1v15 - 私钥必须是 PEM 格式、且已正确解析为
*rsa.PrivateKey；如果用的是 PKCS#8 格式私钥，得先用x509.ParsePKCS8PrivateKey - Go 的
rsa.DecryptPKCS1v15对密文长度有硬性限制：不能超过len(privateKey.PublicKey.N) - 11字节（比如 2048 位密钥最多解密 245 字节明文）
公钥给前端，但 Gin 如何安全加载私钥？
别把私钥硬编码在代码里，也别放 Git 仓库。Gin 应用启动时应从环境变量或文件系统读取，且文件权限必须设为 0600（仅 owner 可读写）。
- 推荐路径：
/etc/secrets/app.rsa.key，启动前由运维或 KubernetesSecret挂载 - 加载时用
ioutil.ReadFile（Go 1.16+ 改用os.ReadFile）读取文件内容，再用pem.Decode提取 block，最后x509.ParsePKCS1PrivateKey解析 - 如果私钥受密码保护（encrypted PEM），需额外调用
x509.DecryptPEMBlock，密码必须来自环境变量，不可写死 - 解析失败时直接 panic 或 log.Fatal，不要返回模糊错误 —— 私钥加载失败意味着服务无法启动，不该尝试降级运行
为什么前端加密后，Gin 解密总报 crypto/rsa: decryption error？
这不是密钥配对问题，绝大多数情况是数据损坏或格式错位。RSA 解密失败几乎从不因为“公私钥不匹配”，而是输入不符合预期。
- 检查前端是否把 Base64 解码后的字节数组直接当字符串传了（比如 JSON 中误传为 string 而非 base64 字符串）
- 确认前端加密时用的公钥和后端解密用的私钥确实是同一对 —— 可用
openssl rsa -pubin -text -noout -in pubkey.pem和openssl rsa -text -noout -in privkey.pem对比模数Modulus - Go 的
rsa.DecryptPKCS1v15要求密文长度严格等于len(privateKey.PublicKey.N)字节（如 2048 位 → 256 字节），少一个字节都会失败 - 别在解密前对密文做任何 trim、replace 或 UTF-8 转换 —— RSA 密文是纯二进制，不是文本
要不要在 Gin 里加 RSA 中间件统一处理加解密？
不要。RSA 是计算密集型操作，不适合放在中间件里无差别执行。它只该用于特定接口（如登录凭证、支付参数），且必须配合限流和超时控制。
- 加解密逻辑应集中在具体 handler 内，便于按需选择算法（比如小数据用 PKCS#1，大数据用混合加密）
- 若真要复用，封装成独立函数（如
DecryptRSA(c *gin.Context, field string) ([]byte, error)），而不是中间件 - 注意：RSA 解密会阻塞 Goroutine，高并发下可能拖慢整个服务；2048 位密钥单次解密约耗时 0.1–0.3ms，但 100 QPS 就吃掉一个 CPU 核心的 10%+
- 真正需要频繁加解密的场景，应该改用 AES 对称加密 + RSA 加密 AES key 的混合模式
RSA 公钥加密通信中最容易被忽略的，是前端和后端对“密文边界”的理解差异：前端认为 Base64 就是最终传输格式，后端却默认它已被正确还原为原始字节 —— 中间任意环节的编码转换（比如 JSON 序列化/反序列化、HTTP body 解析、日志打印）都可能悄悄破坏密文完整性。
