RSA加解密在Go中易出错的四大关键点：明文长度超限（2048位密钥≤245字节）、私钥格式需匹配（PKCS#1用ParsePKCS1PrivateKey，PKCS#8用ParsePKCS8PrivateKey）、解密结果为原始字节不可直接转string、PKCS1v15与OAEP填充不可混用。
rsa.EncryptPKCS1v15 和 rsa.DecryptPKCS1v15 是 Go 标准库里最常用、也最容易出错的 RSA 加解密组合——不是因为难，而是因为几个硬性约束稍不注意就 panic 或返回乱码。
明文超长直接 panic：crypto/rsa: message too long 怎么破
这个错误不是你的代码写错了，是rsa.EncryptPKCS1v15 遇到超过限制的输入时会立刻 panic，不给你任何重试机会。
2048 位密钥 → 最大明文长度 = pubKey.Size() − 11 = 256 − 11 = 245 字节。
1024 位密钥已不安全，且只支持 117 字节，别用。
- 别对原始字符串（尤其是 JSON、base64、含中文的配置）直接调用加密函数
- 若数据来自
io.Reader（如文件、HTTP body），先读进[]byte再判断长度 - 超长必须手动分块：每次取 ≤245 字节加密，拼接密文；解密端按相同块长切片后逐个
DecryptPKCS1v15 - 更推荐混合加密：用
rsa.EncryptPKCS1v15加密一个随机生成的 AES 密钥，再用该密钥加密实际数据
私钥解析失败：x509: failed to parse private key 的真实原因
错误信息指向 PEM 解析失败，但根因几乎全是格式不匹配：x509.ParsePKCS1PrivateKey只认"RSA PRIVATE KEY"类型的 PEM 块（PKCS#1 格式）x509.ParsePKCS8PrivateKey才认"PRIVATE KEY"（PKCS#8 格式）-
rsa.GenerateKey默认产出的是 PKCS#1 私钥，但很多人用 OpenSSL 生成的私钥是 PKCS#8（尤其 macOS 自带 openssl），导致解析失败立即学习“go语言免费学习笔记（深入）”；
生成密钥时统一用
x509.MarshalPKCS8PrivateKey+"PRIVATE KEY"，兼容性更好读私钥前先
pem.Decode，检查block.Type再选对应解析函数不要手敲 PEM 内容：换行符、空格、BOM、多余空行都会让
pem.Decode返回nil
解密后 string(res) 是乱码？不是解密失败，是字节误转
rsa.DecryptPKCS1v15 返回的是原始 []byte，它不承诺是 UTF-8 编码的字符串。
如果原始明文是二进制数据（比如加密后的 AES 密文、图片片段、protobuf），string(res) 强制转 UTF-8 就会显示为 或乱码，但字节本身完全正确。
- 验证是否真失败：用
bytes.Equal(src, res)比对原始输入和解密输出 - 若原始数据是字符串，加密前先确认
utf8.Valid(src) - 若是任意二进制数据，全程用
[]byte，传输前 base64 编码，接收后先base64.StdEncoding.DecodeString还原，再传给解密函数 - 别在中间环节混用
string(b)和[]byte(s)，尤其涉及中文、emoji、加密结果时
EncryptPKCS1v15 和 EncryptOAEP 能否混用？不能，且无提示
两者填充机制完全不同，密文结构不兼容。服务端用EncryptOAEP 加密，客户端用 DecryptPKCS1v15 解密，不会报“不匹配”，而是直接返回 crypto/rsa: decryption error —— 错误信息毫无指向性。
- 新项目优先用
EncryptOAEP：更安全，支持标签（label参数），抗选择密文攻击 - 但 OAEP 要求指定哈希（如
sha256.New()）和非空 label（哪怕只是[]byte("api")），否则 panic - 如果要和 Java/PHP 互通，确认对方用的 padding：Go 的
EncryptPKCS1v15对应 Java 的RSA/ECB/PKCS1Padding，不是OAEPWithSHA-256AndMGF1Padding - 解密函数必须严格配对：
DecryptPKCS1v15←→EncryptPKCS1v15，DecryptOAEP←→EncryptOAEP
密钥格式、填充方式、字节边界、编码还原——这四点漏掉任一，RSA 在 Go 里就不是“加解密”，而是“调试半天才看到一行 panic”。
