InsecureSkipVerify: true 会彻底禁用 TLS 证书链校验，仅限本地调试使用；生产环境启用等于放弃身份认证，必须通过条件编译隔离，并用自定义 CA 和显式 ServerName 实现安全连接。
InsecureSkipVerify: true 是唯一能跳过证书验证的开关，但它不是“跳过某一步”，而是彻底禁用整个 TLS 证书链校验——包括签名、根 CA、域名（ServerName）、有效期。它只该出现在本地调试中，生产环境启用等于主动放弃身份认证能力。
什么时候真需要 InsecureSkipVerify: true
你不是“想跳过”，而是被现实卡住：自签名证书跑本地 WSS、对接还没配正式证书的测试网关、CI 里拉起 mock server 做集成测试。这些场景下，x509: certificate signed by unknown authority 会直接阻断流程。
- 必须确保该配置仅存在于非生产构建中——不能通过环境变量、配置文件或命令行参数意外带到线上
- Go 编译时可用
//go:build !prod条件编译隔离逻辑 - 若用
http.DefaultTransport，记得只改临时实例，别污染全局
为什么不能只靠 InsecureSkipVerify 做安全扫描或灰度调试
设了 InsecureSkipVerify: true 后，resp.TLS 字段为空，你拿不到任何证书信息。想检查是否过期、是否自签名、SAN 是否含目标域名？根本无从下手。
- 正确做法是接管
http.Transport.DialTLS，用tls.Dial手动建连，再调conn.ConnectionState()拿到原始PeerCertificates - 校验逻辑可复用
x509.CertPool.Verify，传入你信任的根池，得到验证链和错误 - 这样一次连接就完成“连得上 + 看得清”，不用二次请求，也不暴露给中间人
替代 InsecureSkipVerify 的真正安全路径
要连内网 HTTPS 或私有 WSS，加载自定义 CA 才是正解。空的 RootCAs 字段会让 Go fallback 到系统默认根证书集（在 Alpine 或 scratch 镜像里压根不存在）。
- 用
x509.NewCertPool()创建新池，再用AppendCertsFromPEM(data)加载你的internal-ca.crt -
tls.Config.ServerName必须显式设置为访问域名，否则 SNI 不发，且证书域名比对失败报x509: certificate is valid for xxx, not yyy - 如果服务端证书没配 SAN 或只配了 IP，
ServerName得设成 IP，但此时需额外在VerifyPeerCertificate回调里手动放宽 DNSNames 检查
最常被忽略的一点：InsecureSkipVerify 关的是客户端验证，不影响加密强度——连接仍是加密的，但你完全无法确认对方是不是你要连的那个服务。这不是“差不多安全”，而是身份可信性归零。生产代码里搜到它，就得立刻删掉，连注释都别留。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
