必须显式设置CurvePreferences，否则Go会fallback至含CurveP384等未优化曲线，单次密钥交换或耗近1秒CPU，导致握手超时、并发下降；推荐优先配置X25519和CurveP256并配合PreferServerCipherSuites:true。
Go 的 crypto/tls 默认支持椭圆曲线，但必须显式设置 CurvePreferences 才能生效——不设就是用 Go 运行时自动选（可能包含低效或未优化的曲线），设错可能拖慢握手甚至卡住连接。
为什么必须手动配 CurvePreferences
Go 会按 CurvePreferences 列表顺序尝试协商曲线，遇到第一个双方都支持的就用。如果不设，它会 fallback 到内置默认列表（含 CurveP384 等未做汇编优化的曲线），而 CurveP384 在某些 CPU 上单次密钥交换可能耗掉近 1 秒 CPU 时间，直接导致 TLS 握手超时或大量连接堆积。
常见错误现象：curl 或浏览器连上后卡住几秒才响应；net/http 服务并发突降、tls.handshake_timeout 报错频发；监控里看到 crypto/elliptic.(*CurveParams).ScalarMult 占高 CPU。
-
CurveP256是目前最稳妥的选择：所有主流平台都有汇编优化，兼容性好，性能稳定 -
X25519（Go 1.8+）更快更现代，但部分旧客户端（如 Windows 7 + IE11、Android 4.x）不支持 - 避免混用
CurveP384或CurveP521，除非你明确压测过它们在目标服务器上的实际开销 - 顺序很重要：把最快、最兼容的放前面，比如
[]tls.CurveID{tls.X25519, tls.CurveP256}
CurvePreferences 和 PreferServerCipherSuites 要一起设
只设曲线不设套件偏好，客户端仍可能选一个不匹配的密钥交换方式（比如用 RSA 证书却协商 ECDHE-ECDSA 套件），导致握手失败。两者是协同生效的。
立即学习“go语言免费学习笔记（深入）”；
加密货币跨交易所套利监控器，实时监控BTC/ETH/SOL等主流币在各交易所价差，发现套利机会后通过飞书/Telegram预警，自动计算扣除手续费后的净利润。
典型配置片段：
config := &tls.Config{
CurvePreferences: []tls.CurveID{
tls.X25519,
tls.CurveP256,
},
PreferServerCipherSuites: true,
MinVersion: tls.VersionTLS12,
MaxVersion: tls.VersionTLS13,
}
- 如果服务端用的是 ECDSA 证书，
CurveP256必须在列表里，否则某些客户端会拒绝握手 - 如果用了
X25519但没配对应私钥（即证书是 RSA 的），Go 不会报错，但实际协商会 fallback 到下一个曲线——得靠抓包确认是否真生效 -
PreferServerCipherSuites: true不只是为密码套件，也影响密钥交换算法的优先级决策
如何验证 CurvePreferences 生效了
不能只看代码有没有写，得看真实握手行为。最简单方法是用 openssl s_client 连接后查 Server Hello：
openssl s_client -connect example.com:443 -tls1_2 -cipher ECDHE-ECDSA-AES128-GCM-SHA256 2>/dev/null | grep "Server key exchange"
输出里出现 ecdh curve X25519 或 ecdh curve P-256 才算真正生效。
- 用
go tool trace可以看到crypto/elliptic相关函数调用热点，确认没落到慢路径 - 线上建议加日志：在
GetConfigForClient回调里打点，记录每次协商出的曲线 ID - 注意：
tls.Config.GetConfigForClient返回的*tls.Config如果没设CurvePreferences，该次连接就用不到你全局配的值
曲线不是配了就完事——它和证书类型、客户端能力、密码套件三者必须对齐，漏掉任一环都可能让整个 TLS 配置退化成“看起来安全，实则慢且脆”。
