Go默认在tls.Config.RootCAs为nil时自动加载系统根证书，但macOS因issue #14514不读Keychain，仅尝试/etc/ssl/cert.pem等固定路径；Linux/Windows行为更一致，而生产环境应显式加载CA证书而非依赖自动机制。
Go 默认怎么加载系统根证书？
Go 的 crypto/tls 在 tls.Config.RootCAs 为 nil 时，会委托标准库自动加载宿主系统的信任根。但这个行为不是统一的：Linux 和 Windows 大致走 OpenSSL 或系统 API 路径；macOS（Darwin）则长期受 Go issue #14514 影响——它跳过 Login 和 System Keychain，只尝试从固定路径（如 /etc/ssl/certs）读取，而多数 macOS 用户的可信证书实际存在 Keychain 中。
如何查当前 Go 进程看到的系统证书路径？
Go 不暴露内部搜索路径列表，但你可以用最小验证代码观察行为：
package main
import (
"crypto/tls"
"fmt"
"log"
)
func main() {
cfg := &tls.Config{}
if cfg.RootCAs == nil {
fmt.Println("RootCAs is nil → will use system roots")
}
// 启动一个 dummy TLS client config 并观察是否 panic
_, err := tls.Dial("tcp", "google.com:443", cfg, nil)
if err != nil {
log.Printf("failed to dial with system roots: %v", err)
// 常见错误如 "x509: certificate signed by unknown authority" 表明加载失败或不全
}
}
更直接的办法是看 Go 源码逻辑：crypto/tls 内部调用 getSystemRoots，其 macOS 实现会尝试以下路径（按顺序）：
/etc/ssl/cert.pem/etc/ssl/certs/ca-certificates.crt-
/usr/local/etc/openssl/cert.pem（Homebrew OpenSSL） -
/opt/homebrew/etc/openssl@3/cert.pem（Apple Silicon Homebrew）
注意：这些只是 fallback 路径，不会自动扫描 Keychain，除非你用 go-rootcerts 这类第三方库显式桥接。
为什么 curl 能通、Go 却报 unknown authority？
这是最常被忽略的兼容性断层。原因包括：
-
curl默认用 libcurl + 系统 SSL backend（如 macOS 的 SecureTransport），能访问 Keychain；Go 默认不访问 - 你的证书在 Keychain 里是“始终信任”，但 Go 根本没读它
- 你改过 Keychain 权限策略（比如设成“由系统决定”），但 Go 不感知该策略
- Go 版本 ≥1.19 后对 SAN 和证书链完整性校验更严格，即使路径对了，缺中间证书也会失败
临时验证方法：把 Keychain 中导出的根证书（PEM 格式）手动追加进 /etc/ssl/cert.pem，再跑上面的 tls.Dial 测试。如果通了，就确认是路径缺失问题。
生产环境别依赖自动加载
系统路径不可控，尤其容器化部署时：/etc/ssl/certs 可能为空、Alpine 镜像用的是 ca-certificates 包、K8s initContainer 可能覆盖证书挂载点。真正可靠的方案是：
- 启动前用
x509.NewCertPool()+AppendCertsFromPEM()显式加载你信任的 CA 文件（如ca-bundle.crt） - 把证书文件打进镜像，或通过 ConfigMap 挂载到固定路径（如
/etc/tls/custom-ca.pem） - 避免用
InsecureSkipVerify: true—— 它绕过整个信任链，连 SNI 和 ALPN 都可能失效
macOS 开发者最容易踩的坑，是以为“系统钥匙串里装了证书，Go 就该认”。其实它不认，而且这个不认是设计使然，不是 bug。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
