Go 1.16+ 可用 autocert 包自动对接 Let’s Encrypt 实现 HTTPS，需开放 80 端口响应 HTTP-01 挑战、配置 HostPolicy/Cache/Prompt，并分离 HTTP 与 HTTPS 服务端口；本地应使用 staging 环境避免限速。
Go 1.16+ 内置 autocert 包能直接对接 Let’s Encrypt，无需手动申请或轮换证书
Go 标准库的 golang.org/x/crypto/acme/autocert 提供了开箱即用的 HTTPS 自动配置能力，核心是自动完成 ACME 协议交互、域名验证、证书获取与续期。它不依赖外部服务进程（如 certbot），整个流程由 Go 程序自身驱动。
关键前提：你的服务必须能响应 Let’s Encrypt 的 HTTP-01 挑战，即 :80 端口需可被公网访问（哪怕只用于验证），且域名 DNS 已正确解析到该服务器 IP。
-
autocert.Manager负责管理证书生命周期，必须提供Prompt（接受 Let’s Encrypt 服务条款）、HostPolicy（限制哪些域名可申请）和Cache（持久化证书，否则每次重启都重申请） - 不能把
autocert.Manager和http.Server绑定在同一个端口上监听 TLS；标准做法是：HTTP 服务跑在:80处理挑战，HTTPS 服务跑在:443处理加密流量 - 本地开发或内网测试时，切勿直接使用生产环境的
acme-v02.api.letsencrypt.org，应改用acme-staging-v02.api.letsencrypt.org，避免触发速率限制
如何配置 autocert.Manager 并启用 HTTPS 服务
以下是最小可用配置，含必要校验和容错处理：
package main
import (
"log"
"net/http"
"golang.org/x/crypto/acme/autocert"
)
func main() {
m := autocert.Manager{
Prompt: autocert.AcceptTOS,
HostPolicy: autocert.HostWhitelist("example.com", "www.example.com"),
Cache: autocert.DirCache("./certs"), // 必须可写，且保留跨重启
}
// HTTP server for ACME challenges (required)
go func() {
log.Fatal(http.ListenAndServe(":80", m.HTTPHandler(nil)))
}()
// HTTPS server
srv := &http.Server{
Addr: ":443",
Handler: http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
w.Write([]byte("OK"))
}),
TLSConfig: &tls.Config{
GetCertificate: m.GetCertificate,
},
}
log.Println("HTTPS server starting on :443")
log.Fatal(srv.ListenAndServeTLS("", ""))
}
-
m.HTTPHandler(nil)返回一个专用于响应/.well-known/acme-challenge/的 handler，不要把它塞进你自己的路由中间件里 -
DirCache是最简单缓存方式，但要注意：目录权限需允许 Go 进程读写；若部署在容器中，该目录必须挂载为持久卷 -
TLSConfig.GetCertificate是关键钩子，让 Go 在需要时从autocert.Manager拉取证书，而不是靠ListenAndServeTLS传入固定文件
常见失败现象及对应检查点
证书申请卡住、返回 404 或连接被拒绝，大概率不是代码问题，而是环境或配置偏差：
立即学习“go语言免费学习笔记（深入）”；
- 访问
http://yourdomain.com/.well-known/acme-challenge/test返回 404 → 检查:80是否真正在运行，防火墙是否放行，反向代理（如 Nginx）是否拦截了/.well-known/路径 - 日志出现
error getting certificate+timeout→ Let’s Encrypt 无法从公网访问你的:80端口，确认域名解析生效（dig A yourdomain.com）、端口未被云厂商安全组屏蔽 - 首次申请成功，但过几天 HTTPS 访问变回 HTTP →
DirCache目录被清空或权限丢失，导致续期失败后 fallback 到无证书状态 - 本地
curl -k https://localhost:443报证书无效 → 正常，Let’s Encrypt 不签发localhost或私有 IP，仅限已注册的公开域名
生产环境必须注意的细节
自动配置不等于零维护，尤其在高可用或灰度发布场景下：
- 多个实例共用同一
DirCache目录会引发竞态，应使用分布式缓存（如 Redis）实现autocert.Cache接口，或通过统一证书中心分发 - 证书更新是后台异步进行的，
GetCertificate可能短暂返回旧证书；若业务对证书时效敏感（如强制最新 OCSP stapling），需监听m.Notify()通道做热重载 - Let’s Encrypt 证书有效期为 90 天，
autocert默认在过期前 30 天尝试续期；若某次续期失败，它不会立即报错，而是在下次 TLS 握手时才触发重试 —— 所以监控应覆盖autocert.Manager的日志输出，而非只看服务是否启动
最易被忽略的一点：ACME 流程全程依赖系统时间准确，NTP 同步失效会导致证书签名验证失败，表现为“证书尚未生效”或“已过期”，即使证书文件本身没问题。
