10,626 颗星、741 位贡献者、v1.8.3 刚发：Foundry 用 Rust 把以太坊合约测试从几十秒压到不到一秒

如果你在 2026 年还在用 npm install 之后等半分钟才跑完一轮合约测试，那多半没见过 Foundry 跑测试的样子。一个几十个用例的 Solidity 测试套件，Hardhat 跑几十秒，Forge 往往不到一秒。这不是营销话术，而是一整套工具链换语言之后的结果。

Foundry 是 Paradigm 团队从 2021 年就开始做的以太坊开发工具包，仓库挂在 foundry-rs/foundry，现在 10,626 颗星、2,644 个 Fork、741 位贡献者，主语言是 Rust，Apache-2.0 与 MIT 双许可。它不是一个”框架”，而是四个命令行工具的集合：Forge（编译 / 测试 / 模糊测试 / 部署）、Cast（和链交互的瑞士军刀）、Anvil（本地以太坊节点）、Chisel（Solidity REPL）。官网在 getfoundry.sh，文档就是那本被反复提到的 Foundry Book。

它真正改变的不是”快一点”，而是测试这件事的书写方式。在 Foundry 里，测试用 Solidity 写，不用写一行 JavaScript。你可以在测试里直接 vm.prank 扮演某个地址、vm.warp 拨快时间、vm.deal 凭空发币，这些”作弊码”让合约状态的模拟变得像改调试变量一样直接。这种原生感是 JS 系工具给不了的。

速度到底快多少，有数字

Foundry 官方和社区留下了几组可以对照的基准：

• 对比它自己的前身 DappTools：guni-lev 快 5.45 倍、solmate 快 7.66 倍、geb 快 3.63 倍、vaults 快 3.9 倍，这是官方 README 里贴的历史数据。
• 对比 Hardhat：在 openzeppelin-contracts 上，Hardhat 编译 15.244 秒，Forge 只用 9.449 秒，有缓存时约 4 秒。
• 最新版本自身对比：Solady 项目上 Foundry 1.0 测试只用 0.9 秒，而 Foundry 0.2 需要 2.3 秒；在 Morpho-blue 上甚至测出了 147 倍的提升。

这些数字来自官方文档和社区整理（开源榜介绍、CSDN 实战文），不是一次性跑分，而是被很多 DeFi 团队当成日常体感的东西。

v1.8 这一版在补什么

真正值得关注的是最近的版本节奏。稳定版已经到 v1.8.3，nightly 几乎每 1–2 天发一次。其中 v1.8.0（2026-08-27）是这个项目一次比较大的转向：

• 原生符号执行测试（symbolic testing） 以 forge test --symbolic 的形式开放预览，底层用 Z3 求解器，可以把失败的符号用例导出成可复现的反例和 Solidity 回归测试；
• 变异测试（mutation testing） 进入工具箱，用来检验”你的测试到底有没有真的在测东西”；
• 隔离模式（isolate mode）与动态测试链接成为默认行为；
• Forge 内置了 Solar 语言服务器，forge lsp 一条命令就能拉起带 Solidity 支持的编辑器环境；
• forge lint 新增了一整套安全与 Gas 检测器，按官方说法已经接近 Slither / Aderyn 的水平；
• foundryup 用 Rust 重写，并加入了对 Monad 的官方支持。

紧接着的 v1.8.1 是一次补丁版，修的是动态测试链接、Polygon PoS 分叉、npm remapping 自动识别、以及 lint 等问题（官方 Changelog）。这种”大版本开功能、小版本快速修”的节奏，说明维护团队还在加速，而不是维护期。

它的边界在哪里

Foundry 常被夸成”Hardhat 终结者”，但把边界说清楚反而更有用。

它服务的范围明确限定在以太坊 / EVM 系。 README 里写得很直白：Ethereum application development toolkit。如果你做的是 Solana、Sui 这类非 EVM 链，Foundry 帮不上你——那是对岸 Anchor 的地盘。

前端集成和复杂部署脚本，Hardhat 生态依然更成熟。 Foundry 没有内置自动生成 TypeScript 客户端的能力，团队经常是”Forge 负责测试、Hardhat 负责部署和插件”两套并存。作者和社区都承认这是当前的真实分工，而不是非要二选一。

Windows 用户有额外门槛。 foundryup 的安装脚本需要 Git Bash 或 WSL，纯 PowerShell / CMD 官方并不支持。

从源码编译的代价不小。 有一份公开评测（mrkeyoor.com/repos/foundry）记录得很诚实：在一台 3 核、12GB 的干净 Debian 容器里，装依赖用了 139 秒（1,257 个 Rust 包），源码构建成功了但花了 886 秒，随后跑 cargo test 在 900 秒上限到时仍未结束。也就是说：用发布二进制很轻，想当贡献者得准备充足的 CI 时间。

部署脚本不是零风险的。 同份评测引用了两个开放 issue：#17012 指出即使加了 --slow，后续调用仍可能沿用最初模拟时的数值；#16566 记录了 forge script --resume 在某些”估算 vs 挖矿”场景下会误读交易进度。往主网发真实资产前，部署脚本的行为值得自己复核一遍，而不是全信模拟结果。

谁适合用，谁先别急

适合：写 Solidity、想要”编译-测试-模糊测试-部署-链上查询”一条命令搞定的合约工程师；需要把主网状态分叉到本地做真实集成测试的协议团队；会用 Forge 的 cheatcodes、invariant 测试、Gas 快照或内置语言服务器的人；以及愿意为 CI 装发布二进制或留足编译时间的工程负责人。Uniswap、Optimism、Paradigm 这些名字都在用它，说明它已经进了生产级工具箱。

先别急：做非 EVM 链的开发者；依赖大量 JS 插件、需要自动生成前端 client 的团队；只能在小规格 CI runner 上从源码构建的贡献者；以及在 Windows 上必须用 PowerShell 的人。

下一步可以做什么

不要一上来就把整条流水线搬过去。更稳妥的路径是：

1. 在现有仓库里先用 forge install foundry-rs/forge-std 引入测试库，把测试环节单独迁过来，跑一轮和现有 Hardhat 测试的对照，感受一下那个”秒级反馈”；
2. 确认体感之后，再逐步把 anvil --fork-url 接进集成测试，用主网分叉验证真实场景；
3. 关注 v1.8 的符号测试和 forge lint——对做安全审计的团队来说，这两块可能是这一版最值得提前上手的部分；
4. 发主网前，务必自己复核部署脚本，别把模拟结果当保证。

工具链的迁移从来不是”谁取代谁”，而是”哪一段值得换”。Foundry 已经用一万多颗星和真实的基准数据，把”合约测试这段该换”这个答案摆在了桌面上。