Go tls.ClientHelloInfo.Conn 该放在哪里：QUIC 握手连接的取值边界

把 Go 1.27 接到 QUIC 服务端时，最容易混淆的是三个“连接”：上层的 QUICConn、TLS 包里的 tls.Conn，以及握手回调看到的底层 net.Conn。Go 1.27 新增的 QUICConfig.ClientHelloInfoConn 只解决一个问题：指定 ClientHelloInfo.Conn 应该暴露哪一个底层连接。它不改变 QUIC 的数据事件模型，也不授权回调抢读握手字节。

在 QUIC 服务端的 ClientHello 回调里，ClientHelloInfo.Conn 适合做地址记录、连接关联和配置选择；读写仍交给 TLS/QUIC 层，应用数据也不要从这个字段绕过去。

先把 ClientHelloInfo.Conn 放回连接分层

Go 1.27 的发布说明把 QUICConfig.ClientHelloInfoConn 定义为“用于 ClientHelloInfo.Conn 的 net.Conn”。这句话的重点在“指定来源”，不是新增一条应用数据通道。ClientHelloInfo.Conn 是握手信息的一部分，服务端可以借它记录对端地址或把本次握手和外部日志关联起来。

连接分层可以这样记：QUICConfig.ClientHelloInfoConn 位于配置边界，ClientHelloInfo.Conn 指向 net.Conn，而 tls.Conn 和 QUICConn 分别代表 TCP 上的 TLS 连接和 QUIC 会话。它们可能共享底层资源，但接口职责不同。看到字段类型是 net.Conn，不代表 QUIC 已经变成了 TCP 流；它只是把这次 TLS 握手关联到一个底层连接。

在 QUIC 服务端握手回调中只读取连接信息

适配层通常在 tls.Config.GetConfigForClient 回调里读取 ClientHelloInfo。此时 ServerName 和 SupportedProtos 可用于选择证书或协议配置，ClientHelloInfo.Conn 可用于读取 RemoteAddr。但官方文档特别提醒：不要从该连接读，也不要向该连接写，否则 TLS 连接会失败。

base := &tls.Config{
    GetConfigForClient: func(hello *tls.ClientHelloInfo) (*tls.Config, error) {
        peer := hello.Conn.RemoteAddr().String()
        recordHandshake(peer, hello.ServerName, hello.SupportedProtos)
        return base, nil
    },
}

quicConfig := &tls.QUICConfig{
    ClientHelloInfoConn: transportConn,
}

这里的关键是“读取信息后返回配置”。GetConfigForClient 不负责消费 ClientHello，也不应把连接关闭当成通用拒绝机制；证书不匹配、协议不接受等结果应通过 TLS 配置和握手错误返回给上层处理。QUICConfig.ClientHelloInfoConn 的值也应该由 QUIC 适配层维护，业务回调只读它。

按传输类型选择 TLS Conn 还是 QUICConn

普通 TCP TLS 的数据读写和握手由 tls.Conn 完成；它实现 net.Conn，可以调用 Handshake、Read、Write。QUIC 则通过 QUICConn 驱动握手事件、加密级别和传输参数，应用层数据由具体 QUIC 实现管理。两者都依赖 TLS，但不能因为回调里出现了 ClientHelloInfo.Conn 就把接口混为一谈。

这张表也给代码审查一个简单判断：握手回调看 ClientHelloInfo，普通 TLS 看 tls.Conn，QUIC 看 QUICConn。如果同一个变量在这三个位置来回传递，先拆开命名，再确认每个生命周期由谁关闭。

用升级清单验收 ClientHelloInfoConn 的兼容性

接入 Go 1.27 时，第一项检查是构建环境是否真的使用了包含该字段的 Go 版本；第二项检查是 QUIC 适配层是否把合适的 net.Conn 写入 ClientHelloInfo.Conn；第三项检查是回调只读规则和普通 TCP TLS 回归是否仍然成立。

• 字段层：确认 QUICConfig.ClientHelloInfoConn 与 ClientHelloInfo.Conn 的类型、赋值方向一致。
• 回调层：只调用 RemoteAddr 等观察方法，不调用 Read、Write 或随意 Close。
• 协议层：分别覆盖 SNI、ALPN、证书选择和握手失败，确认 QUIC 数据事件仍由 QUICConn 驱动。

如果只是普通 TLS 服务，通常不需要为了这个字段改动连接管理；如果是 QUIC 适配器，则应把字段接入限制在握手关联和诊断信息范围内。这个边界比“能不能编译”更重要：编译通过只说明 API 存在，不能证明握手期间没有被错误读写。

常见问题

ClientHelloInfo.Conn 是 QUICConn 吗？

不是。它是握手信息中的底层 net.Conn，而 QUICConn 是负责 QUIC 事件和传输状态的会话对象。

可以从 ClientHelloInfo.Conn 读取客户端数据吗？

不可以。TLS 官方文档明确要求不要读写该连接，否则会导致 TLS 连接失败；应用数据应走对应的 TLS 或 QUIC 数据接口。

普通 TLS 服务需要设置 ClientHelloInfoConn 吗？

通常不需要。这个字段针对 QUIC 服务端握手中 ClientHelloInfo.Conn 的连接来源，普通 TCP TLS 继续按 tls.Conn 的生命周期处理。