Go问答：tls.Config ClientSessionCacheTLS 握手为什么没有复用会话怎样完成一个可复用的最小示例

在 Go 客户端里设置了 tls.Config.ClientSessionCache，并不意味着每次请求都会自动出现“会话复用”。最容易混淆的是两件事：HTTP 客户端可能直接复用同一条 TCP/TLS 连接，而 TLS 会话恢复要求第二次请求真正重新握手，再从缓存里拿到服务端提供的票据。

这篇文章用一个本地 HTTPS 示例把两种复用拆开。核心判断只有一个：新连接完成握手后读取 resp.TLS.DidResume。如果它仍为 false，再按客户端缓存、服务端票据和票据生命周期三层排查。

官方文档：https://pkg.go.dev/crypto/tls

要让 Go TLS 会话恢复稳定工作，先保证同一个长期存活的 ClientSessionCache 被多个新连接共享，再确认服务端允许并实际提供会话票据；不要用“同一条连接没有再次握手”来判断会话恢复。

先把两种“复用”分开

连接复用发生在 HTTP 传输层：http.Transport 保留空闲连接，后续请求直接使用已有的 TLS 状态，不会再次执行 TLS 握手。此时你看不到新的 DidResume 判定。

TLS 会话恢复发生在新连接的握手阶段。客户端把上一次握手得到的会话状态放入 ClientSessionCache，下一条新连接尝试使用它。握手结束后，ConnectionState.DidResume 才能说明本次连接是否成功从旧会话恢复。

因此，排查时可以暂时关闭 HTTP keep-alive，让每个请求都创建新连接。这个设置只是为了观察行为，生产环境不要为了追求 DidResume=true 而强行关闭连接。

让缓存跨请求、跨连接存活

ClientSessionCache 是客户端使用的会话状态缓存接口。标准库提供的 tls.NewLRUClientSessionCache 适合做最小实现：容量有限，按最近使用顺序淘汰，而且实现预期会被多个 goroutine 并发调用。

常见错误是把 tls.Config、ClientSessionCache 或 http.Transport 写进单次请求函数。这样第二次请求拿到的是全新的空缓存，自然无法恢复上一次的会话。正确做法是初始化一次，然后让多个新连接共享它。

用最小 HTTPS 示例读取 DidResume

下面的示例使用 httptest.NewUnstartedServer 生成本地 HTTPS 服务，沿用测试客户端的根证书配置。客户端显式创建一个 LRU 会话缓存，并把 DisableKeepAlives 设为 true，确保两次请求分别建立新连接。代码只观察 TLS 状态，不关闭证书校验。

package main

import (
	"crypto/tls"
	"fmt"
	"io"
	"net/http"
	"net/http/httptest"
)

func main() {
	server := httptest.NewUnstartedServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		// 服务端只返回短文本，避免示例把注意力带到业务处理。
		_, _ = io.WriteString(w, "ok")
	}))
	server.StartTLS()
	defer server.Close()

	// 复用 httptest 客户端的根证书，但复制一份 Config 供本客户端管理。
	base := server.Client()
	transport := base.Transport.(*http.Transport).Clone()
	config := transport.TLSClientConfig.Clone()
	config.ClientSessionCache = tls.NewLRUClientSessionCache(8)
	transport.TLSClientConfig = config
	// 每次请求都新建连接，才能观察第二次 TLS 握手是否恢复会话。
	transport.DisableKeepAlives = true
	client := &http.Client{Transport: transport}

	for i := 1; i <= 2; i++ {
		response, err := client.Get(server.URL)
		if err != nil {
			panic(err) // 示例直接终止；生产代码应记录并分类处理错误。
		}
		state := response.TLS
		fmt.Printf("request=%d version=%s didResume=%t\\n", i, tls.VersionName(state.Version), state.DidResume)
		_ = response.Body.Close() // 先关闭响应体，避免影响后续连接管理。
	}
}

在能够提供会话票据的服务端上，通常可以看到第一次请求的 didResume=false，后一次新连接有机会得到 didResume=true。这里的“有机会”很重要：会话恢复是协商结果，不是客户端单方面强制命令，服务端策略、票据是否已经到达客户端以及两次连接间的配置是否兼容都会影响结果。

为什么设置了缓存仍然是 false

可以按下面的顺序检查，先排除客户端明确关闭或没有保存状态的情况，再看服务端和生命周期问题：

标准库文档还明确说明：客户端的 ClientSessionCache 为空时，客户端的 session ticket 支持也会被关闭；SessionTicketsDisabled 可显式关闭 session ticket 和 PSK 恢复支持。因此，先看这两个字段，比盯着 HTTP 状态码更有效。

生产环境怎样保留安全边界

会话恢复减少的是握手成本，不应该以牺牲证书校验为代价。不要为了让示例“成功”而设置 InsecureSkipVerify=true；官方文档明确提醒，这会让客户端接受任意证书链和主机名，除非你同时实现了正确的自定义验证。

如果应用需要审计每次连接是否恢复，可以在 VerifyConnection 中记录 ConnectionState.DidResume。不要把只在完整握手中执行的 VerifyPeerCertificate 当作所有连接都会执行的审计点，因为它不会在恢复连接上被调用；需要覆盖恢复连接时，应使用 VerifyConnection，并避免把证书、会话票据等敏感材料写进日志。

缓存容量也要结合目标域名和并发模型决定。多个目标共享一个缓存通常由标准库按 session key 区分，但应用仍应让它和负责 TLS 配置的客户端一起管理，避免生命周期短于连接池或被无意替换。

几个容易混淆的相关问题

为什么第二次请求成功了，但 DidResume 还是 false？

请求成功只说明 HTTP 事务完成，不等于 TLS 恢复成功。服务端可以接受一次新的完整握手，业务结果照样是 200；请读取对应响应的 resp.TLS.DidResume，并确认第二次请求确实建立了新 TLS 连接。

只复用同一个 tls.Config 就够了吗？

还不够。需要给它配置非 nil 的 ClientSessionCache，并让服务端允许会话恢复。仅仅复用配置但没有缓存，客户端没有地方保存上一次会话状态。

TLS 1.2 和 TLS 1.3 的恢复机制一样吗？

标准库文档说明，TLS 1.2 使用基于 ticket 的恢复；TLS 1.3 则通过 PSK 模式支持恢复。应用层只需要通过 ClientSessionCache 提供缓存，并用 DidResume 观察结果，不应自行解析或拼装会话票据。

结语

遇到 ClientSessionCache 已设置但 DidResume=false 时，先问自己两句：第二次请求是否真的重新握手？缓存是否和第一次连接使用的是同一个长期对象？确认这两点后，再检查 SessionTicketsDisabled、服务端票据、缓存淘汰和配置兼容性。这样既能得到可复用的最小示例，也能把测试观察方式迁移到生产排障中。