insecureskipverify: true会彻底禁用tls证书链校验，不验证签名、根ca、域名和有效期，仅用于测试；生产环境启用将导致中间人攻击风险，正确做法是加载自定义ca并保持insecureskipverify为false。
crypto/tls.Dial 的 InsecureSkipVerify 是什么行为
InsecureSkipVerify: true 不是“跳过某一步验证”，而是彻底禁用整个 TLS 证书链校验流程：不检查证书签名、不追溯根 CA、不比对域名（ServerName）、不验证有效期。它让 tls.Dial 在收到任意证书（包括空证书、自签名、伪造证书）时都直接进入密钥交换阶段。
这个字段只作用于客户端侧的证书验证逻辑，不影响服务端行为，也不改变加密强度——连接仍是加密的，但你完全无法确认对方身份。
开发调试环境为什么常设 InsecureSkipVerify=true
本地快速验证业务逻辑时，你往往只关心“能不能通”，而非“是不是它”。常见场景包括：
- 用
mkcert或openssl生成的自签名证书跑本地 WSS/HTTPS 服务 - 对接尚未部署正式证书的测试网关或 IoT 设备
- CI 流水线中临时拉起 mock server 进行集成测试
此时设 InsecureSkipVerify: true 能绕过 x509: certificate signed by unknown authority，避免阻塞开发节奏。但必须确保：该配置仅存在于非生产构建中，且不能通过环境变量、配置文件等意外泄露到线上。
线上环境启用 InsecureSkipVerify 的真实后果
生产环境启用 InsecureSkipVerify: true 等价于主动放弃 TLS 的身份认证能力。攻击者只需在网络路径上做一次中间人（比如劫持 DNS 或 BGP），就能：
- 伪造目标域名的证书（无需私钥，用任意自签名即可）
- 解密并篡改全部请求/响应内容（如 token、密码、支付参数）
- 向客户端注入恶意 payload，而客户端毫无感知
Go 官方文档明确标注该字段为 “for testing only”。Kubernetes、PCI DSS、等保2.0 等合规框架均禁止此类配置。一旦上线，它不是“隐患”，而是已确认的攻击面。
真正安全的替代路径：加载自定义 CA 而非关闭验证
要连内网 WSS 或私有 HTTPS 服务，正确做法是把你的根 CA（internal-ca.crt）加入信任池，而不是关掉验证。关键点：
- 用
x509.NewCertPool()创建空池，再用AppendCertsFromPEM()加载 PEM 内容 -
RootCAs字段必须非 nil，否则仍会 fallback 到默认 Mozilla 根证书集 - 若服务端证书 SAN 不含访问域名，
ServerName字段必须显式设置，否则握手失败报x509: certificate is valid for xxx, not yyy - Go 1.21+ 支持
GOCERTIFICATEPATH环境变量自动加载系统外 CA，但需确保路径下只有.crt或.pem文件且可读
最易被忽略的是：加载 CA 后仍需保留 InsecureSkipVerify: false（默认值），否则前面所有努力都无效。
