go链接过程由cmd/link全自动完成，不暴露用户控制；纯go代码无传统链接，仅cgo场景才调用系统链接器处理c符号，此时#cgo ldflags生效。
Go 的链接过程不暴露给用户直接控制，go build 内部调用的链接器（cmd/link）是自包含、无须手动干预的。你不需要、也不应该去碰 ld、ar 或写 Makefile 控制链接步骤——所有符号解析、重定位、段合并都由 Go 工具链全自动完成。
为什么不能像 C 那样用 -l/-L 手动控制 Go 链接？
Go 编译器（gc）生成的是平台无关的中间目标格式（.o），不是 ELF/COFF；它的链接器不消费传统静态库（.a）或动态库（.so/.dll）的符号表，而是直接读取 Go 包的导出信息和内联 C 代码的编译结果。所以：
-
#cgo LDFLAGS: -lfoo只在存在import "C"且需要链接 C 符号时才生效，它触发的是 gcc/clang 链接阶段，不是 Go 链接器本身 - 纯 Go 代码之间（如
package main调用package utils）根本不会走系统链接器，符号绑定发生在 Go 编译期 - 试图用
go tool link手动链接多个.o文件会失败：Go 目标文件缺少标准 ELF 头、无动态符号表，cmd/link也不接受外部传入的目标文件列表
真正需要你介入的“链接点”只有 cgo 场景
当你在 Go 源码里写了 import "C"，Go 工具链会在构建时启动两套并行流程：
- Go 部分：编译
.go文件 → 生成 Go 目标（含 cgo stub 函数） - C 部分：用系统 gcc/clang 编译
#include的头文件 + 内联 C 代码 + 同目录下.c文件 → 生成 C 目标 - 最后把这两组目标交给系统链接器（
ld/link.exe）合并成最终二进制
此时你才需要操心 #cgo LDFLAGS 和 #cgo CFLAGS：
- 若链接 Windows DLL，必须提供
.lib导入库（不是.dll），例如：#cgo LDFLAGS: -LC:/sdk/lib -lMyModule - 若链接 Linux
.so，确保LD_LIBRARY_PATH或RPATH正确，否则运行时报cannot open shared object file - 避免
#cgo LDFLAGS: ./foo.o：这会让 GCC 重复编译同一份 C 实现，导致multiple definition
如何验证链接是否真出问题？
区分错误来源比盲目加 flag 更重要：
-
undefined reference to 'xxx'→ 是 C 符号未定义：检查.c是否缺失、-l库名是否拼错、.h声明与实现是否一致（尤其extern "C"） -
symbol not found in main module（运行时）→ 是动态库加载失败：用ldd ./myapp（Linux）或dumpbin /dependents myapp.exe（Windows）看依赖链 -
internal compiler error: failed to load package→ 不是链接问题，是 Go 包导入路径或go.mod错误
最常被忽略的一点：Go 链接器从不报“链接失败”，它只负责 Go 符号；所有带 undefined reference 的错误，100% 来自 cgo 启动的 C 链接阶段——盯住那一行错误里的函数名，它一定出自 C 头文件或 //export 声明。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
