cgo编译报“multiple definition”错误的根本原因是c侧多个编译单元导出同名全局符号，导致gcc链接时冲突；需用nm定位冲突符号，再依场景采用static修饰、剔除冗余目标文件或链接选项修复。
为什么 CGO 编译报 multiple definition of 'xxx'？
根本原因不是 Go 写错了，而是 C 侧多个编译单元（.c 文件、静态库、头文件内联定义）导出了同名全局符号。CGO 把所有 C 代码（含 #include 展开后的内容）一起交给 gcc 链接，此时链接器发现两个 log_init 或 config_parse，直接拒绝合并。
常见诱因包括：
- 两个第三方 C 库都自带
utils.c，且里面定义了未加static的str_trim() - 头文件里写了
int global_flag = 0;（定义而非声明），被多个 .c 包含后变成多份 - Go 项目里同时
#include "libA.h"和#include "libB.h"，而两者都宏定义了MAX_PATH并间接定义了同名函数
用 nm 快速定位冲突符号来源
别猜，直接看目标文件里谁在导出那个名字。假设报错是 duplicate symbol 'json_parse'：
go build -x -o /dev/null 2>&1 | grep '\.o' | head -5
拿到类似 /tmp/go-build.../xxx.o 的路径后，挨个查：
nm -gC xxx.o | grep json_parse
观察输出的符号类型：
-
T json_parse→ 是函数定义（强符号，冲突源） -
D json_parse→ 是已初始化全局变量（同样强符号） -
C json_parse→ 是未初始化全局变量（common symbol，最常引发冲突）
找到所有含 T 或 C 的 .o，就锁定了冲突模块。
三类真实有效的修复手段（按优先级排序）
不是加 static 就完事，得匹配场景：
- 若冲突来自你控制的 C 代码：把函数前加
static，或变量改用extern声明 + 单独定义文件 - 若来自第三方静态库（如
libz.a和libpng.a都含inflate）：用ar -t libz.a | grep inflate找出对应 .o，再用ar -d libz.a inflate.o剔除冗余对象（前提是确认不依赖该函数） - 若必须保留两个库且无法修改源码：用 GCC 的
--allow-multiple-definition（仅限链接阶段，不推荐生产环境）或改用-Wl,--undefined=xxx强制只取某一个定义
CGO 中避免符号污染的硬性习惯
很多问题其实在写第一行 #include 时就埋下了：
- 永远不用
#include第三方库的完整头文件（如curl/curl.h），改用自己写的薄封装头，只暴露真正需要的函数声明 - 所有 CGO 块里的 C 代码，开头加
static能加就加；导出给 Go 调用的函数，用唯一前缀（如myproj_json_parse） - 禁止在
/* #cgo */块里写任何变量定义，只放#include和函数声明；实现全放在独立 .c 文件里 - 跨平台构建时，
go build -ldflags="-s -w"会 strip 符号，但解决不了链接期冲突——那是编译期的事
符号冲突不是“运气不好”，是 C 的链接模型和 Go 的 CGO 打包方式共同作用的结果。越早用 nm 看清符号表，就越少花时间在反复删 #include 上。
