go默认静态链接，仅当启用cgo_enabled=1且明确依赖系统共享库（如libpq）时才需通过-ldflags '-extldflags "-shared"'启用动态链接，否则应坚持默认静态模式。
go build 默认根本不是动态链接
Go 编译器默认生成的是完全静态链接的二进制，连 libc 都打包进去了——它压根不走系统 ld.so 加载路径。所谓“开启动态链接”，不是打开某个开关，而是绕过默认行为、主动引入 C 工具链和外部 so 依赖。
常见错误现象：ldd ./myapp 显示 not a dynamic executable，或提示 libpq.so.5: cannot open shared object file 却以为是编译参数漏了 -shared。
- 必须设
CGO_ENABLED=1，否则 cgo 代码不编译，libpq这类依赖直接失效 - 要覆盖默认的
-static行为，得用-ldflags '-extldflags "-shared"'（注意嵌套引号） -
go run永远静态链接，动态链接只能靠go build - 目标机器必须预装对应版本的 so，比如
libpq.so.5，且 ABI 兼容；ldd ./myapp要能看到该库路径
replace 替换本地依赖时 plugin.Open 仍失败
用 replace 把模块指向本地目录，看似能控制源码，但 plugin.Open 加载插件时仍报 "built with a different version of package"——问题不在路径，而在构建指纹不一致。
插件机制对环境一致性要求极苛刻，replace 不改变 go.mod 中原始 import path 的哈希计算，也不同步构建参数。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 主程序和插件必须用同一个
go命令、同一GOROOT、相同GOOS/GOARCH -
CGO_ENABLED必须两边一致（建议都设为0，避免 libc 版本差异） - 插件必须用
go build -buildmode=plugin -o plugin.so plugin.go，不能用c-shared或普通build -
go mod vendor后仍需确保插件和主程序的go.sum完全一致；go list -m all输出应无差异
生成 .so 供 C 调用时头文件缺失或函数不可见
执行 go build -buildmode=c-shared -o libhello.so hello.go 后没生成 libhello.h，或 C 程序调用时报 undefined reference to 'hello'——核心是导出规则没满足。
Go 不会自动导出函数给 C，必须显式声明，且受包结构约束。
- 文件开头必须有
import "C"，哪怕没用到 C 类型 - 每个要导出的函数前必须写
//export hello（//和export之间**不能有空格**） - 必须在
main包里，且包含空的func main() {} - 导出函数参数和返回值只能是 C 兼容类型：
int、char*、C.int等，不能是 Go 的[]string或map - Windows 下生成
.dll会附带.h，Linux 下生成.so同样生成.h，但需确保输出目录可写
交叉编译时动态链接必然失败
在 x86_64 机器上执行 GOOS=linux GOARCH=arm64 CGO_ENABLED=1 go build -ldflags '-extldflags "-shared"'，结果报错找不到 libc 或链接器崩溃——这不是配置问题，是 cgo 默认绑定宿主机工具链。
交叉编译 + cgo + 动态链接三者叠加，Go 官方不支持开箱即用，必须手动指定交叉工具链。
- 不能依赖系统默认
gcc，得用目标平台的交叉编译器，如aarch64-linux-gnu-gcc - 需设置
CC_arm64=aarch64-linux-gnu-gcc，并确保该工具链已安装且能找到sysroot -
CGO_CFLAGS和CGO_LDFLAGS要指向目标平台的头文件和库路径，例如-I/usr/aarch64-linux-gnu/include - 更稳妥的做法：在目标架构机器上原生编译，或用 Docker 构建镜像（如
golang:1.22-bookworm）
ldd 或 plugin.Open 就会立刻翻脸。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
