lld 报 duplicate symbol 问题本质是输入目标文件或静态库中存在重复定义，而非 lld 自身缺陷；它默认禁用 -fcommon 模式，严格遵循“一处定义”规则，比系统 ld 更早、更严地暴露符号冲突。
LLVM LLD 报 duplicate symbol，基本不是 LLD 本身的问题，而是你传给它的目标文件（.o）或静态库（.a）里已经存在重复定义 —— LLD 只是比系统 ld 更严格、不妥协地执行“一处定义”规则。
为什么 LLD 比系统 ld 更容易报 duplicate symbol
LLD 默认不启用 -fcommon 兼容模式，而 GCC 和旧版 Clang 在某些场景下会把未初始化的全局变量（如 int g_counter;）当作“common symbol”处理，链接时自动合并；LLD 则直接视为多重定义错误。典型触发点：
- 多个
.c或.m文件里写了同名未加extern的全局变量（比如int kConfigFlag = 1;） - C++ 模板特化定义放在头文件里，被多个源文件包含（如
template constexpr double pi::value<double> = 3.14;</double>） - 误在
.h里写函数实现或变量定义，而非仅声明 - 静态库（
.a）本身已含重复.o，LLD 不像 GNU ld 那样容忍
快速定位哪个 .o 或 .a 引起冲突
报错行末尾一定列出两个冲突文件路径，例如：
duplicate symbol _g_session_id in:
/path/to/A.o
/path/to/B.o
顺着这个线索查：
- 用
file A.o和file B.o确认是否真为 ELF/Mach-O 目标文件（排除误拖入源码或脚本） - 用
nm -C A.o | grep g_session_id查符号类型：如果都是T（text/定义）或D（data/定义），说明两者都定义了，不是声明 - 如果是
.a文件出问题，先用ar -t libX.a列出内部.o，再对每个.o执行nm -C定位具体是哪个.o包含重复定义 - Xcode 用户：检查
Build Phases → Compile Sources是否重复添加了同一.m或.c文件
第三方 .a 库之间冲突，怎么修
不能改源码？只能动二进制。核心步骤是“拆-删-合”，注意顺序和平台：
- 用
lipo -info libA.a看架构，如果是 fat 库（含 arm64 + x86_64），先lipo libA.a -thin arm64 -output libA.arm64.a - 对瘦库执行
ar -t libA.arm64.a找出含冲突符号的.o（比如JSONKit.o），然后ar -d libA.arm64.a JSONKit.o删除它 - 重复上述操作清理所有架构下的对应
.o - 最后用
lipo -create libA.arm64.a libA.x86_64.a -output libA-fixed.a合并 - ⚠️ 注意：
ar rcs重建单个瘦库时，必须确保删除后剩余.o无其他隐式依赖，否则运行时报undefined symbol
编译阶段就避免，关键设置
与其事后修，不如让 Clang + LLD 从源头减少风险：
- 全局变量务必在
.c/.m中定义，在.h中用extern int g_flag;声明 - C++ 模板特化定义不要放头文件；若必须，加
inline（C++17 起支持inline variable）或改为extern template显式实例化 - Clang 编译时加
-fno-common（LLD 默认行为），提前暴露问题，而不是等链接才爆 - 用
clang -fuse-ld=lld时，确保-fuse-ld=lld出现在所有-l、-L参数之前，否则可能静默 fallback 到系统ld
真正麻烦的从来不是 LLD 报错，而是它报错后你发现两个第三方 .a 都没源码、且冲突符号深埋在几十个 .o 里——这时候删 .o 前，务必先备份原始库，并用 nm 反复验证删的是不是真冗余的定义。
