Go 1.27 ML-KEM 1024 怎么显式启用：CurvePreferences 与 GODEBUG 边界

升级到 Go 1.27 后，如果你想在 TLS 1.3 客户端里明确尝试 ML-KEM 1024，关键不是只设置一个环境变量，而是把 tls.MLKEM1024 放进 CurvePreferences。只要这个列表非空，TLS 就按显式候选集合处理；tlsmlkem 和 tlssecpmlkem 主要决定默认集合是否包含后量子混合组。

Go 1.27 先分清默认组与显式列表

先看配置对象，而不是先改 GODEBUG。Go 1.27 的 crypto/tls 新增 MLKEM1024，但它和 Go 1.24、1.26 已加入默认集合的混合组不是一回事。CurvePreferences 为 nil 或空列表时，库才会代入默认组；一旦写入候选项，默认组就不再自动补进来。

这一区分也决定了图中的两个区域：配置边界描述 tls.Config 和 CurvePreferences，选择边界描述 默认组、显式组、MLKEM1024 与 X25519MLKEM768 的归属。

CurvePreferences 中如何只放 MLKEM1024

最小配置可以这样写，重点是列表内容而不是列表顺序：

config := &tls.Config{
    MinVersion:       tls.VersionTLS13,
    CurvePreferences: []tls.CurveID{tls.MLKEM1024},
}

CurvePreferences 的顺序不会成为协商优先级，内部会按 TLS 实现的偏好选择。把 tls.X25519MLKEM768 一起放进去，就已经不是“只放 MLKEM1024”；这样做可以提高对端兼容性，但问题边界也变了。另一个容易忽略的约束是：Config 交给 TLS 函数后不要再修改，应该在创建连接前冻结配置。

tlsmlkem 与 tlssecpmlkem 只影响哪些默认选择

这里最容易把开关作用范围看反。官方文档说明，tlsmlkem=0 可关闭默认的后量子混合选择，tlssecpmlkem=0 可关闭默认的椭圆曲线混合选择；它们针对的是 CurvePreferences 为空时的默认集合。若代码显式写了 tls.MLKEM1024，不能把这两个开关理解成“全局禁止 ML-KEM”。

GODEBUG=tlsmlkem=0,tlssecpmlkem=0 ./client

生产排查时把这三项分开记录：Go 版本、实际的 CurvePreferences 列表、进程启动时的 GODEBUG。只记录环境变量而没有保存配置对象，复查时仍无法知道连接走的是默认组还是显式组。

用 TLS 1.3 握手验证配置是否真的生效

验证要围绕同一条链路展开：客户端创建 tls.Config，CurvePreferences 给出候选，服务端在 TLS 1.3 ClientHello 中看到可协商组，最后再结合连接状态和错误信息判断。GODEBUG 是环境开关，不应被当作握手结果本身。

可以在测试日志里打印配置摘要，但不要把私钥、会话票据或完整握手密钥写入日志。若连接失败，先区分“对端不支持该组”“TLS 版本不匹配”和“本地列表为空或写错 CurveID”，这三种现象的修复方向完全不同。

第二张图按客户端配置、握手观测、环境开关三组展示静态关系：客户端持有 tls.Config，CurvePreferences影响 TLS 1.3 ClientHello，MLKEM1024再与 ConnectionState对应；GODEBUG只标出它与默认选择的边界。

常见问题：为什么显式配置后 GODEBUG 仍可能干扰判断

显式列表能保证对端一定使用 MLKEM1024 吗？

不能。它只能限制本地允许的候选组，最终还要看对端是否支持 TLS 1.3 和同一组；不支持时握手可能失败。

把 CurvePreferences 写成多个值时，排在第一位就优先吗？

不一定。官方文档明确说明列表顺序会被忽略，内部使用实现自己的偏好顺序。

什么时候应该使用 GODEBUG 开关？

当你需要控制未显式设置 CurvePreferences 的默认集合时使用。若代码已经声明显式列表，应优先审查列表内容、Go 版本和对端能力。

复查这类问题时，最小记录包括 Go 版本、MinVersion、完整 CurveID 列表、GODEBUG 原值、对端支持情况和握手错误。这样才能把配置边界与网络能力边界分开。