Go HTTP客户端生产环境必须禁用InsecureSkipVerify，显式配置tls.Config启用证书验证，并设置MinVersion≥TLS1.2、安全加密套件及RootCAs（内网自签CA时），否则面临中间人攻击风险。
http.Client 默认不验证 TLS 证书，生产环境直接用会暴露在中间人攻击下。必须显式配置 tls.Config 并禁用 InsecureSkipVerify。
Go HTTP 客户端 TLS 验证必须关闭 InsecureSkipVerify
常见错误是测试阶段设 InsecureSkipVerify: true 后忘记改回，上线即高危。这个字段一旦为 true，客户端会接受任意服务器证书（包括自签名、过期、域名不匹配的），等于裸奔。
- 永远不要在生产代码中写
InsecureSkipVerify: true；CI/CD 流水线可加静态检查规则拦截 - 若对接内网自签 CA，需显式加载根证书到
RootCAs字段，不能靠系统证书池（尤其 Alpine 容器） -
MinVersion至少设为tls.VersionTLS12，TLS 1.0/1.1 已被 NIST 禁用 - 加密套件建议锁定
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256等 AEAD 类型，避免 CBC 模式漏洞
连接超时必须分层设置，不能只靠 client.Timeout
client.Timeout 是总超时，但网络异常常卡在连接建立或响应读取阶段，单靠它无法防止 goroutine 泄漏或连接池耗尽。
- 用
http.Transport显式控制：设.DialTimeout（连接建立）、ResponseHeaderTimeout（等待响应头）、ReadTimeout（读响应体） -
MaxIdleConns和MaxIdleConnsPerHost必须设具体值（如 100），否则默认为 0（无限），易打爆服务端连接数 -
IdleConnTimeout建议 90 秒，太短导致频繁重连，太长让空闲连接占用服务端资源 - 所有超时值建议统一用
time.Second单位，避免30 * time.Second写成30 * time.Millisecond
PostgreSQL 连接字符串里 sslmode=verify-full 不是摆设
用 lib/pq 或 pgx 连 PostgreSQL 时，仅写 sslmode=require 不够——它只加密，不校验证书。真正防中间人必须用 sslmode=verify-full，且配套提供 sslrootcert 路径。
-
sslmode=verify-full会校验证书签名、域名、有效期三者，缺一不可 -
sslrootcert必须指向 PEM 格式 CA 证书文件，不能是目录或空字符串 - 若用自建 CA，在容器中挂载证书后，路径要写绝对路径（如
/etc/ssl/certs/internal-ca.crt），相对路径容易失败 - DSN 中避免明文密码，优先用
url.User构造或从环境变量注入，防止日志泄露
RabbitMQ amqp091-go 的 TLS 配置和 HTTP 不是一回事
amqp091-go 的 TLS 设置不在 http.Transport 里，而是通过 amqp.DialConfig 的 TLSClientConfig 字段传入，且部分参数行为不同。
- 必须用
amqp.DialConfig替代amqp.Dial，否则TLSClientConfig不生效 -
ServerName字段必须显式设置（如"rabbitmq.example.com"），否则 SNI 扩展不发，证书域名校验失败 - AMQP 协议没有
ResponseHeaderTimeout这类概念，超时靠amqp.Config.ConnectionTimeout控制握手阶段，业务层需自行加 context.WithTimeout 包裹 publish/consume - 若启用了 RabbitMQ 的
verify_peer（mTLS），客户端还得提供Certificates字段，不只是RootCAs
实际部署时最容易被忽略的是：证书路径是否真实可读、ServerName 是否与证书 SAN 匹配、以及 amqp 和 http 客户端各自独立的超时体系——它们不会共享同一套配置逻辑。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
