Go 1.27 的 crypto/mldsa 适合直接替换什么：ML-DSA 签名接入边界

如果团队准备把 RSA 或 Ed25519 用在新的签名链上，Go 1.27 的 crypto/mldsa 值得单独评估，但它不是“换一个包就能替代全部密码学组件”。它最适合先接管应用层数字签名，再根据证书链和对端能力评估 crypto/x509、TLS 1.3 的联动。

ML-DSA 解决的是数字签名与验签；数据加密、密钥协商、旧客户端兼容仍要分别设计，最稳妥的路径是先小范围双轨验证，再决定是否切换默认算法。

先分清替换对象：ML-DSA 是签名，不是加密

先把现有链路拆成三栏，结论会清楚很多。应用请求里的“谁签了这段数据”属于数字签名；证书里的公钥和签名属于身份与信任链；TLS 握手里的签名方案又受通信双方协商能力约束。ML-DSA 可以进入前两栏，并在 Go 1.27 的 TLS 1.3 支持中出现，但不能因此推断它会自动替换 AES 数据加密或所有密钥协商。

这一步的验证标准不是“代码能编译”，而是你能明确写出签名对象、验证对象和失败后的回退方式。否则后面很容易把算法切换和协议升级混成一次高风险发布。

用 crypto/mldsa 接上消息签名与验签

最小接入可以从消息签名开始。下面的上下文字符串不是装饰，它相当于把同一把钥匙的不同业务用途隔开；签名端和验签端必须约定完全相同的值。

sk, err := mldsa.GenerateKey(mldsa.MLDSA44())
if err != nil {
    return err
}

msg := []byte(`order:v1|id=8421|amount=199`)
opts := &mldsa.Options{Context: "order-sign-v1"}
sig, err := sk.Sign(nil, msg, opts)
if err != nil {
    return err
}

if err := mldsa.Verify(sk.PublicKey(), msg, sig, opts); err != nil {
    return err
}

官方示例中，MLDSA44 公钥编码为 1312 字节、签名为 2420 字节。它们明显大于许多旧签名方案，JWT、数据库字段、消息队列头部和网关限制都要重新量一遍。验签时故意改动金额、顺序或 context，应该得到失败；这才是第一层可复查证据。

x509 与 TLS 1.3 什么时候可以一起切换

Go 1.27 已让 crypto/x509 识别 ML-DSA 私钥、ML-DSA 公钥和 ML-DSA 签名，crypto/tls 也为 TLS 1.3 增加了 MLDSA44、MLDSA65、MLDSA87 签名方案。这表示标准库有接入面，不表示任意旧客户端都会协商成功。

实际切换时至少要分别检查：证书能否被目标运行时加载，链上的每个签名是否被验证端接受，TLS 1.3 对端是否支持目标签名方案，以及失败时是否保留旧链路。证书加载成功但握手失败，通常说明问题在协商或对端能力，而不是消息签名代码本身。

上线前用三层兼容清单收口

建议把灰度门槛写成三层，而不是只保留一条“验签成功”的测试记录。

还要关注运行环境。官方文档指出，FIPS 140-3 Go Cryptographic Module v1.0.0 模式下，crypto/mldsa 的部分密钥和验签函数会返回错误；使用合规模块的项目应先确认模块版本和发布配置。只有三层都能复测，才适合把默认签名算法改成 ML-DSA。

常见问题

crypto/mldsa 能直接替换 RSA 或 Ed25519 的所有用途吗？

不能。它适合替换数字签名用途，证书、TLS 协商和旧客户端兼容要单独验证，数据加密与密钥协商也不是同一件事。

为什么签名代码通过，线上协议仍可能失败？

应用层验签只证明一对密钥和一段输入匹配；线上还要经过证书解析、信任链和 TLS 1.3 签名方案协商。

MLDSA44、MLDSA65、MLDSA87 应该怎么选？

它们是不同参数集，选择要以安全策略、签名尺寸、性能和对端互操作结果为准，不要只按数字大小拍板。