根本原因是cgo_enabled=1时go mod tidy不校验c工具链兼容性，仅验证go包依赖；构建成功但目标平台缺少对应c库（如libssl.so）或syscall支持，导致运行时报错。
交叉编译时 go mod tidy 没报错，但构建出来的二进制在目标平台跑不起来——这不是模块管理失效，而是依赖解析和实际运行环境脱节了。根本原因在于：Go 模块系统只管“能不能编译通过”，不管“链接后有没有对应 C 库”或“目标系统有没有那个 syscall”。
CGO_ENABLED=1 时，go mod 不会校验 C 工具链兼容性
Go 模块本身不感知 C 头文件、静态库或动态库路径。当你设 CGO_ENABLED=1 并交叉编译，go mod tidy 仍只检查 Go 包依赖是否可下载、版本是否合法，完全不验证 CC 是否可用、CGO_CFLAGS 指向的头文件是否存在、CGO_LDFLAGS 里的 -lssl 在目标 sysroot 里有没有对应 libssl.a。
- 典型现象：
go build成功，但目标机器上执行时报./myapp: error while loading shared libraries: libssl.so.1.1: cannot open shared object file - 真正出问题的是链接阶段被忽略的 C 依赖，不是 Go 模块缺失
-
go list -m all看不到任何异常，因为所有 Go 包都 resolve 成功了 - 验证方式：加
-x参数看构建日志里gcc和ld的实际调用路径和参数
私有模块 + 交叉编译 = GOPRIVATE 必须显式配置
如果项目用了公司内网 Git 的私有模块（比如 git.internal.company.com/go/libfoo），而你又在 macOS 或 x86_64 Linux 上交叉编译到 ARM Linux，go mod tidy 默认会走 GOPROXY（如 proxy.golang.org），导致私有模块拉取失败或跳过 —— 这看起来像“依赖丢失”，其实是网络策略拦截。
- 必须提前设置
GOPRIVATE=git.internal.company.com/*，否则go mod会拒绝从私有源解析模块 - CI 环境尤其容易漏掉这个，本地能过，CI 构建就卡在
unknown revision - 若用
replace指向本地路径（如replace git.internal.company.com/go/libfoo => ./libfoo），要确认该路径下确实有go.mod，且内容与目标平台兼容（比如没硬编码 x86 汇编） -
go mod download -x可以单独触发模块下载并打印调试信息，比tidy更早暴露私有源问题
GOOS/GOARCH 切换后，某些包会自动降级或禁用
不是所有 Go 包都无条件支持全平台。比如 golang.org/x/sys/unix 在 GOOS=linux 下提供完整 syscall 封装，但在 GOOS=windows 下部分函数不可用；更隐蔽的是，像 github.com/mattn/go-sqlite3 这类含 C 的包，在 CGO_ENABLED=0 时会 fallback 到纯 Go 实现（如果有），但功能可能受限或直接 panic。
- 检查方式：
go list -f '{{.ImportPath}}: {{.GoFiles}} {{.CgoFiles}}' github.com/mattn/go-sqlite3，看CgoFiles是否为空 - 交叉编译前务必确认目标平台是否支持该包的 C 部分：ARM64 的 musl 工具链未必带
libz，而 sqlite3 编译时默认依赖它 - 避免靠猜：用
go build -a -x -o /dev/null . 2>&1 | grep -E "(gcc|ld|sqlite)"直接观察构建链中是否真调用了 C 编译器 - 如果发现某包在目标平台被静默忽略（比如
import _ "net/http/pprof"在GOOS=js下无效），得换替代方案，而不是指望go mod提醒你
最易被忽略的点是：模块依赖图和运行时符号表之间没有自动对齐机制。你得自己确保 CGO_CFLAGS 和 CGO_LDFLAGS 覆盖了所有 C 依赖的头文件与库路径，而 go mod 对此完全沉默。
