优先选LLD，Gold已停更；LLD是LLVM活跃组件，支持ThinLTO、WASM等新特性，Gold则完全不支持且自2017年起停止维护。
直接结论：优先选 LLD，Gold 已停更，不建议新项目引入。
LLD 和 Gold 的实际维护状态差异
Gold 自 2017 年起已停止主动维护，主流发行版（如 Ubuntu 24.04+、Fedora 38+）默认不再预装 binutils-gold，部分新版 binutils 甚至移除了 Gold 源码。而 LLD 是 LLVM 项目活跃开发组件，LLVM 15/16/17 每个版本都包含 LLD 的性能改进与平台支持扩展（比如刚合入 HarmonyOS PC AArch64 支持）。这意味着：
- 遇到 Gold 的 bug 基本无修复渠道；LLD 的问题可在 llvm-project GitHub 提 issue 或提交 PR
- LLD 对 ThinLTO、增量链接、WASM、PDB 调试信息等新特性的支持是开箱即用的，Gold 完全不支持
- Clang 默认会尝试调用
ld.lld，而 GCC 对 Gold 的“默认 fallback”逻辑早已弱化
什么时候还可能用到 Gold
仅限两类场景：
- 遗留嵌入式构建系统（如 Yocto 旧版 meta-clang 层），其
toolchain-config硬编码了-fuse-ld=gold，且升级成本过高 - 极少数特定内核模块链接脚本依赖 Gold 的某些非标准符号解析行为（例如某些 ARMv7 内联汇编段对
.gnu.linkonce的处理），但这类 case 在 LLD 14+ 中基本已兼容
注意：ld.gold 在部分系统上仍可通过 sudo apt install binutils-gold 安装，但安装后需手动确认是否被 update-alternatives 切换为系统默认 ld —— 多数现代 CI 流程已跳过这步，导致看似安装成功实则未生效。
LLD 启用时最容易忽略的兼容性点
LLD 兼容 GNU ld 接口，但以下三点常被跳过，引发链接失败或运行时异常：
-
--hash-style=gnu必须显式加：LLD 默认用sysv，而 glibc 动态加载器在某些旧版（如 CentOS 7 的 glibc 2.17）中只认gnuhash 表，漏加会导致undefined symbol: __libc_start_main类错误 - 静态链接
libstdc++时，需补-static-libstdc++：LLD 不像 GNU ld 那样自动推导 C++ 运行时依赖，否则可能漏掉libsupc++.a - 使用
-flto时，确保所有目标文件由同一 Clang 版本生成：LLD 的 LTO 后端直接消费 LLVM bitcode，跨版本 bitcode 格式不兼容，报错类似invalid bitcode version
验证你真正在用 LLD 的方法
别只信 g++ -fuse-ld=lld 命令行。实际生效需确认三点：
- 编译命令末尾是否出现
-Wl,--dynamic-list-data或-Wl,--no-as-needed？这些是 LLD 特有链接选项，GNU ld 会报错，而 LLD 会静默接受 —— 这是快速判断依据 - 运行
readelf -p .comment your_binary，输出中应含LLD字样（GNU ld 输出为GNU ld） - 在链接耗时明显下降（尤其 >1000 个 .o 文件时）且
/usr/bin/ld.lld进程 CPU 占用达 300%~400%，说明并行链接已触发
真正容易被忽略的是：LLD 的速度优势只在多核 + 大量目标文件 + 符号密集（如模板展开多的 C++ 项目）时才显著。小项目换 LLD 可能感知不到区别，但一旦项目规模增长，再切回来就难了 —— 因为构建脚本、CI 配置、IDE（如 Qt Creator）的工具链设置都得同步改。
