rsa.DecryptPKCS1v15解密失败主因是密钥格式或数据不匹配：私钥需按PEM块类型（PRIVATE KEY/PKCS#8或RSA PRIVATE KEY/PKCS#1）正确解析，密文须为同公钥+PKCS1v15加密且长度严格等于密钥字节数，分段密文需手动切片解密合并。
rsa.DecryptPKCS1v15 解密失败的常见原因
直接调用 rsa.DecryptPKCS1v15 却返回 crypto/rsa: decryption error，大概率不是算法问题，而是密钥格式或数据来源不匹配。Go 的 crypto/rsa 对私钥格式非常敏感：如果 PEM 块类型是 PRIVATE KEY（PKCS#8），必须用 x509.ParsePKCS8PrivateKey；如果是 RSA PRIVATE KEY（PKCS#1），才该用 x509.ParsePKCS1PrivateKey。混用会静默解出 nil *rsa.PrivateKey，后续解密必然 panic 或报错。
- 用
pem.Decode()后先检查block.Type，别硬编码解析函数 - 密文必须是用对应公钥、相同填充方案（如 PKCS1v15）加密的，跨语言交互时尤其注意 Java 默认用 PKCS#8 + OAEP，而 Go 示例常写 PKCS1v15
- 密文长度需严格等于公钥字节长度（如 2048 位 → 256 字节），少一字节或多一字节都会解密失败
分段解密长数据时的边界处理
RSA 本身不能直接加密超过 keySize - 11 字节的明文（PKCS#1 v1.5）。若密文是拼接多段加密结果（比如前端 JS 分段加密后传入），Go 端必须手动切片解密再合并，不能一股脑丢给 rsa.DecryptPKCS1v15。
- 每次解密长度 = 私钥字节数（
priv.Size()），例如 2048 位私钥 → 每次最多解 256 字节密文 - 用
bytes.NewReader(cipherData)配合循环读取，避免手动算 offset 出错 - 解密后字节直接
append到[]byte{}，别转 string 再拼 —— 中文或二进制数据会因 UTF-8 解码损坏
私钥加载时的典型 PEM 类型判断逻辑
别靠文件名或注释猜格式，block.Type 才是唯一可信依据。实际项目中经常遇到运维给的“public.key”其实是 PKIX 格式，而“private.pem”却是 PKCS#8 —— 名称和内容不一致太常见。
-
block.Type == "PRIVATE KEY"→ 用x509.ParsePKCS8PrivateKey -
block.Type == "RSA PRIVATE KEY"→ 用x509.ParsePKCS1PrivateKey -
block.Type == "PUBLIC KEY"→ 用x509.ParsePKIXPublicKey -
block.Type == "RSA PUBLIC KEY"→ 用x509.ParsePKCS1PublicKey
为什么不用 openssl 包而坚持标准库
像 github.com/forgoer/openssl 这类封装库看似省事，但隐藏了 key 格式转换、padding 选择、错误分类等细节。一旦服务上线后遇到跨环境（如 macOS 开发 vs Linux 生产）或跨版本（Go 1.21+ 对 crypto/rand 行为微调）问题，调试成本远高于手写几行标准库代码。
立即学习“go语言免费学习笔记（深入）”；
- 标准库
crypto/rsa+x509组合稳定、无 CGO 依赖、静态编译友好 - 所有错误都来自明确的 error 类型（如
crypto/rsa: decryption error），可精准捕获重试或降级 - 签名验签、加密解密、密钥生成三者共用同一套 key 解析逻辑，维护一致性高
密钥格式和填充方案的匹配是 RSA 解密里最隐蔽也最常出问题的地方，宁可多 decode 一次 block 打印 Type，也不要凭经验硬写解析函数。
