生产环境必须禁用InsecureSkipVerify：true，否则等于放弃TLS身份认证，易遭中间人攻击；正确做法是加载自定义CA证书池并保持InsecureSkipVerify为false。
Go HTTP客户端必须禁用 InsecureSkipVerify
生产环境启用 InsecureSkipVerify: true 等于放弃TLS校验，攻击者可轻易中间人劫持。哪怕只是临时调试，也应改用自定义CA证书池替代跳过验证。
常见错误现象：
- 请求返回
x509: certificate signed by unknown authority - 本地测试时直接设
InsecureSkipVerify: true后忘记还原 - 证书链不全（如缺中间CA），导致校验失败但误判为“必须跳过”
正确做法：
- 内网服务用私有CA：读取
internal-ca.crt文件，用x509.NewCertPool()+AppendCertsFromPEM()构建RootCAs - 始终显式设置
MinVersion: tls.VersionTLS12，禁用 TLS 1.0/1.1 - 若需域名匹配校验（如防止通配符证书滥用），保留默认的
ServerName行为，不手动覆盖
Transport 层超时与连接池参数不能只靠 Timeout 字段
http.Client.Timeout 只控制整个请求生命周期，无法细分连接建立、TLS握手、响应读取等阶段。实际线上故障中，大量 goroutine 卡在 connect 或 read 阶段，仅靠 Timeout 无法及时释放。
立即学习“go语言免费学习笔记（深入）”；
关键参数组合：
-
Transport.DialContext：配合net.Dialer.Timeout和KeepAlive控制底层 TCP 连接建立与保活 -
Transport.TLSHandshakeTimeout：单独限制 TLS 握手时长（建议 ≤ 10s） -
Transport.ResponseHeaderTimeout：从发出请求到收到响应头的最大等待时间（防服务端迟迟不发 header） -
MaxIdleConns和MaxIdleConnsPerHost：避免连接池无节制膨胀，尤其在多域名调用场景
示例片段：
transport := &http.Transport{
DialContext: (&net.Dialer{
Timeout: 5 * time.Second,
KeepAlive: 30 * time.Second,
}).DialContext,
TLSHandshakeTimeout: 8 * time.Second,
ResponseHeaderTimeout: 10 * time.Second,
MaxIdleConns: 100,
MaxIdleConnsPerHost: 100,
IdleConnTimeout: 90 * time.Second,
}数据库连接也要走 TLS，但配置位置和 HTTP 不同
MySQL/PostgreSQL 的 TLS 不由 http.Transport 控制，而是在 DSN（Data Source Name）里通过参数开启，且驱动行为差异大。
MySQL（go-sql-driver/mysql）：
- DSN 中加
&tls=custom，再用mysql.RegisterTLSConfig("custom", config)注册自定义*tls.Config - 不能只写
&tls=true—— 默认会使用系统 CA，内网环境大概率失败 - 若证书是自签，必须把 CA 证书内容传给
RootCAs，且InsecureSkipVerify仍要设为false
PostgreSQL（jackc/pgx）：
- DSN 使用
sslmode=require或更严格sslmode=verify-full - 对应提供
sslrootcert（CA路径）、sslcert（客户端证书）、sslkey（私钥）参数 - 注意私钥权限：Linux 下必须是
0600，否则pgx直接 panic 报错invalid key pair
ACL 认证和 TLS 要分层配置，不能混为一谈
RocketMQ、Kafka 等中间件的 Go 客户端常同时支持 ACL（身份认证）和 TLS（链路加密），但二者作用域和配置入口完全不同。误以为开了 TLS 就自动带认证，或把 AccessKey 塞进 TLS 配置里，都会导致连接被拒绝。
典型错误：
- 只配了 TLS 加密，没传
AccessKey/SecretKey，Broker 返回NO_PERMISSION - 把 SecretKey 当作 TLS 私钥加载，结果
crypto/tls解析失败报tls: failed to find any PEM data - ACL 签名计算依赖时间戳，客户端系统时间偏差 > 5 分钟会导致签名失效，但错误信息常被吞掉，只显示连接超时
务必确认：
- ACL 凭据通过客户端构造函数的
.WithCredentials()显式注入（如 RocketMQ 的primitive.Credentials） - TLS 配置走独立的
.WithTLSConfig()或 Transport 层，与认证逻辑完全解耦 - 所有涉及时间的认证机制，必须同步客户端和服务端 NTP 时间（误差建议
真正容易被忽略的是：TLS 配置生效的前提是证书路径可读、格式合法、私钥未加密、时间同步准确——四个条件缺一不可，而其中任意一个失败，错误提示都可能被上层库静默吞掉或映射成泛泛的 “connection refused” 或 “timeout”。
