ListenAndServeTLS的certFile必须包含按序拼接的域名证书和中间证书，不可仅含域名证书或分开加载；根证书禁止加入，私钥保持独立且未加密。
ListenAndServeTLS 传入的 certFile 必须含中间证书
Go 的 http.Server.ListenAndServeTLS(certFile, keyFile) 不会自动补全证书链，它只读取 certFile 文件里的 PEM 块，并按顺序发送给客户端。如果该文件只含你的域名证书（如 myalcoholist.pem），浏览器就无法向上追溯到可信根 CA，SSL Labs 会直接标为 “Incomplete chain”，评级掉到 B 级。
常见错误是把 GoDaddy 提供的 sf_bundle-g2-g1.crt 单独加载进 ClientCAs 或忽略不用——这完全无效，ClientCAs 只影响客户端证书校验，和服务端证书链无关。
- 必须将域名证书和中间证书拼成一个文件，例如：
cat myalcoholist.pem sf_bundle-g2-g1.crt > fullchain.pem - 顺序不能错：先放
myalcoholist.pem（Leaf），再追加中间证书（Intermediate） - 根证书（Root CA）不要放进这个文件——现代系统已内置信任，加了反而触发 SSL Labs “Contains anchor” 警告
- 私钥仍用原
myalcoholist.key，不参与拼接
tls.LoadX509KeyPair 不接受分开加载中间证书
试图对中间证书单独调用 tls.LoadX509KeyPair(intermediate.crt, myalcoholist.key) 会 panic，报错类似 certificate doesn't match private key 或 x509: certificate specifies an incompatible key usage。因为中间证书的公钥根本不是由你的私钥签发的，数学上就不匹配。
tls.LoadX509KeyPair 的语义非常严格：它只接受一对能互相验证的证书+私钥。中间证书没有、也不该有你持有的私钥。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法是只调用一次
tls.LoadX509KeyPair("fullchain.pem", "myalcoholist.key") -
fullchain.pem是纯证书拼接（无私钥），myalcoholist.key是唯一私钥文件 - 若需自定义
http.Server.TLSConfig，直接把返回的tls.Certificate赋给TLSConfig.Certificates字段即可
证书文件格式与换行符容易被忽略
即使内容拼对了，文件格式出问题也会导致 TLS 启动失败或链验证异常。Go 的 crypto/tls 对 PEM 解析很敏感，尤其在跨平台部署时。
- 所有行必须是 Unix 换行符（LF），Windows 的 CRLF 会导致解析中断，静默跳过后续证书块
- 不能有 BOM、空行、注释行或额外空格；每个证书块必须以
-----BEGIN CERTIFICATE-----开头、-----END CERTIFICATE-----结尾 - 私钥文件权限必须是
0600（Linux/macOS），否则LoadX509KeyPair会拒绝加载 - 可用
file fullchain.pem和hexdump -C fullchain.pem | head快速检查换行和 BOM
Nginx 作为反向代理时仍要传 fullchain.pem
即使 Go 服务前面套了 Nginx，只要 Nginx 是终止 TLS（即做 SSL offload），那 Nginx 自己的 ssl_certificate 配置也得指向拼好的 fullchain.pem，而不是仅域名证书。否则浏览器从 Nginx 收到的仍是断裂链。
此时 Go 服务可退为 HTTP，但 Nginx 的配置错误仍会让终端用户看到证书警告——这个问题常被误判为 Go 代码问题。
- Nginx 配置片段：
ssl_certificate /path/to/fullchain.pem;，不是myalcoholist.pem -
ssl_certificate_key仍指向原始私钥文件 - 无需在 Nginx 中设置
ssl_trusted_certificate来补链——那是用于 OCSP stapling 或客户端证书验证的，和服务端链无关
crypto/tls 里都是走不通的。 
