Go 1.27 QUIC 握手如何传入连接信息：ClientHelloInfoConn 解决什么问题

QUIC 服务端按 SNI 选择证书时，GetCertificate 通常只看域名；一旦还要按本地监听地址、远端地址或传输层标签做判断，回调就需要一个可靠的连接视图。Go 1.27 在 tls.QUICConfig 中增加 ClientHelloInfoConn，让 QUIC 实现可以明确指定 ClientHelloInfo.Conn 应该暴露哪个 net.Conn。

这个字段用于向证书或配置回调提供连接元数据，不是让 TLS 代码直接读写 QUIC 数据。回调可以读取地址等信息，但绝不能对 ClientHelloInfo.Conn 调用 Read 或 Write。

为什么 QUIC 握手需要单独传入 net.Conn 视图

普通 TLS 连接天然包着一个底层 net.Conn，因此 ClientHelloInfo.Conn 有明确来源。QUIC 不同：TLS 只处理握手协议，数据报收发与连接管理由 QUIC 传输实现负责，TLS 层未必持有一个可直接代表传输连接的 net.Conn。

Go 1.27 的新字段把这层关系说清楚。QUIC 传输适配器准备一个 QUIC 连接视图，写入 QUICConfig.ClientHelloInfoConn；当 TLS 构造 ClientHelloInfo 时，再把该对象放入 Conn 字段。它不是新的网络连接，也不接管 QUIC 的收发。

最小配置写法放在哪里

最小写法只需要在创建 tls.QUICServer 或 tls.QUICClient 之前，把已经由传输层准备好的 net.Conn 视图放进配置：

quicTLS := &tls.QUICConfig{
    TLSConfig:          tlsConfig,
    ClientHelloInfoConn: connView,
}

q := tls.QUICServer(quicTLS)

connView 不是普通 TCP 连接的替身，而是 QUIC 实现给 TLS 回调看的适配对象。它必须满足 net.Conn 接口；最常见的用途是让 LocalAddr 和 RemoteAddr 返回与当前 QUIC 会话对应的地址。对象生命周期也应至少覆盖握手及相关回调，避免回调拿到已经失效的元数据。

证书回调应该怎样读取连接信息

ClientHelloInfo 的官方定义明确说明，Conn 是底层连接，并警告不要从中读取或向其写入数据。对 QUIC 来说，这条边界更重要：传输数据并不由这个视图负责。

tlsConfig.GetConfigForClient = func(hello *tls.ClientHelloInfo) (*tls.Config, error) {
    if hello.Conn == nil {
        return defaultConfig, nil
    }

    local := hello.Conn.LocalAddr()
    remote := hello.Conn.RemoteAddr()
    return chooseConfig(hello.ServerName, local, remote), nil
}

这里的 chooseConfig 只是业务边界示意：输入是 SNI、本地地址和远端地址，输出是一份不可在回调后继续修改的 TLS 配置。不要在回调里调用 Read、Write 或试图推进 QUIC 握手，也不要把这个对象长期保存到握手之外。

哪些信息适合放进连接视图

连接视图最好只暴露稳定且确实属于当前会话的信息：

• 本地地址：区分同一进程监听的不同 VIP、端口或网络命名空间；
• 远端地址：供日志、租户路由或策略匹配使用，但不要把容易变化的地址当成唯一身份；
• 生命周期方法：满足 net.Conn 接口需要，但握手回调不应借此关闭或修改真实 QUIC 会话。

如果业务需要更多传输层标签，更稳妥的做法是在适配类型上定义额外只读接口，再在回调中做类型断言。这样既保留 net.Conn 兼容性，又不会把所有 QUIC 私有状态塞进地址字符串。

升级到 Go 1.27 时怎样保持兼容

没有读取 ClientHelloInfo.Conn 的程序通常不需要因为新字段改代码。真正需要迁移的是那些 QUIC 证书回调已经依赖连接地址，却过去只能从闭包、全局映射或自定义上下文旁路获取信息的实现。

升级时建议核对四点：

1. 所有创建 tls.QUICConfig 的入口是否都使用同一种连接视图；
2. GetCertificate 与 GetConfigForClient 是否能处理 hello.Conn == nil；
3. 回调是否只读取元数据，没有调用 Read、Write、Close 或期限设置方法；
4. 多连接并发时，连接视图是否按会话独立创建，没有复用可变地址字段。

常见问题

ClientHelloInfoConn 会让 TLS 接管 QUIC 连接吗？

不会。它只指定 ClientHelloInfo.Conn 的值，QUIC 数据收发仍由传输实现管理。

可以直接传 UDPConn 吗？

只有当它准确代表当前回调需要的会话语义时才合适。一个共享 UDP socket 往往不能唯一表示某条 QUIC 会话，更常见的是传入按会话封装的连接视图。

为什么还要检查 hello.Conn 是否为 nil？

回调可能在旧版本适配层、不同 QUIC 实现或未设置新字段的配置中运行。保留 nil 分支可以让默认配置继续工作。

能在回调里读取一个字节来识别客户端吗？

不能。官方文档明确警告读写该连接会让 TLS 连接失败；客户端信息应来自 ClientHello 字段或传输层提供的只读元数据。

小结

QUICConfig.ClientHelloInfoConn 解决的是连接元数据如何进入 ClientHello 回调，而不是 QUIC 数据如何传输。把它视为一条明确的适配边界：传输层提供按会话的 net.Conn 视图，TLS 把视图放进 ClientHelloInfo.Conn，证书和配置回调只读取必要元数据。边界守住后，过去依赖闭包或全局映射的连接信息就能收敛到更清晰的配置结构中。

参考：Go 1.27 官方发布说明、crypto/tls 官方包文档。