开发栈(Dev Stack)
约 2576 字大约 9 分钟
2026-05-12
Web3 开发栈不是一组随机工具名,而是一条从写合约、测合约、部署合约、连接钱包、调用合约到监控结果的工程链路。工具选型的目标是让链上开发更可验证、更可复现、更少事故。
为什么要学这个
写一个 Web3 demo 很容易:接钱包、调合约、发交易。但真正做项目时,你会马上遇到合约编译、测试、部署脚本、环境变量、RPC、前端 SDK、链切换、合约验证、权限管理和监控。
开发栈的作用不是让你收集更多工具,而是把开发流程变成可重复的系统。一个项目至少要做到:本地能跑、测试能复现、部署有记录、前端调用明确、合约地址可追踪。
工具链越清楚,链上执行越可控。
可以先把一条最小开发链路拆成六步:
- 在本地或浏览器 IDE 写出合约。
- 编译合约,得到 bytecode 和 ABI。
- 在本地链或测试网部署合约。
- 写测试覆盖核心状态变化和权限边界。
- 前端用合约地址和 ABI 读取或发送交易。
- 在区块浏览器验证源码、交易和事件。
这些步骤缺一环,后面都会变成排查成本。比如前端拿错 ABI,会出现参数编码错误;部署地址没有版本记录,会让用户和开发者不知道自己到底在和哪份合约交互;测试只覆盖 happy path,则权限和失败分支很容易漏掉。
第一性原理
Web3 工具链的核心是把不可逆执行前移到可测试、可模拟、可审查的流程里。
链上交易一旦成功,后悔成本很高。因此开发工具要尽量把错误暴露在本地、测试网、模拟环境和 code review 阶段,而不是等到主网上线后再发现。
- 本地优先复现:合约逻辑、部署脚本和前端调用都应该能在本地或测试网跑通。
- 地址和 ABI 要版本化:前端调用的到底是哪份合约,必须能追踪。
- 安全库不是免审计:OpenZeppelin 等库降低基础风险,但组合逻辑仍要自己验证。
知识节点
Remix
难度:初级。 Remix 适合快速理解 Solidity、部署小合约和观察合约调用流程。
Remix 是浏览器里的 Solidity IDE。它可以编写、编译、部署和调试合约,适合入门、教学、原型和快速验证。
它的优势是低门槛,不需要先搭完整工程。但真实项目仍然需要进入 Git、测试框架、部署脚本和 CI,否则很难复现和协作。
你可以把 Remix 当成“合约实验台”。最适合用它做三件事:
- 快速复制一段 Solidity 代码,看能不能编译。
- 在 JavaScript VM 或测试网部署合约,观察构造函数、函数调用和 event。
- 用 Deploy & Run 面板理解
read和write调用的区别。
Remix 不适合长期替代工程化 repo。只要项目开始多人协作,就应该把合约放进 Git 仓库,并用 Hardhat 或 Foundry 固化测试和部署流程。
相关 topic
- Remix Documentation:官方文档,适合入门 Remix 工作区、编译器、Deploy & Run、debugger 和插件。
- Remix Online IDE:浏览器版 IDE,可以直接写、编译和部署 Solidity 合约。
Hardhat
难度:中级。 Hardhat 适合 JavaScript/TypeScript 项目,把合约开发接进测试、脚本和前端工程。
Hardhat 提供本地开发网络、编译、测试、部署脚本和插件生态。对前端团队来说,它和 TypeScript、ethers、CI 的结合比较自然。
学习 Hardhat 的重点不是记命令,而是理解本地链、测试网、部署脚本、合约验证和环境变量如何组成完整开发流程。
Hardhat 更像是“合约工程框架”。一个典型 repo 会包含:
contracts/:Solidity 合约源码。test/:TypeScript 或 Solidity 测试。ignition/或scripts/:部署模块和脚本。hardhat.config.ts:网络、编译器、插件和变量配置。artifacts/:编译生成的 ABI、bytecode 和 metadata。
如果你的项目需要和前端、后端、CI 紧密协作,Hardhat 通常比只用 Remix 更容易把流程固定下来。
相关 topic
- Hardhat Documentation:官方文档,重点看 getting started、testing、deploying、configuration variables 和 contract verification。
Foundry
难度:中级。 Foundry 更偏命令行和 Solidity-native 测试,适合高强度合约开发和快速反馈。
Foundry 常用工具包括 forge、cast、anvil。它可以用 Solidity 写测试,运行速度快,也适合做 fuzz testing、脚本部署和链上状态交互。
如果你更关注合约逻辑、测试深度和命令行工作流,Foundry 是非常重要的工具。
Foundry 的几个常见入口:
forge test:运行合约测试。forge build:编译合约。anvil:启动本地测试链。cast call:读取链上合约。cast send:发送交易调用合约。
它特别适合训练“先写测试,再改合约”的习惯。对安全敏感的合约来说,能快速跑单元测试、fuzz test 和 fork test,比只在 UI 上点几次更可靠。
相关 topic
- Foundry Book:官方文档,适合学习
forge、cast、anvil、fuzz testing 和 fork testing。
OpenZeppelin
难度:中级。 OpenZeppelin 提供常用合约标准和安全组件,但不能替代对业务逻辑的审查。
OpenZeppelin Contracts 包含 ERC-20、ERC-721、AccessControl、Ownable、Pausable 等常见模块。使用成熟库可以减少重复造轮子,也能避免很多基础实现错误。
但危险在于“用了库就安全”的错觉。权限组合、升级模式、参数设置、外部调用和经济设计仍然可能出问题。
一个常见例子:你可以用 OpenZeppelin 的 ERC-20 实现 token,但仍然要自己决定谁能 mint、是否能 pause、owner 是否可以转移、升级权限是否有 timelock。这些不是库自动帮你做出的产品决策。
相关 topic
- 智能合约(Smart Contract):先理解合约状态、ABI、事件和升级风险。
- OpenZeppelin Contracts:官方合约库文档,适合学习 ERC 标准实现、AccessControl、Ownable、Pausable 等模块。
- OpenZeppelin Upgrades:了解 proxy 升级流程和升级合约的风险边界。
viem / wagmi
难度:中级。 viem 和 wagmi 主要解决前端与链交互的问题:读合约、写合约、管理账户、处理网络和缓存。
viem 是 TypeScript 以太坊接口库,强调类型安全和底层调用能力。wagmi 则面向 React 应用,提供钱包连接、账户状态、合约读写和 hooks。
前端接链时,最容易出问题的是状态不一致:钱包网络、前端配置、合约地址、RPC 返回、交易 pending 状态都可能不同步。好的 SDK 只能降低复杂度,不能替你设计清楚用户流程。
在前端里,至少要把四类状态分开:
- 钱包是否已连接。
- 用户当前在哪条链。
- 合约读取结果是否正在加载或已过期。
- 写交易处于等待签名、已广播、等待确认、成功或失败的哪一步。
如果这些状态混在一个按钮里,用户会很难判断自己是在“连接钱包”“签名授权”还是“等待交易上链”。
相关 topic
- viem Documentation:学习 TypeScript 方式读取链、编码调用、发送交易和处理链上数据。
- wagmi Documentation:学习 React 应用里的钱包连接、账户状态、合约读写和交易状态管理。
一条具体工具链怎么串起来
假设你要做一个最小投票合约,可以这样组合工具:
- 用 Remix 写第一版
Voting.sol,先确认语法和基本调用流程。 - 把合约迁移到 Hardhat 或 Foundry repo。
- 写测试覆盖:创建投票、重复投票、投票结束、非管理员操作失败。
- 用本地链部署,记录地址和 ABI。
- 用 viem 或 wagmi 写前端:读取候选项、发起投票交易、展示 pending 和 confirmed 状态。
- 部署到测试网后,在区块浏览器验证源码,并检查 event 是否能被正确查询。
这个流程看起来比“直接写页面调合约”慢,但它能让错误更早暴露。Web3 项目真正耗时间的地方,往往不是写第一版,而是上线后发现合约地址错了、ABI 不匹配、权限没测、交易状态没处理。
在 AI x Web3 中的位置
AI 可以显著提升 Web3 开发效率:解释 ABI、生成部署脚本、补测试、排查交易失败、总结合约权限。但 AI 参与开发栈后,验证流程反而要更明确。
如果 Agent 能运行 forge test、读取部署配置、调用 cast 或生成前端合约调用代码,它就必须受到 repo workflow、测试、权限和 secret 管理约束。链上开发不是普通代码生成,高风险命令需要人工确认。
最小实践
搭一个最小 Web3 开发链路:
- 用 Remix 部署一个极简计数器合约,包含
count()、increment()和CountChangedevent。 - 用 Hardhat 或 Foundry 建一个本地工程,并写测试覆盖初始值和
increment()后的状态变化。 - 记录合约地址、ABI、部署网络、部署账号和交易哈希。
- 用 viem 或 wagmi 从前端读取
count(),再发起一次increment()交易。 - 在区块浏览器或本地日志里确认 event 被正确发出。
- 写下这条链路中哪些信息必须进版本控制,哪些必须放在
.env或密钥管理里。
扩展阅读
- Remix Documentation:适合从浏览器 IDE 入门 Solidity 编译、部署和调试。
- Hardhat Documentation:学习 TypeScript/JavaScript 合约开发、测试和部署流程。
- Foundry Book:学习
forge、cast、anvil和 Solidity-native 测试工作流。 - OpenZeppelin Contracts:查看常见合约标准、安全组件和访问控制模块。
- viem Documentation:学习 TypeScript 方式读取链、发送交易和调用合约。
- wagmi Documentation:学习 React 应用中的钱包连接、账户状态和合约交互。