go111module=off时无法使用go modules功能，依赖解析退回到gopath模式，导致replace/require失效、cgo静态库路径不可控；cgo_enabled=0则完全忽略#cgo ldflags指令，不调用gcc也不链接库。
GO111MODULE=off 时根本无法引入静态链接库
Go 模块模式关闭时，go build 会退回到 GOPATH 模式，此时 cgo 的 #cgo LDFLAGS 和 #cgo CFLAGS 仍可工作，但所有依赖路径解析都绕过模块系统——这意味着你无法用 replace 或 require 控制本地 C 库的构建上下文，更没法保证 .a 文件被正确发现。强行在 GOPATH 模式下混用 CGO_LDFLAGS 容易出现 ld: cannot find -lxxx 或静默跳过链接。必须确保 GO111MODULE=on（或 auto，且项目不在 GOPATH 中）。
CGO_ENABLED=0 会直接禁用所有 cgo 静态库链接
只要设了 CGO_ENABLED=0，哪怕代码里写了 /* #cgo LDFLAGS: -L/path/lib -lmylib */，go build 也会完全忽略这些指令，且不报错。编译器不会调用 gcc，也不会传递任何 -l 参数。常见误操作是为“纯 Go 构建”临时关掉 CGO，结果导致依赖 C 静态库的功能直接失效。验证是否生效：加 go build -x，若输出中没出现 gcc 调用和 -lmylib，说明已被跳过。
CGO_LDFLAGS 必须用绝对路径，且不能依赖环境变量展开
CGO_LDFLAGS 中的 -L 和 -l 不支持 shell 变量展开（比如 -L$HOME/lib 无效），也不接受相对路径（-L./lib 在 go build 时会被忽略）。必须写成完整绝对路径：
CGO_LDFLAGS="-L/home/you/mylib/lib -lmylib"- Windows 下需用反斜杠或正斜杠均可：
CGO_LDFLAGS="-LC:/dev/mylib/lib -lmylib" - 路径中不能含空格，否则需额外转义（实际建议避免空格路径）
同时，libmylib.a 必须满足：符号完整（无未定义引用）、架构匹配（如 Linux amd64 编译的 .a 不能用于 darwin/arm64）、且不含与 Go 运行时冲突的全局符号（如重复定义 main 或 malloc）。
GOPRIVATE 对 C 静态库无影响，但影响其 Go 封装模块的拉取
如果你把 C 静态库封装成一个 Go 模块（比如 github.com/yourorg/cwrapper），并在其中用 cgo 调用 libmylib.a，那么 GOPRIVATE 只控制该 Go 模块本身的下载行为（绕过代理、跳过校验），不影响 CGO_LDFLAGS 解析。但若该模块依赖私有 Git 地址，不设 GOPRIVATE=github.com/yourorg/*，go get 会失败，导致整个封装模块无法构建。此时 GOPRIVATE 是前置条件，不是链接开关。
真正容易被忽略的是：C 静态库的 ABI 兼容性不归 Go 管，go build 不做校验。哪怕 libmylib.a 是用旧版 glibc 编译的，而目标机器只有新 glibc，运行时才会崩溃——构建阶段一切正常。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
