Go 1.27 ecdsa.PrivateKey.Sign 为什么检查哈希长度：SignerOpts 约束

升级 Go 1.27 后，一些封装了 crypto.Signer 的代码可能在 ecdsa.PrivateKey.Sign 处直接报错。变化并不是 ECDSA 算法换了，而是方法会在 SignerOpts 非空时核对“声明的哈希算法”和“实际摘要字节数”。例如传入 crypto.SHA256，摘要就必须是 32 字节；把 SHA-512 摘要配成 SHA-256，会在签名前被拒绝。

所有传入Sign方法的摘要长度必须和当前ECC曲线能安全处理的位长匹配，不匹配的输入会直接返回错误，不会进入后续的签名运算流程。

Go 1.27 把算法声明和摘要长度绑在一起

官方发布说明明确记录：当提供非空 SignerOpts 时，PrivateKey.Sign 现在检查哈希长度。源码中的边界很直接：先从 SignerOpts 取得 HashFunc()，再比较 Hash.Size() 与 len(digest)。算法为 crypto.Hash(0) 时返回“必须传入哈希”的错误，长度不一致时返回 ecdsa: hash length does not match hash function。

这里保护的资产不是私钥文件本身，而是“算法元数据与摘要内容的一致性”。digest []byte、SignerOpts 和 PrivateKey.Sign 共同组成输入边界；只有进入“长度一致”状态，签名请求才继续。这个检查更像接口契约收紧，不应夸大成对所有 ECDSA 攻击的通用防护。

最小写法是让摘要和 SignerOpts 成对出现

下面的调用把 sha256.Sum256 与 crypto.SHA256 明确配对，既便于评审，也能通过 Go 1.27 的长度检查：

digest := sha256.Sum256(message)
sig, err := privateKey.Sign(rand.Reader, digest[:], crypto.SHA256)
if err != nil {
    return err
}
_ = sig

常见错误是上游改成 sha512.Sum512，下游仍保留 crypto.SHA256；另一个风险是自定义 SignerOpts 返回了与实际摘要不同的算法。Go 1.27 会更早暴露这类错配。这里别急着删掉 opts 来绕过检查，那会让算法语义重新变得含糊，也会掩盖适配器之间的协议问题。

迁移时先审计这三条调用路径

第一类是直接调用私钥的方法，检查摘要函数与 crypto.Hash 是否成对。第二类是自定义 Signer，它可能把调用转发给 HSM、云密钥或插件；重点看它是否原样传递 SignerOpts。第三类是测试桩，尤其是为了省事返回 crypto.Hash(0) 的实现。

随机签名和确定性签名都应纳入回归测试。前者通常传入 rand.Reader，后者在 random 为 nil 时还依赖有效的哈希算法。测试至少覆盖正确的 sha256.Sum256、错误摘要长度、crypto.Hash(0) 以及自定义 Signer 转发，断言错误文本和调用是否在签名前停止。

常见问题

升级后出现长度错误，是私钥损坏了吗？

通常不是。先检查摘要函数、摘要切片和 SignerOpts.HashFunc() 是否一致；新错误发生在签名前的参数校验阶段。

可以把 SignerOpts 传 nil 维持旧行为吗？

不建议把它当迁移方案。调用方既然知道摘要算法，就应明确传递并修复错配；否则算法信息会在封装层丢失。

把报错当成协议审计入口

Go 1.27 的变化很小，但定位价值很高：它把原先可能潜伏在签名适配层的算法错配，提前变成可测试的接口错误。修复时不要只改到“不报错”，还要确认摘要生成、算法声明、远程签名封装和回归用例使用的是同一份协议。

参考：Go 1.27 Release Notes、crypto/ecdsa 官方源码、Go 1.27 官方发布文章。