以太坊智能合约交互指南：合约调合约实战笔记

前言：智能合约还能这么玩？

很多开发者在初次接触智能合约时，经常把“部署一个币”和“只有一个合约”等同起来。实际上，以太坊网络支持无限次部署，合约可以像积木一样堆叠。本文用最贴近一线的视角，带你拆解“以太坊智能合约”如何互相调用、如何收发 ETH、如何控制 gas，让你一口气看懂“合约调合约”的全部细节。

一、关键认知：智能合约 ≠ 只能干一件事的脚本

1. 同一链可以部署多个智能合约

每个合约都是链上的独立账户（拥有地址、余额、存储区），互不覆盖。
→ 最佳实践：发币和全局数据放在“核心合约”，其他逻辑拆分成“辅助合约”。这样既避免“多发一个币”的尴尬，也便于后期升级。

2. 智能合约就是一个无密钥的账户

可以接收 ETH：只要有 receive() 或标记 payable 的 fallback()。
可以转账：合约自身变量 + 权限控制就是“私钥”——只要检查时 msg.sender == owner，就能主动 transfer(value)。

👉 学会5分钟写出无密钥账户的交互逻辑，让代码开口说话

二、合约如何接收 ETH：fallback 机制拆解

场景：用户把 ETH 直接打到合约地址

合约必须具备：

fallback() external payable { /* 省略校验 */ }

gas 限制误区

address.send(1 ether) ➜ 受 2300 gas 限制，几乎只能记录日志。
address.call{value: 1 ether}("") ➜ 可传任意 gas，适合复杂逻辑，但要防止重入。

FAQ：关于收款的 3 个疑问

#	读者提问	结论式回答
1	为什么没有 fallback 就报错？	合约没有任何可收款函数，客户端无法提交交易。
2	2300 gas 能做什么？	最多写 1 个 storage，或发 1 条 Event，无法执行转账。
3	既要收钱又要升级怎么办？	在 upgradeable 代理合约中保留 `fallback()`，内部转发到新版业务合约。

三、合约之间的“打招呼”：调用的 3 种姿势

1. 接口（interface）方式——最常用的解耦方案

步骤：

声明 interface，与被调侧函数签名保持一致；
在构造函数或 setter 中注入目标合约地址；
用 SomeInterface(addr).foo{value: eth}(...) 完成调用。

示例（A 合约 → 调用 → B 合约）：

// B.sol
interface IERC20 {
    function mint(address to, uint256 amount) external returns (bool);
}

// A.sol
contract Crowdsale {
    IERC20 public token;     // 指向 B 合约
    constructor(address token_) {
        token = IERC20(token_);
    }
    function buy() external payable {
        token.mint(msg.sender, msg.value);   // 调用 B 的 mint
    }
}

2. 直接地址调用（不推荐）

直接把被调函数签名编码后 call()，容易碰签名错误、gas 估算难题，容易重入攻击。

3. “写在一起”——即一份文件但多个合约

编译器会把内部调用改写成 JUMP，节约 gas；但可维护性与地址复用性差。

👉 再复杂的业务逻辑，也能像这样拆合约升级而不失安全性

四、权限模型：没有私钥也能“提现”的秘密

合约身份由代码而不是密钥决定：

modifier onlyOwner() {
    require(msg.sender == owner, "Not owner");
    _;
}

function withdraw(address payable to, uint256 amount) external onlyOwner {
    require(address(this).balance >= amount, "Insufficient balance");
    to.transfer(amount);
}

核心：
owner 可以在链下用持有私钥的 EOA 签名交易，调用该 withdraw ——这里没有破解加密，只是逻辑赋予了合约“动账”的权力。

五、Gas 估算法则：学会看 Remix

复制合约 → Remix → 选择编译版本 → 右侧 Compile → Details → 搜索 Gas Estimates。
Deploy + 各 function 的 估算值 会完整展示，一键确认大致成本。
实测发现：
- 部署 1000 行左右的 ERC20 → 约 2,400,000 gas；
- 合约调合约再转 1 ETH → 额外 25,000–50,000 gas（取决于接收方是否触发逻辑）。

FAQ：Gas 计费的 3 个容易踩坑的点

Q1：一次 call 就比 send 省 gas 吗？
A：不是，call 提供的灵活度可能在复杂业务中带来额外存储/事件开销。

Q2：delegatecall 为什么 gas 更高？
A：因为它要把外部合约的代码临时装进当前上下文，需要附加的内存拷贝和校验。

Q3：部署时代码体积越大越贵？
A：是的。主网每字节 200 gas，优化器开到 runs=200 通常可下降 10–30%。

六、实战小结：部署-交互-升级一条龙

把“核心数据”拆到单独合约，如 TokenStorage。
把“业务逻辑”拆到可升级合约，通过 initialize() 回调。
用 OpenZeppelin 的 Proxy + UUPS 方案平滑升级，无需迁移资产。
内测网验证整条链路：用户买币 ➜ 合约收款 ➜ 调用另一合约 mint ➜ gas 估算合理。

把以上 4 步在一周内走完，你就能写出让审计舒适的“链上乐高”架构，离 DApp 上线只差一次安全审计。

祝你「一发上链，永不翻车」！