Go服务端必须用自定义http.Server+tls.Config才能控制TLS版本；MinVersion和MaxVersion须同时设置，仅设MinVersion会导致行为不明确且存在兼容风险。
Go 服务端不能靠 http.ListenAndServeTLS 控制 TLS 版本，必须用自定义 http.Server + tls.Config 才能生效。
MinVersion 和 MaxVersion 必须同时设值
只设 MinVersion 不设 MaxVersion 是常见错误。Go 默认 MaxVersion 为 0（即“不限制”），实际会取当前运行时支持的最高版本（如 tls.VersionTLS13），但行为不明确，且未来可能引入 TLS 1.4 导致意外兼容问题。
-
MinVersion和MaxVersion必须成对出现，且满足MinVersion - 禁用 TLS 1.0/1.1 的最小安全配置是：
MinVersion: tls.VersionTLS12+MaxVersion: tls.VersionTLS13 - 拼错常量名（比如写成
tls.TLS12或tls.VersionTLS1.2）会导致编译失败；Go 中只有tls.VersionTLS12这种形式 -
tls.VersionSSL30、tls.VersionTLS10、tls.VersionTLS11已被标记为 cryptographically broken，不应再启用
客户端连老系统时 MinVersion 得往低设
有些遗留系统（如老旧监控设备、私有中间件）只支持 TLS 1.0，而 Go 1.16+ 默认 MinVersion 是 tls.VersionTLS12，直接导致 tls: no supported version satisfy MinVersion and MaxVersion 错误。
- 遇到这类报错，先用
curl --tls1.0 https://target验证是否真只支持 TLS 1.0 - 若确认，客户端侧需显式设为：
MinVersion: tls.VersionTLS10+MaxVersion: tls.VersionTLS10 - 服务端一般不需降级，除非你明确要兼容这类客户端——但应评估风险，避免暴露弱协议
http.ListenAndServeTLS 里的 tls.Config 参数完全被忽略
这个函数内部硬编码构造了一个 *tls.Config，你传进去的证书路径之外的所有字段（包括 MinVersion、CipherSuites、PreferServerCipherSuites）全被丢弃。
- 它只适合本地开发或临时测试，生产环境必须绕过它
- 正确路径：自己 new 一个
http.Server，把自定义tls.Config赋给其TLSConfig字段 - 哪怕只是想监听裸 TLS（如用
tls.Listen），也必须传入完整配置的*tls.Config，不能只传证书
最容易被忽略的是：MaxVersion 不设就等于“放手不管”，而 TLS 协商结果取决于两端能力交集——服务端没锁死上限，就可能在升级 Go 版本后意外启用新协议，引发下游客户端握手失败。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
