Go 1.27 把 ML-DSA 收进标准库：TLS 1.3 的密钥交换和签名现在凑齐了
官方资料：
crypto/mldsa：FIPS 204 后量子签名进标准库
Go 1.27 新增 crypto/mldsa 包，把 ML-DSA（FIPS 204）作为一等公民支持。如果团队已经排了后量子迁移时间线，这条改动的分量在于：Go 现在同时覆盖了密钥交换和签名两类标准化原语，不必为了 ML-DSA 去引第三方实现。
x509、TLS 和 External Mu
crypto/x509可以解析并处理 ML-DSA 的私钥、公钥和签名。crypto/tls在 TLS 1.3 中支持 ML-DSA，方式是新增MLDSA44、MLDSA65、MLDSA87三个SignatureScheme值。- 新增的
MLDSAMu带一个Hash值，支持 External Mu 形式的 ML-DSA 签名。 MLKEM1024现在可以作为密钥交换选项使用，crypto/tls的CurvePreferences增加了MLKEM1024。
密钥交换和签名都齐了，对迁移时间线意味着什么
后量子迁移一般分两步：先换密钥交换，防「先存后解」；再换签名，防伪造。ML-KEM 上一轮已经就位，这次 ML-DSA 补齐签名侧，标准库两个方向都能走。落到工程上，证书链、TLS 握手、签名验证这些环节可以开始用同一套标准原语串起来验证，不用等各个依赖库分别跟进。
但「标准库支持」不等于「可以上线」。当前的瓶颈更多在证书签发侧和中间件上：CA 是否签发 ML-DSA 证书、对端认不认这些签名方案、既有信任链能不能平滑过渡。标准库这一层解决的是「Go 这边能算」。
现阶段值得验证的三件事
- 互操作性。
MLDSA44/65/87对应不同安全强度，先确认对端（其他语言实现、网关、负载均衡）认哪个等级，以及握手会不会因算法协商失败回落到经典方案。MLKEM1024作为密钥交换选项同理。 - 证书链。用
crypto/x509解析 ML-DSA 公私钥与签名，跑一遍签发—验证闭环，确认中间 CA 和根证书的行为符合预期。 - 性能开销。ML-DSA 的签名尺寸和 CPU 开销都高于 ECDSA，握手包体积和 QPS 值得实测；
MLDSAMu的 External Mu 路径如果有预哈希需求，也一并压测。
同版本顺带记两笔
crypto/ecdsa的PrivateKey.Sign现在在传入非 nil 的SignerOpts时会校验 hash 长度。crypto/tls的Config.Rand被弃用，替代方案是testing/cryptotest.SetGlobalRandom。
此外，Go 1.27 支持了泛型方法；新增 encoding/json/v2（默认更严格：拒绝非法 UTF-8 字符串和重复的对象成员名）与 encoding/json/jsontext，原有 encoding/json 现在由 v2 实现支撑；新增 uuid 包和 go fix modernizers；goroutineleak profile 转 GA；小对象分配最多便宜 30%；升级到 Unicode 17；最低 macOS 版本升至 13。