Go tls MLKEM 为什么曲线偏好没有生效（参数形态）

Go 的 crypto/tls 里，MLKEM 曲线偏好没有按预期生效，最常见的原因不是 MLKEM 名称写错，而是把 CurvePreferences 当成了“按顺序执行的优先级列表”。它实际是 []tls.CurveID 类型的允许集合，列表顺序会被忽略，协商时还要受到对端支持范围和 TLS 版本的共同限制。

先把参数写成正确的 []tls.CurveID，再区分 nil 默认集合和显式集合；如果显式列表只放 MLKEM1024，客户端与服务端没有共同支持组时，握手就不会因为“偏好”而强行使用它。

• 参数形态：字段需要一个 []tls.CurveID，元素才是 tls.MLKEM1024 等常量。
• 顺序语义：文档明确说明列表顺序被忽略，内部固定顺序决定选择。
• 默认语义：nil 才会使用默认集合，显式切片会改成调用方指定的集合。
• 协商边界：最终使用的组必须同时出现在客户端和服务端可接受的范围内。

先确认 CurvePreferences 的参数形态

tls.Config.CurvePreferences 的声明是 []tls.CurveID。这里的“Curve”是历史命名，TLS 1.3 已经把这类值扩展为 named group，也包含后量子混合密钥交换和 ML-KEM。Go 1.27 新增了 tls.MLKEM1024，但它仍然要以 CurveID 元素的形式放进切片。

package main

import "crypto/tls"

func tlsConfig() *tls.Config {
	return &tls.Config{
		MinVersion: tls.VersionTLS13,
		// 字段需要切片；每个元素都是一个允许的 TLS named group。
		CurvePreferences: []tls.CurveID{
			tls.MLKEM1024,
			tls.X25519MLKEM768,
			tls.X25519,
		},
	}
}

下面几种写法都表达错了参数形态：给字段赋一个单独的 tls.MLKEM1024、把字符串 "MLKEM1024" 放进去，或者把它误写到签名算法配置中。它们不是“偏好不生效”，而是类型或配置职责不匹配。

为什么调整切片顺序看不到效果

官方文档对 CurvePreferences 的说明很关键：它表示一组支持的密钥交换机制，列表顺序会被忽略，实际选择使用 crypto/tls 的内部偏好顺序。因此，把 tls.MLKEM1024 从切片末尾移动到开头，并不等于告诉 Go“必须优先选它”。

这也是“参数写对但结果没变”的典型原因。切片的作用更接近过滤器：显式列出的值可以进入候选集合，未列出的值被排除；候选集合内部的优先级由库实现决定。若目标是限制协商范围，应减少集合中的元素；若目标是改变内部优先级，单靠调整切片顺序并不能完成。

var cfg = &tls.Config{
	MinVersion: tls.VersionTLS13,
	// 顺序不是业务优先级；这里只表达允许的集合。
	CurvePreferences: []tls.CurveID{
		tls.X25519,
		tls.MLKEM1024,
	},
}

nil、显式集合与 GODEBUG 的区别

当 CurvePreferences 为空时，crypto/tls 使用默认集合。Go 1.24 起默认集合包含 X25519MLKEM768，Go 1.26 起又包含 SecP256r1MLKEM768 和 SecP384r1MLKEM1024；Go 1.27 另外支持把 MLKEM1024 显式加入 CurvePreferences。因此，下面两种配置的语义不同：

// nil：交给 crypto/tls 选择默认的支持集合。
defaultConfig := &tls.Config{}

// 显式集合：只允许这两个 named group，默认集合不会自动并入。
restrictedConfig := &tls.Config{
	CurvePreferences: []tls.CurveID{
		tls.MLKEM1024,
		tls.X25519,
	},
}

tlsmlkem=0 和 tlssecpmlkem=0 主要影响默认集合。当调用方显式填写 CurvePreferences 时，Go 1.27 允许通过该字段明确启用后量子混合密钥交换；不要把关闭默认项的 GODEBUG 理解成对显式集合的无条件覆盖。

用“共同支持组”定位没有采用 MLKEM

排错时不要只看本地配置。客户端的 CurvePreferences 与服务端的配置共同决定可用集合；如果一端只接受 tls.X25519，另一端只提供 tls.MLKEM1024，两边就没有共同组，握手无法因为本地偏好而越过对端能力。

可以按下面的顺序检查：第一，确认运行时和构建环境确实支持 Go 1.27 的 tls.MLKEM1024；第二，确认字段类型和元素是 []tls.CurveID；第三，确认没有把切片顺序当成优先级；第四，比较客户端和服务端显式集合；第五，若字段为 nil，再检查默认集合相关的 GODEBUG 设置。

常见问题

CurvePreferences 越靠前是不是越优先？

不是。官方文档明确说列表顺序会被忽略；它主要用于指定允许的密钥交换机制集合。

为什么只配置 MLKEM1024 后反而连不上？

显式切片会收窄允许范围。如果服务端不接受 MLKEM1024，且双方没有其他共同组，握手就会失败。需要根据两端能力决定是否保留 X25519 或其他共同支持组。

tlsmlkem=0 会覆盖显式配置吗？

Go 1.27 的发布说明区分了默认集合与显式 Config.CurvePreferences。显式配置可以明确启用相关后量子组；排查时先确认字段是否为 nil，再判断 GODEBUG 的影响范围。