Go 的 http.ListenAndServe 不能自动支持 HTTPS 跳转，因其仅处理明文 HTTP，而 HTTPS 依赖 TLS 层解密，协议分离且无内置跳转机制，必须手动启两个服务分别监听 HTTP 和 HTTPS 端口并实现 301 重定向。
Go 服务无法自动把 HTTP 请求重定向到 HTTPS，必须手动监听两个端口并显式返回 301 响应。
为什么 http.ListenAndServe 不能直接支持 HTTPS 跳转
Go 标准库的 http.Server 是协议无关的：它只处理已解密的 HTTP 流量。HTTPS 在 TLS 层完成，而 HTTP 跳转是应用层逻辑，两者不在同一监听点上。你不能让一个 http.ListenAndServe 同时跑 HTTP 和 HTTPS，更不能让它“自动升级”协议。
-
http.ListenAndServe只监听 HTTP（明文） -
http.ListenAndServeTLS只监听 HTTPS（需证书） - 没有内置中间件或配置项能“强制跳转”，必须自己启动两个服务、互相协作
如何用两个 goroutine 分别监听 HTTP 和 HTTPS 端口
典型做法是：HTTP 服务监听 :80，收到请求后一律 301 跳转到 https://$host:$request_uri；HTTPS 服务监听 :443，正常处理业务。
关键点：
立即学习“go语言免费学习笔记（深入）”；
- HTTP 服务里必须用
r.Host拼接目标 URL，不能硬编码域名（否则多租户或反代场景会出错） - 跳转响应要设
Content-Type为空或text/plain，避免某些客户端解析 HTML 体导致重定向延迟 - 不要在 HTTPS 服务里再做跳转判断——那毫无意义，且可能引发循环
示例片段：
// HTTP 跳转服务（:80）
go func() {
http.ListenAndServe(":80", http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
target := "https://" + r.Host + r.URL.RequestURI()
http.Redirect(w, r, target, http.StatusMovedPermanently)
}))
}()
// HTTPS 主服务（:443）
http.ListenAndServeTLS(":443", "cert.pem", "key.pem", handler)
反向代理（如 Nginx）存在时，r.Host 和 r.TLS 可能失效
如果 Go 服务前面有 Nginx 或 Cloudflare，真实 HTTPS 是由它们终止的，Go 收到的是纯 HTTP 请求，r.TLS 为 nil，r.Host 也可能是代理 IP 或内部域名。
此时必须依赖代理设置的头信息：
- 确认代理转发了
X-Forwarded-Proto: https和X-Forwarded-Host - 在跳转逻辑中改用：
proto := r.Header.Get("X-Forwarded-Proto")，只对proto == "http"的请求跳转 - 拼接目标 URL 时用
r.Header.Get("X-Forwarded-Host")替代r.Host - 务必校验这些 header 是否可信（比如只接受来自内网代理的请求，或配置
TrustedProxies）
证书热更新与端口占用冲突的常见问题
开发时容易把 :443 写死在代码里，然后发现 macOS/Linux 需 root 权限才能绑定 443，或者端口被其他进程占用了。
- 本地调试建议用
:8443替代:443，并在跳转 URL 中显式写端口（https://localhost:8443/...） - 生产环境若需 443，不要用 root 启动 Go 进程，而是用
setcap 'cap_net_bind_service=+ep' ./yourapp授权 - 证书更新时，
ListenAndServeTLS不支持热重载，需重启或改用http.Server+ 自定义TLSConfig.GetCertificate回调 - 两个监听 goroutine 中任一 panic 会导致整个进程退出，建议加
recover或用errgroup.Group统一管理生命周期
真正麻烦的不是写几行跳转代码，而是搞清流量路径上到底谁在终止 TLS、谁在传 header、谁在做负载均衡——这些决定了你该信哪个 host、该不该跳、跳到哪。漏掉一层代理的 header 配置，就可能让跳转指向错误端口或域名，而且很难复现。
