Go二进制默认静态链接、零外部依赖，但需警惕隐性环境依赖：cgo启用、外部命令调用、硬编码系统路径、TLS证书查找、DNS解析及嵌入资源管理。
为什么 go build 产出的二进制默认已自包含
Go 编译出的可执行文件默认是静态链接的，运行时不依赖系统 libc、不依赖 glibc 或 musl，连 CGO_ENABLED=0 都不是必须项——只要没显式启用 cgo，就天然零外部依赖。真正需要警惕的是你主动引入的“外部”：比如调用 exec.Command("curl")、读取 /etc/ssl/certs、硬编码 /usr/bin/python3 路径，或者用了 net/http 却忘了证书路径可能随系统变化。
- 检查是否启用了 cgo：
go env CGO_ENABLED，值为1时才可能带动态依赖 - 确认没调用外部命令：grep -r "exec.Command\|os.StartProcess" ./
- 避免读写固定系统路径：用
os.UserConfigDir()或传参替代硬编码/etc或/usr/share
net/http 和 TLS 证书的隐性依赖怎么破
Go 的 net/http 默认会尝试加载系统 CA 证书（如通过 crypto/tls 调用 getSystemRoots），但行为因平台而异：Linux 上找 /etc/ssl/certs，macOS 走 Keychain，Windows 查注册表。一旦找不到，http.Client 发 HTTPS 请求就会报 x509: certificate signed by unknown authority，这不是代码 bug，而是部署环境缺失信任链。
- 最稳方案：用
http.DefaultTransport.(*http.Transport).TLSClientConfig.RootCAs显式加载 embed 的证书 bundle - 证书来源推荐
github.com/golang/go/src/crypto/tls/testdata/cert.pem（仅测试）或更可靠的github.com/mozilla/certificates（需 embed） - 构建时加
-tags netgo强制走纯 Go DNS 解析，避免 libcgetaddrinfo带来的不确定性
如何把配置、模板、静态资源打包进二进制
Go 1.16+ 的 embed 是唯一正解。别再把 config.yaml 放目录里靠 os.ReadFile("config.yaml") 加载——那等于放弃“自包含”。embed.FS 不只是藏文件，它让资源成为类型安全、编译期校验的一部分。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 声明嵌入：
//go:embed config.yaml templates/* static/js/*.js紧跟var content embed.FS - 读取时用
content.ReadFile("config.yaml")，不是os.ReadFile；路径是 embed 注释里写的相对路径，不是运行时当前目录 - 注意：嵌入的文件在编译时固化，修改需重新 build；调试阶段可用
build tags切换本地文件读取模式
交叉编译时怎么确保不混入宿主系统特性
GOOS=linux GOARCH=amd64 go build 看似干净，但如果项目里有 // +build darwin 的文件、或依赖了 golang.org/x/sys/unix 中非通用接口，就可能漏掉条件编译错误，导致目标平台 panic。更隐蔽的是：某些第三方库（比如日志库）会根据 GOOS 自动启用不同后端（syslog vs local file），而 syslog 在容器里根本不可用。
立即学习“go语言免费学习笔记（深入）”；
- 构建前先清理环境：
export CGO_ENABLED=0，再执行交叉编译 - 验证产物依赖：
ldd your-binary应输出not a dynamic executable - 用
file your-binary确认是ELF 64-bit LSB executable, x86-64类型，且不含 interpreter 行
真正的难点不在“怎么打包”，而在识别那些看似无害、实则偷偷伸手要环境的代码——比如一个 time.LoadLocation("Asia/Shanghai") 会去读 /usr/share/zoneinfo，而这个路径在 Alpine 容器里压根不存在。这类问题不会在 go build 阶段报错，只会在第一次运行时崩给你看。
