http.ListenAndServeTLS 启动 HTTPS 服务需同时满足证书 PEM 格式、路径正确、权限严格（如 chmod 600）、内容完整（含中间 CA）四项条件，缺一则握手失败或静默崩溃。
http.ListenAndServeTLS 是最直接的启动方式，但必须同时满足证书格式、路径、权限和内容四项硬性条件，缺一不可。用错任何一个，服务根本起不来，或者连握手都失败。
证书和私钥文件必须是 PEM 格式且顺序/权限正确
Go 的 crypto/tls 只认标准 PEM 封装，不支持 PFX、DER、PKCS#8 加密私钥，也不接受 CRLF 换行符（Windows 默认）。常见静默失败或 panic 报错如 tls: failed to find any PEM data in certificate input，往往不是证书不存在，而是：
- 私钥被加密（比如用
openssl genrsa -aes256生成），需先用openssl rsa -in key.pem.enc -out key.pem去密 - 证书文件里只放了域名证书，没拼中间 CA（如 Let’s Encrypt 的
fullchain.pem必须由cert.pem+chain.pem合并） - 私钥权限太宽：Linux/macOS 下必须
chmod 600 key.pem，否则 Go 直接拒绝加载 - 文件用了 Windows 风格换行（CRLF），需转成 Unix 风格（LF）
为什么直接传两个文件路径经常报 “no certificate found”
http.ListenAndServeTLS 的第二、三个参数确实是两个独立路径（certFile 和 keyFile），但很多人误以为可以合并成一个文件传——其实不能。真正容易出错的是：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 路径写成相对路径（如
"./cert.pem"），但程序工作目录不是你预期的，导致open cert.pem: no such file or directory - 证书文件里混入了私钥（PEM 格式要求证书和私钥严格分离），或私钥文件里混入了证书
- 证书文件虽含完整链，但顺序错了：必须是「服务器证书 → 中间证书」，不能倒过来
- 用
curl -vI https://localhost:8443测试时，没加-k，而本地又没导入自签名 CA，结果卡在 TLS 握手前
需要定制 TLS 行为时必须手动构造 http.Server 并设置 TLSConfig
直接调 http.ListenAndServeTLS 会创建默认 *tls.Config，但无法控制协议版本、密码套件、SNI 或客户端证书校验。一旦要禁用 TLS 1.1、限制椭圆曲线、或做 mTLS，就必须显式构造 http.Server：
-
MinVersion: tls.VersionTLS12必须设，否则默认仍支持 TLS 1.0/1.1，现代扫描工具会标红 - 设
ClientAuth: tls.RequireAndVerifyClientCert时，ClientCAs字段不能空，否则连接直接被拒，日志只显示模糊的tls: bad certificate -
GetCertificate回调是热更新证书的唯一原生方式，但必须保证每次返回非 nil*tls.Certificate，否则握手失败 - 修改
TLSConfig必须在调用srv.ListenAndServeTLS之前完成，之后改无效
HTTP 自动跳转 HTTPS 必须另起一个 :80 server
http.ListenAndServeTLS 只监听 HTTPS 端口，完全收不到 HTTP 请求。想实现 http://→https:// 跳转，必须单独启动一个 HTTP server：
- 监听
:80，用http.Redirect返回http.StatusMovedPermanently（301），不是默认的 302 - 跳转目标 URL 必须写死可信域名（如
"https://example.com" + r.URL.RequestURI()），不能拼r.Host——它可能被篡改 - 若部署在 Nginx / ALB 后，Go 层应关闭 TLS，仅靠
X-Forwarded-Proto判断是否跳转，避免双重 TLS 终止和循环重定向
