能，但仅限静态证书且域名必须出现在证书的 DNSNames 字段中。BuildNameToCertificate 启动时构建域名到证书映射，不支持通配符或动态更新；生产环境应使用 GetCertificate 回调。
tls.Config.Certificates + BuildNameToCertificate 能否直接支持多域名
能，但仅限静态证书且域名必须出现在证书的 DNSNames 字段中。Go 的 tls.Config.BuildNameToCertificate() 会自动扫描 Certificates 切片里每个 tls.Certificate 的 Leaf.DNSNames 和 Leaf.IPAddresses，构建域名到证书的映射表。它不解析 SAN 扩展外的字段，也不支持通配符匹配（如 *.example.com 只匹配一级子域，且必须显式写在证书里）。
常见错误现象：BuildNameToCertificate 后仍返回默认证书或报 x509: certificate is valid for example.com, not api.example.com，大概率是证书本身没包含目标域名——比如你用 OpenSSL 生成时漏了 -addext "subjectAltName=DNS:api.example.com,DNS:example.com"。
使用场景：开发/测试环境托管少量固定域名（如 localhost、test.local、dev.example.org），证书可预先加载进内存或文件。
- 证书文件必须含完整链（终端证书 + 中间证书），拼在同一个 PEM 文件里
- 私钥必须是未加密 PEM 格式（
-----BEGIN PRIVATE KEY-----或-----BEGIN RSA PRIVATE KEY-----），权限 ≤0600 - 调用
BuildNameToCertificate()必须在tls.Config初始化后、http.Server启动前完成，否则无效
GetCertificate 回调才是生产级多域名方案
当域名数量动态变化（如 SaaS 多租户）、证书需热更新（如 Let’s Encrypt 自动续期），就必须用 tls.Config.GetCertificate。它在每次 TLS 握手时被调用，传入 *tls.ClientHelloInfo，你可以根据 ClientHelloInfo.ServerName 查数据库、本地缓存或远程 ACME 服务，返回对应证书。
立即学习“go语言免费学习笔记（深入）”；
为什么不能只靠 Certificates 切片？因为 BuildNameToCertificate 是启动时一次性构建的静态映射，无法响应证书过期、新增域名或密钥轮转。
性能影响：回调函数必须快（建议 ≤10ms），否则拖慢 TLS 握手。避免同步 HTTP 请求或磁盘读取；用内存缓存（如 sync.Map）+ TTL 过期策略。
- 回调返回
nil时，Go 会 fallback 到Certificates[0]（若存在），否则握手失败 - 务必检查
ClientHelloInfo.ServerName非空且合法（防止空字符串或恶意长域名耗尽资源） - 证书加载失败（如文件不存在、解析出错）应记录日志并返回
nil，不要 panic —— 否则整个服务器 TLS 握手卡死
证书加载失败的三个高频坑点
tls.LoadX509KeyPair 或 tls.X509KeyPair 报错，常让服务启动失败或握手静默拒绝。最典型的三个原因：
错误现象：tls: failed to find any PEM data in certificate input —— 私钥或证书文件内容为空、路径错、或格式非 PEM。
错误现象：x509: certificate signed by unknown authority（客户端）或服务端日志无提示 —— 证书文件没包含中间证书，或客户端没加载正确 RootCA。
错误现象：启动成功但浏览器提示“证书不可信”，点开详情发现“颁发给”字段为空或不匹配 —— 证书的 DNSNames 没覆盖访问域名，或用了已废弃的 CommonName 字段。
- 路径基于进程当前工作目录，不是 Go 源码目录；用
os.ReadFile前先os.Stat确认文件存在且可读 - 自签名证书必须显式设置
DNSNames: []string{"example.com"}，不能只设Subject.CommonName - 用
openssl x509 -in cert.pem -text -noout检查证书内容，确认X509v3 Subject Alternative Name区域包含目标域名
http.ListenAndServeTLS 与自定义 http.Server 的选择边界
如果你只需要一个域名、证书不变、不关心 TLS 细节，直接用 http.ListenAndServeTLS(":443", "fullchain.pem", "privkey.pem") 最省事。但它内部封装了 tls.Config，无法启用 SNI、禁用旧协议、或注入 GetCertificate。
一旦涉及多域名、mTLS、协议降级防护、或证书热更新，就必须放弃这个快捷函数，手动构造 http.Server 并传入自定义 *tls.Config。
兼容性注意：Go 1.19+ 默认要求证书含 SAN，且 MinVersion 建议设为 tls.VersionTLS12；若设 tls.VersionTLS10，现代浏览器会直接拒绝连接。
-
http.ListenAndServeTLS的handler参数是全局的，无法按域名分流；多域名场景下，路由逻辑必须在http.Handler内部用r.Host或r.TLS.ServerName判断 - 自定义
http.Server时，别忘了显式调用srv.Close()做优雅退出，否则 TLS 连接可能 hang 住 - 证书热更新（如 CertMagic）本质也是替换
tls.Config.GetCertificate返回值，不是 reload 整个 server
真正难的不是写对 GetCertificate 回调，而是保证每次返回的证书都有效、未过期、私钥可解密、且和域名严格匹配。线上环境建议加一层健康检查：定期用 openssl s_client -connect example.com:443 -servername example.com 验证证书链和 SNI 行为，比等用户投诉更靠谱。
