Go中在Gin接口使用RSA需避免裸调加解密函数，必须采用混合加密或限制字段加密，中间件中提前解密请求体、手动写入加密响应，并严格校验密钥格式（PKCS#1私钥/PUBLIC KEY公钥）、填充模式与长度限制，同时缓存密钥、验证有效性并规避CPU性能瓶颈。
Go 里怎么用 RSA 做 Gin 接口的非对称加解密
不能直接在 Gin 的 Handler 里裸调 rsa.EncryptPKCS1v15 或 rsa.DecryptPKCS1v15 —— 它们操作的是 []byte，而 HTTP 请求体是流式读取的，且长度受限（RSA 一次最多加密约 keySize/8 - 11 字节，2048 位密钥仅支持 ~245 字节）。实际必须配合协议设计：比如约定前端用服务端公钥加密 AES 密钥，再用该 AES 密钥加密业务数据（即混合加密），或只对关键字段（如 token、ID）做 RSA 封装。
常见做法是：在中间件层统一处理加解密逻辑，但注意——
- 解密必须放在
c.Request.Body被其他 handler 读取前，否则会因 body 已关闭/耗尽而失败 - 加密响应时需替换
c.Writer，并手动写入加密后数据，不能再调c.JSON等原生方法 - 务必校验密文长度是否超出 RSA 单次承载上限，否则
crypto/rsa: message too long错误静默 panic
如何加载 PEM 格式 RSA 密钥供 Gin 使用
Gin 本身不管理密钥，全靠 Go 标准库 crypto/rsa。你得自己读文件、解析、缓存，别每次请求都重读。
典型加载方式：
func loadRSAPrivateKey(path string) (*rsa.PrivateKey, error) {
data, err := os.ReadFile(path)
if err != nil {
return nil, err
}
block, _ := pem.Decode(data)
if block == nil || block.Type != "RSA PRIVATE KEY" {
return nil, fmt.Errorf("invalid PEM block type: %s", block.Type)
}
return x509.ParsePKCS1PrivateKey(block.Bytes)
}
<p>func loadRSAPublicKey(path string) (<em>rsa.PublicKey, error) {
data, err := os.ReadFile(path)
if err != nil {
return nil, err
}
block, _ := pem.Decode(data)
if block == nil || block.Type != "PUBLIC KEY" {
return nil, fmt.Errorf("invalid PEM block type: %s", block.Type)
}
pub, err := x509.ParsePKIXPublicKey(block.Bytes)
if err != nil {
return nil, err
}
return pub.(</em>rsa.PublicKey), nil
}注意点：
- 私钥文件必须是 PKCS#1 格式（
-----BEGIN RSA PRIVATE KEY-----），不是 PKCS#8（-----BEGIN PRIVATE KEY-----）；后者要用x509.ParsePKCS8PrivateKey - 公钥必须是
PUBLIC KEY类型，不是RSA PUBLIC KEY；后者需用x509.ParsePKCS1PublicKey - 生产环境密钥不能硬编码路径，建议通过环境变量传入绝对路径，避免相对路径在不同工作目录下失效
为什么前端用 C# 或 PHP 加密后 Go 解不出来
核心问题是密钥格式和填充模式不一致。C# 默认导出 XML 密钥，PHP 的 openssl_public_encrypt 默认用 PKCS#1 v1.5，而 Go 的 rsa.EncryptPKCS1v15 虽然也叫 v1.5，但对输入数据长度、错误处理更严格。
排查重点：
- 确认 PHP/C# 是否对明文做了 Base64 编码再传给 RSA？Go 解密后要反向 Base64 解码才能得到原始字节
- C# 若用
RSACryptoServiceProvider，导出的 XML 需转 PEM：用工具或代码将<Modulus>/<Exponent>拼成 ASN.1 结构再 PEM 封装 - PHP 中若用了
OPENSSL_PKCS1_OAEP_PADDING，Go 必须对应用rsa.EncryptOAEP，不能混用 v1.5 - 检查双方是否用了相同哈希算法（OAEP 场景下），Go 默认是
sha256，PHP 需显式指定
生产环境 RSA 加解密容易被忽略的性能坑
RSA 是 CPU 密集型操作，2048 位密钥单次加解密耗时约 0.5–2ms，看似不多，但高并发下会迅速成为瓶颈。Gin 的 goroutine 调度无法掩盖这点。
必须做的优化：
- 私钥解密操作绝不能放在请求 hot path 上；应前置到鉴权环节，且结果缓存（如 JWT payload 解密后存入
c.Set()） - 公钥加密可异步批量做，比如把多个待加密 ID 合并为一个结构体再加密，减少调用次数
- 严禁在循环中反复调用
rsa.DecryptPKCS1v15；如有列表字段需解密，先提取所有密文，再并发解密（注意控制 goroutine 数量） - 测试时用
go tool pprof抓 CPU profile，确认crypto/rsa.(*PrivateKey).Validate和big.(*Int).Exp是否占过高比例
最常被跳过的一步：没验证密钥有效性。加载私钥后应立即调 priv.Validate()，否则运行时首次解密失败才暴露问题，线上已受损。
