使用crypto/rsa时，私钥必须为*rsa.PrivateKey类型，需用x509.ParsePKCS8PrivateKey或ParsePKCS1PrivateKey解析PEM块；签名与验签的hash类型、填充方案、密钥格式必须严格一致，否则验签失败。
用 crypto/rsa 生成密钥对和签名时，私钥必须是 *rsa.PrivateKey 类型
Go 标准库不接受 PEM 解码后直接断言为 *rsa.PrivateKey——哪怕内容正确，也常因类型断言失败 panic。常见错误是读取私钥后写成：privateKey := pemBlock.Bytes，然后直接传给 rsa.SignPKCS1v15，这会报 interface conversion: interface {} is []byte, not *rsa.PrivateKey。
正确做法是先用 x509.ParsePKCS1PrivateKey（对应 PKCS#1 格式）或 x509.ParsePKCS8PrivateKey（对应 PKCS#8）解析字节流：
block, _ := pem.Decode(pemBytes)
if block == nil {
return nil, errors.New("failed to decode PEM block")
}
privateKey, err := x509.ParsePKCS8PrivateKey(block.Bytes)
if err != nil {
privateKey, err = x509.ParsePKCS1PrivateKey(block.Bytes) // fallback
}
if err != nil {
return nil, err
}
- PKCS#1 私钥开头是
-----BEGIN RSA PRIVATE KEY-----；PKCS#8 是-----BEGIN PRIVATE KEY-----，后者更现代、支持多种算法，优先用ParsePKCS8PrivateKey - 公钥同理：用
x509.ParsePKIXPublicKey或x509.ParsePKCS1PublicKey，别直接用rsa.PublicKey字段赋值 - 签名前务必校验
privateKey != nil，否则运行时 panic
签名时 hash 必须与 SignPKCS1v15 的 hash 参数严格匹配
比如你用 sha256.Sum256 计算摘要，却传 crypto.SHA1 给 rsa.SignPKCS1v15，函数不会报错，但验签必然失败——因为底层按你传的 hash 类型去填充并验证 ASN.1 编码结构。
实操要点：
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 先算哈希：
hash := sha256.Sum256(data)，再调用rsa.SignPKCS1v15(rand.Reader, privateKey, crypto.SHA256, hash[:]) -
crypto.Hash值必须和实际哈希算法一致，crypto.SHA256对应sha256，不是字符串"sha256" - 若用
h := sha256.New(); h.Write(data); sum := h.Sum(nil)，则传sum（而非h）进签名函数，且仍需指定crypto.SHA256 - ECDSA 签名（
ecdsa.SignASN1）同理，hash 参数必须与hash.Hash实例类型一致
验签失败的三大高频原因：公钥格式错、哈希不一致、填充方案不匹配
最典型现象是 rsa.VerifyPKCS1v15(pubKey, crypto.SHA256, dataHash[:], signature) 返回 crypto.ErrVerification，但你确认私钥签过、数据没动过。
逐项排查：
- 公钥是否从证书中误取了
cert.PublicKey？它可能是interface{}，需显式转成*rsa.PublicKey：pubKey, ok := cert.PublicKey.(*rsa.PublicKey) - 验签用的哈希值是否和签名时完全相同？注意：不能对原始数据重新哈希，而应复用签名时的
hash.Sum(nil)结果；若签名时用的是sha256.Sum256(data).Sum(nil)，验签也得用同一份字节 - 签名用的是
SignPKCS1v15，验签就不能用SignPSS对应的VerifyPSS——两者填充机制完全不同，混用必失败 - ECDSA 验签时，
ecdsa.VerifyASN1的输入是原始 R/S 拼接字节（ASN.1 DER 编码），不是纯 R+S 的 64 字节，别自己拼接
用 crypto/ecdsa 时，私钥导出要小心 rand.Reader 的使用场景
ECDSA 签名函数 ecdsa.Sign 和 ecdsa.SignASN1 都要求传入 rand.Reader，但这个随机源只用于生成临时私钥 k（符合 RFC 6979 的确定性签名除外）。线上服务若用 rand.Reader = rand.Reader（即系统熵池），在容器或低熵环境可能阻塞或失败。
建议：
- 生产环境优先用
ecdsa.SignASN1+crypto/rand.Reader，它已做熵池健康检查 - 单元测试可用
rand.New(rand.NewSource(1))构造确定性 reader，便于断言签名结果 - 不要把
math/rand的实例传给 crypto 函数——它不满足密码学安全要求，ecdsa.Sign会 panic - ECDSA 公钥序列化推荐用
x509.MarshalPKIXPublicKey，而不是手动取X, Y字段拼接
数字签名不是“套个函数就完事”，密钥类型、哈希绑定、填充协议、编码格式，四者缺一不可。漏掉任一环，表现都是“验签失败”，但原因可能天差地别。
