链接器很容易被忽略，直到它变成每次本地构建里最后一个肉眼可见的停顿。编译器已经完成最有存在感的工作，测试还没有启动，开发者盯着终端，等待数千个目标文件、重定位、符号、归档、调试段和共享库决策收拢成一个最终二进制。mold 的意义在于，它把这个停顿当作一个架构问题处理，避免把它视作工具链里注定存在的天气。[1][2]

Rui Ueyama 给这个项目的定位刻意收得很窄：mold 是现有 Unix 链接器的快速直接替代品，目标是在高频调试、编辑、重建循环里缩短构建时间。[1] 这里的 “drop-in” 和 “fast” 一样重要。一个只在干净基准测试里胜出的链接器值得关注。一个能够挂在 -fuse-ld=mold 后面、经由 rustflags 进入 Rust、用 mold -run 接管难以配置的构建流程，并在输出中留下可核验 .comment 标记的链接器更有价值，因为它能进入真实项目已经在使用的复杂路径。[1]

封面图采用 Ueyama 的公开 GitHub 个人资料照片，来源真实，既非图表，也非生成的系统示意图。这里使用这张照片，是因为 mold 的采用叙事罕见地与一位维护者的可信度绑定在一起；这位维护者同时创建了 LLVM 的 lld 链接器，并持续公开讨论 mold 能否成为普通的 /usr/bin/ld 基础设施。[4][7]

边界在最终构建步骤

README 里的基准测试表有用，因为它把问题压回具体数字。在一台模拟 16 核、32 线程机器上，mold 对 MySQL 8.3 最终带 debuginfo 的二进制文件给出的时间是 0.46 秒，对 Clang 19 是 1.35 秒，对 Chromium 124 是 1.52 秒；对应的 LLVM lld 数字分别是 1.64、5.20 和 6.10 秒，GNU gold 与 GNU ld 在列出的项目中更慢。[1] 这些精确数字若未复现同一工作负载，就不能直接搬进采购材料；真正重要的是这个形状：即便编译已经充分并行化，链接仍会留下数秒级尾部。

这个尾部的影响超过它的绝对时长。在活跃的 C、C++ 或 Rust 循环里，最终链接直接夹在一次小的源码修改和任何可用二进制、测试运行或手动复现之间。四秒链接延迟发生在前台，带来的是直接打断。一个团队若已经花了数月削减编译、测试和容器冷启动时间，却放过链接器，构建体验会显得反常：前面的每一次优化，最后都流向同一个缓慢闸口。

mold 的架构札记正是从这种挫败感出发。设计文档写到，即使 lld 已经改善了情况，链接仍然是最慢的步骤之一，而 mold 想消除的用户问题，就是改动一行代码后还要等待数秒。[2] 这是一个有力的架构框架。这个项目没有试图重新定义目标文件格式，没有发明新构建系统，也没有要求开发者改写代码。它攻击的是一个输入和输出已经清楚界定、但实现方式仍然没有充分使用并行硬件的阶段。

这种目标在 1.0 阶段已经很清楚。InfoQ 在发布初期的报道中，把 mold 放在 Ueyama 的目标下理解：让 Chromium 规模的链接接近瞬时完成，而不只是比旧链接器快一些。[6] 具体硬件和工作负载后来有所变化，但产品命题没有改变：链接步骤应当停止成为所有构建系统改进之后仍然残留的成本。

并行性才是真正的产品

解释 mold 速度最直接的方式，也决定了它是否适合进入你的技术栈：它高度并行化，并围绕更快的算法和数据结构编写。[1] README 用 Chromium 链接过程对比 mold 和 lld，展示 mold 会持续调动可用核心，而 lld 对整机资源的使用没有那么均匀。[1] 设计文档给出了更接近工程视角的说法：mold 试图在解析、符号处理、重定位处理、输出布局和文件写入之间暴露独立工作，让链接器少一点像大部分串行的解析器，多一点像吞吐机器。[2]

这并不会让链接器变简单。链接器是兼容性机器。它们要保留旧命令行预期、归档行为、链接器脚本、ELF 细节、重定位溢出检查、调试段处理、符号版本、平台 ABI 特例，以及早于当前构建系统的语言工具链假设。因此，一个快速链接器的难点不仅在于让常规情况跑得快，还在于让怪异情况清楚失败，或足够贴近既有行为，使用户不会用发布构建破裂来换取速度。

近期发布说明表明，这项兼容性工作仍在继续。截至本文创建日期 2026-07-01，GitHub 将 mold 2.41.0 列为最新版本，发布日期为 April 13, 2026。[3] 这个版本包含与 LTO 有关的修复、更加贴近 GNU ld 的 --omagic 行为、RELRO 段对齐修复，以及面向特定目标的工作。Phoronix 对同一 2.41 周期的发布解读，也把它视为功能与兼容性更新，其中包括用于缩减受支持目标集合的 MOLD_TARGETS、--gdb-index 性能工作、--zero-to-bss、LTO 兼容性，以及架构专属修复。[5]

