Go 1.25 crypto.MessageSigner 怎么兼容自带哈希与外部签名器：SignMessage 回退路径

接入硬件密钥或远程签名服务时，最容易踩中的边界是：调用方手里只有一份消息，却不知道签名器希望收到原文，还是已经算好的摘要。Go 1.25 的 crypto.MessageSigner 和 crypto.SignMessage 把这两种约定放进同一条调用路径，优先使用签名器自带的消息签名能力，不支持时再回退到传统的 Signer.Sign。

调用方应把哈希算法、原文和随机源交给 crypto.SignMessage，让它负责判断接口能力；不要先自行哈希，再把摘要误当作原文传给支持 MessageSigner 的实现。

同一个签名调用，为什么会出现两种消息边界

传统的 crypto.Signer 约定比较窄：调用方先计算摘要，再把摘要传给 Sign(rand, digest, opts)。这对 RSA、ECDSA 等常规路径很清楚，但外部签名设备可能希望拿到原文，由设备内部选择哈希、编码和签名格式。把两者硬塞进同一个 digest 参数，适配层就必须猜测。

Go 1.25 增加的 MessageSigner 扩展了这个能力。它仍然可以被普通签名器实现，但额外表达了“我能处理消息本身”的意图；SignMessage 则给调用方一个兼容入口。

type MessageSigner interface {
    SignMessage(rand io.Reader, message []byte, opts SignerOpts) ([]byte, error)
}

func SignMessage(rand io.Reader, signer Signer, message []byte, opts SignerOpts) ([]byte, error) {
    if ms, ok := signer.(MessageSigner); ok {
        return ms.SignMessage(rand, message, opts)
    }
    h := opts.HashFunc()
    digest := h.New()
    digest.Write(message)
    return signer.Sign(rand, digest.Sum(nil), opts)
}

沿着 SignMessage 调用链确认回退条件

判断点只有一个：传入的 signer 是否同时实现了 MessageSigner。实现了扩展接口，就把原始 message 交给 SignMessage；没有实现，才根据 opts.HashFunc() 计算摘要，并调用 Signer.Sign。

这个顺序很重要。若调用方在入口处无条件执行 sha256.Sum256，然后仍把摘要交给 crypto.SignMessage，支持 MessageSigner 的设备会再对摘要做一次消息处理，签名验证自然对不上。

给传统 Signer 写适配测试，别只测返回值

迁移测试至少要准备两个实现：一个只实现 Signer，记录收到的摘要；另一个实现 MessageSigner，记录收到的原文。这样才能证明回退路径确实只哈希一次，也能证明扩展路径没有提前改变消息。

type captureMessageSigner struct {
    got []byte
}

func (s *captureMessageSigner) SignMessage(_ io.Reader, message []byte, _ crypto.SignerOpts) ([]byte, error) {
    s.got = append([]byte(nil), message...)
    return []byte("signature"), nil
}

func verifyMessagePath(signer crypto.Signer, message []byte) error {
    _, err := crypto.SignMessage(rand.Reader, signer, message, crypto.SHA256)
    return err
}

测试断言应检查 captureMessageSigner.got 等于原文，而不是只检查“有一段签名返回”。对只实现 Signer 的测试替身，则断言 hash.Hash 通过 sha256.New 产生的摘要字节已经进入回退调用。

生产接入时的三个防错点

第一，确认签名设备的协议文档写的是“签原文”还是“签摘要”。接口名称只能说明代码能力，不能替代设备协议。第二，把 SignerOpts 和哈希算法当成同一个配置边界传递，避免调用层计算了一种摘要、签名层却按另一种算法验证。第三，对远程签名失败保留原始错误，不要在适配层改成一个笼统的“签名失败”，否则很难区分参数错误、设备拒绝和网络超时。

如果项目仍需要兼容 Go 1.24 或更早版本，可以把兼容逻辑隔离在一个小适配包里，用构建版本策略管理差异；不要在业务代码中散落“先哈希还是后哈希”的判断。升级到 Go 1.25 后，再用上面的双实现测试确认消息边界没有漂移。

相关问题

MessageSigner 会替代 Signer 吗？

不会。它是额外能力接口，传统签名器仍可通过 Signer.Sign 工作，SignMessage 会按能力选择路径。

为什么不能把摘要直接传给 SignMessage？

因为支持 MessageSigner 的实现收到的是 message，可能会按自己的协议再次处理；调用方应传入原文。

怎么确认自己走的是回退路径？

给只实现 Signer 的测试替身记录输入，检查它收到的字节是否等于指定哈希函数计算出的摘要。

远程签名服务也适合实现 MessageSigner 吗？

适合，但要先确认服务端协议确实接收原文，并在适配层保留算法、编码和错误语义。

小结

crypto.SignMessage 的价值在于把接口能力判断集中起来：支持 MessageSigner 时保持原文边界，只实现 Signer 时负责哈希后回退。围绕这条分支写双实现测试，通常比上线后追查“为什么签名偶尔验不过”更省时间。