0x01 一個(gè)讓人抓狂的錯(cuò)誤
寫(xiě) Solidity 時(shí)遇到過(guò)這種錯(cuò)誤嗎？
CompilerError: Stack too deep, try removing local variables.
函數(shù)參數(shù)一多，局部變量一多，編譯器就開(kāi)始報(bào)錯(cuò)。然后你只能：
- 把變量改成 struct 打包
- 把函數(shù)拆成好幾個(gè)
- 或者干脆放棄優(yōu)雅的代碼結(jié)構(gòu)
這不是你的問(wèn)題，是 EVM 的棧深度限制（最多 16 層）導(dǎo)致的。
好消息是：via_IR 可以解決這個(gè)問(wèn)題。
0x02 什么是 via_IR
via_IR 是 Solidity 的一個(gè)編譯選項(xiàng)，全稱(chēng) "via Intermediate Representation"（通過(guò)中間表示）。
傳統(tǒng)編譯流程：
Solidity 源碼 → 字節(jié)碼
啟用 via_IR 后：
Solidity 源碼 → Yul IR → 優(yōu)化 → 字節(jié)碼
Yul 是一種中間語(yǔ)言，更接近底層，編譯器可以在這一層做更激進(jìn)的優(yōu)化。
0x03 如何啟用
Hardhat
// hardhat.config.js
module.exports = {
solidity: {
version: "0.8.26",
settings: {
viaIR: true,
optimizer: {
enabled: true,
runs: 200
}
}
}
};
Foundry
# foundry.toml
[profile.default]
solc_version = "0.8.26"
via_ir = true
optimizer = true
optimizer_runs = 200
注意： viaIR 必須配合 optimizer 使用，否則生成的字節(jié)碼會(huì)非常臃腫。
0x04 解決 Stack Too Deep
啟用 via_IR 前：
function complexFunction(
address token,
uint256 amount,
address recipient,
uint256 deadline,
bytes32 data
) external {
uint256 balance = IERC20(token).balanceOf(address(this));
uint256 allowance = IERC20(token).allowance(msg.sender, address(this));
uint256 fee = amount * feeRate / 10000;
uint256 netAmount = amount - fee;
// ... 更多局部變量
// ? CompilerError: Stack too deep
}
啟用 via_IR 后：
// ? 編譯通過(guò)，不需要任何代碼改動(dòng)
編譯器會(huì)自動(dòng)把棧上的變量挪到內(nèi)存或其他位置，你不用手動(dòng)重構(gòu)代碼。
0x05 優(yōu)化效果
via_IR 不只解決 stack too deep，還能優(yōu)化 Gas。
案例 1：去除冗余計(jì)算
function calculate(uint256 x) public pure returns (uint256) {
uint256 a = x * 2;
uint256 b = x + x; // 和 a 等價(jià)
return a + b;
}
via_IR 會(huì)識(shí)別出 a 和 b 等價(jià)，合并計(jì)算。
案例 2：內(nèi)聯(lián)優(yōu)化
function _transfer(address from, address to, uint256 amount) private {
balances[from] -= amount;
balances[to] += amount;
}
function transfer(address to, uint256 amount) external {
_transfer(msg.sender, to, amount);
}
如果 _transfer 只被調(diào)用一次，via_IR 會(huì)直接內(nèi)聯(lián)，省去函數(shù)調(diào)用開(kāi)銷(xiāo)。
0x06 代價(jià)和注意事項(xiàng)
1. 編譯時(shí)間變長(zhǎng)
via_IR 的編譯時(shí)間是傳統(tǒng)模式的 2-5 倍。
對(duì)于大項(xiàng)目（幾十個(gè)合約），編譯可能需要幾分鐘。
解決方案：
- 開(kāi)發(fā)時(shí)用傳統(tǒng)模式快速迭代
- 部署前切換到 via_IR 做最終優(yōu)化
// hardhat.config.js
const useViaIR = process.env.PRODUCTION === 'true';
module.exports = {
solidity: {
settings: {
viaIR: useViaIR,
optimizer: { enabled: true, runs: useViaIR ? 200 : 800 }
}
}
};
2. 字節(jié)碼可能變大
啟用 via_IR 后，某些合約的字節(jié)碼會(huì)比傳統(tǒng)模式更大（尤其是小合約）。
如果合約接近 24KB 限制，測(cè)試后再?zèng)Q定是否啟用。
3. 調(diào)試?yán)щy
via_IR 生成的字節(jié)碼和源碼對(duì)應(yīng)關(guān)系不如傳統(tǒng)模式清晰，stack trace 可能不準(zhǔn)確。
生產(chǎn)環(huán)境建議同時(shí)保留兩個(gè)版本的 ABI + 字節(jié)碼。
4. 工具鏈兼容性
一些老版本的工具可能不支持 via_IR 生成的字節(jié)碼：
- ? Etherscan 驗(yàn)證：支持（需要在驗(yàn)證時(shí)勾選 via_IR）
- ? Tenderly 調(diào)試：支持
- ?? 部分老版本 Hardhat 插件：可能有問(wèn)題
0x07 最佳實(shí)踐
1. 什么時(shí)候用 via_IR
推薦啟用：
- 遇到 stack too deep 錯(cuò)誤
- 合約邏輯復(fù)雜，優(yōu)化空間大
- 追求極致的 Gas 優(yōu)化
可以不用：
- 簡(jiǎn)單合約（<100 行代碼）
- 字節(jié)碼已經(jīng)接近 24KB 限制
- 開(kāi)發(fā)階段需要快速編譯
2. 配合 optimizer runs 調(diào)優(yōu)
// 高頻調(diào)用合約（如 DEX Router）
optimizer: { runs: 200 }
// 低頻部署合約（如 Factory）
optimizer: { runs: 1 }
// 平衡（大多數(shù)情況）
optimizer: { runs: 800 }
via_IR 模式下，runs 的影響比傳統(tǒng)模式更顯著。
3. CI/CD 中測(cè)試兩種模式
# .github/workflows/test.yml
- name: Test without viaIR
run: npm test
- name: Test with viaIR
run: PRODUCTION=true npm test
確保兩種模式下行為一致。
0x08 實(shí)戰(zhàn)案例
某 DeFi 項(xiàng)目的 swap 函數(shù)：
傳統(tǒng)模式：
- ? Stack too deep 錯(cuò)誤
- 不得不拆成 3 個(gè)函數(shù)
- Gas 消耗：~180k
via_IR 模式：
- ? 單函數(shù)完成
- Gas 消耗：~165k（節(jié)省 8%）
- 編譯時(shí)間：從 5 秒增加到 18 秒
對(duì)于生產(chǎn)環(huán)境，這點(diǎn)編譯時(shí)間完全值得。
0x09 總結(jié)
via_IR 是 Solidity 的未來(lái)。Solidity 團(tuán)隊(duì)計(jì)劃在未來(lái)版本中默認(rèn)啟用它。
現(xiàn)在就開(kāi)始使用，你會(huì)：
- 再也不用為 stack too deep 煩惱
- 獲得更好的 Gas 優(yōu)化
- 代碼更簡(jiǎn)潔（不用手動(dòng)拆函數(shù)）
唯一代價(jià)是編譯時(shí)間變長(zhǎng)，但這點(diǎn)成本相比收益完全可以接受。
如果你的項(xiàng)目還在用傳統(tǒng)編譯模式，試試 viaIR: true 吧。
推薦閱讀：