对采用者来说，经验是：mold 的速度不能与它的修复流分开看。链接器太接近发布产物，只评估一次远远不够。如果采用它，也就采用了一套实践：固定版本，阅读发布说明，复现你们最大的 debug 和 LTO 链接，在有价值的地方核验 .comment 段，并为仍处在边缘位置的工作负载保留回到平台链接器的路径。

直接替代并不等于隐身

mold 给团队提供了几条采用通道，每一条都会露出不同的风险边界。最干净的路径，是经由编译器驱动器传入 -fuse-ld=mold。Rust 项目可以在 Cargo 配置里的 Linux 目标下放置 rustflags = ["-C", "link-arg=-fuse-ld=mold"]。那些难以直接传入链接器选择的项目，可以在 mold -run 下执行构建；它用 LD_PRELOAD 拦截对 ld、ld.bfd、ld.lld 或 ld.gold 的调用，并把它们重定向。[1]

这些入口都很有力，但不能被当作等价选项。-fuse-ld=mold 是显式选择，也容易在构建日志中审计。Cargo 的 rustflags 设置很方便，可是一旦它从仓库拥有的配置转移到用户级配置，就会变成环境里的默认气味。mold -run 对探索和顽固构建系统很有用，但它靠拦截工作，因此在 CI 和发布任务里需要额外审慎。实现方式很巧，策略问题则是：你的组织希望在哪里声明链接器选择。

因此，mold 更适合先作为反馈循环优化试点，然后再成为发布平台默认项。先从本地开发构建和非发布 CI 通道开始。确认真正相关的语言和打包表面：CMake、Bazel、Cargo、Make、Conan、发行版包构建，或嵌入式 SDK 流程。用链接时间确实可见的工作负载测量墙钟变化。再决定生产产物构建是否跟进，是否继续留在系统链接器上，或者在兼容性证据积累前保留双通道。

/usr/bin/ld 问题是一场约束测试

Ueyama 在 FOSDEM 2024 的演讲标题 “Can the mold linker be /usr/bin/ld?”，比 “Is mold fast?” 更适合作为采用问题。演讲页面把 mold 描述为开源、快速、面向 ELF 可移植，并且在 GNU 工具链用户中日益重要；同时它也点出了困难例外：内核和嵌入式编程仍是单纯替换 /usr/bin/ld 难以自动成立的主要领域。[4]

这个区分很关键。一个使用常规 ELF 输出、现代编译器驱动器和普通发行目标的用户态应用，与内核、固件镜像、bootloader、自定义链接器脚本，或深度嵌入式内存映射相比，风险表面完全不同。链接步骤越接近硬件布局和特殊段，团队越要把泛泛的 “drop-in” 语言留在一边，直到自己的产物给出证据。

受支持目标列表足够宽，能说明这个项目的雄心：README 列出了 x86-64、i386、Arm、RISC-V、PowerPC、s390x、LoongArch、SPARC64、m68k 和 SH-4 变体。[1] 宽目标支持让 mold 超过了单一平台技巧的范围。它也扩大了必须持续跟进发布说明的表面，因为每个架构家族都带着自己的重定位、ABI 和工具链预期，它们会分别发生回归。

这篇架构札记落在何处

尝试 mold 的最佳理由，不是更快的链接器在基准表里显得漂亮。真正的理由是，构建延迟会累积，也会影响心理节奏。开发者更容易接受缓慢的夜间构建，却很难忽视每次编辑后反复出现的小停顿。mold 用合适的系统工程处理这个反复出现的停顿：保留既有契约，并行化昂贵阶段，维持足够兼容性以进入常规驱动器，并暴露核验点，让团队能够证明某个产物由哪个链接器生成。[1][2]

避免过度采用它的最强理由，也正是它重要的同一个理由：链接器位于产物流水线末端。糟糕的编译通常会响亮失败。糟糕的链接会变成运行时、打包、调试符号或平台特定问题，归因更难。因此，理性的采用方式是先窄后宽，先测量，再等那些异常二进制表达完自己的意见。

对多数应用团队来说，mold 属于快速测试选择、远程缓存纪律和冷启动削减这一类基础设施：它的价值在于保护注意力。如果这个项目缩短了你的热循环，同时没有改变产物语义，它就不只是让构建更快。它把注意力还给了工程师仍能推理变更的代码路径。

来源

1. rui314/mold, "mold: A Modern Linker" README - 项目定位、基准测试表、受支持目标、驱动器集成、mold -run、核验方式和并行性说明。
2. rui314/mold, docs/design.md - 关于链接器延迟、动机和并行架构的 mold 设计与实现札记。
3. GitHub, rui314/mold releases - 当前发布流和 2.41.0 发布说明。
4. FOSDEM 2024, "Can the mold linker be /usr/bin/ld?" - 演讲页面描述 mold 的 ELF 可移植性、GNU 工具链角色，以及内核/嵌入式边界。
5. Michael Larabel, "Mold 2.41 Linker Released With New Features & Fixes," Phoronix, April 13, 2026 - 独立发布解读。
6. Sergio De Simone, "Mold is a New Linux Linker Aiming to Outperform Lld," InfoQ, December 2021 - mold 性能目标和开发者生产力主张的发布初期背景。
7. GitHub, "Rui Ueyama / rui314" - 公开维护者资料，以及真实摄影封面图来源。