CREATE2 地址的算法本身只有一行：keccak256(0xff ++ deployer ++ salt ++ keccak256(init_code))[12:]。但部署前预测经常出错，原因几乎都不在公式，而在两个输入：deployer 到底是谁，以及 init_code 到底是什么。算错任何一个，预测地址和实际部署地址就会对不上。
公式里每一项的确切含义
根据 EIP-1014 的规范，四个组成部分需要逐字理解。
0xff 是一个固定字节，作用是让 CREATE2 算出的地址不可能与传统的 CREATE（keccak256(rlp([sender, nonce]))）地址碰撞。
deployer 是执行 CREATE2 操作码的地址，固定 20 字节。这是最容易搞错的一项。如果你通过一个工厂合约部署，deployer 是这个工厂合约的地址，不是你个人的 EOA 钱包地址。如果你用 Foundry 脚本里的默认 CREATE2 deployer，它是 0x4e59b44847b379578588920cA78FbF26c0B4956C。先确认你的交易最终是由哪个地址调用的 CREATE2，再填这个字段。
salt 是你选择的 32 字节值。它没有格式要求，但它的选择会影响地址，也影响安全性。
keccak256(init_code) 是初始化代码的哈希，不是运行时字节码的哈希。init_code 是"执行后产生运行时字节码"的那段代码，在 Solidity 里通常包含构造函数逻辑和构造函数参数。构造函数参数必须拼进 init_code 再哈希，单独对 type(MyContract).creationCode 做哈希而漏掉参数，算出来的地址一定是错的。
公式最后取哈希结果的后 20 字节（即 [12:]），这就是合约地址。
用工具算，而不是手算
手动拼字节再算 keccak256 容易出错，日常核验用工具更可靠。
Foundry 的 cast 提供了直接的计算命令。如果你有 init_code 的完整内容（包含构造参数），可以用 cast create2 --salt --init-code 得到地址。如果你已经有 init_code 的哈希，用 cast compute-address 并传入 --init-code-hash 也可以。在 Solidity 测试里，Foundry 的 cheatcode vm.computeCreate2Address(salt, initCodeHash, deployer) 可以直接在测试中断言预测地址和实际部署地址是否一致。注意两个参数的重载使用的是默认 deployer，如果你在测试合约里直接 new Contract{salt: salt}()，deployer 是测试合约本身，需要传三个参数的版本。
ethers.js 的 ethers.getCreate2Address(deployer, salt, initCodeHash) 做同样的计算。你需要在调用前自己把构造函数参数编码并拼到 creationCode 后面，再取 keccak256。
预测和实际对不上，先查这四处
第一，deployer 填错了。 你用的是自己的 EOA 地址，但实际部署走的是一个工厂合约。或者你在本地测试时 deployer 是测试合约地址，上链后换成了另一个工厂。把交易的实际 to 地址或触发 CREATE2 的合约地址找出来，替换 deployer 重新算。
第二，init_code 里少了或多了解码参数。 构造函数参数的类型和值必须与实际部署时完全一致。abi.encode 和 abi.encodePacked 对某些类型会产生不同结果，使用你在部署脚本或合约调用中实际传入的编码方式。
第三，Solidity 的元数据变了。 这是一个不容易察觉但很关键的问题。Solidity 默认在字节码末尾附加 CBOR 编码的元数据，包含源码哈希、编译器版本、文件路径等信息。即使合约逻辑没改，仓库路径变化或依赖版本变动都可能导致元数据变化，进而改变 keccak256(init_code) 和 CREATE2 地址。如果要求跨环境或跨链的确定性部署，在 Foundry 配置中设置 bytecode_hash = "none" 和 cbor_metadata = false 可以去掉这部分元数据，让字节码稳定下来。代价是区块浏览器上的合约验证可能显示为"部分匹配"而非"完全匹配"。
第四，salt 的类型或编码不一致。 如果你在 Solidity 里用 bytes32 salt = keccak256("my-salt")，在链下算的时候也要做同样的 keccak256，而不是直接把字符串转成 bytes32。两边用同一种方式生成 salt。
核验：部署后拿实际地址回比
部署交易确认后，从交易回执或区块浏览器拿到实际创建的合约地址，和你预测的地址逐字节比对。一致，说明公式和输入都对了。不一致，用上面四个分支逐一排查。
有一个边界需要知道：CREATE2 允许地址碰撞，但碰撞时的行为由 EIP-684 规定——如果目标地址已经有非零 nonce 或非空代码，创建会立即失败，Gas 被消耗，原有状态不变。这意味着你不能用 CREATE2 覆盖一个已存在的合约。如果预测地址上已经有东西，部署会 revert，而不是替换。
另外，如果你在使用一个公开的 CREATE2 工厂，确认该工厂在你目标链上的地址与你在计算时用的 deployer 一致。同一个工厂在不同链上的部署地址理论上可以相同（如 EIP-7997 推动的 0x4e59...），但并非所有链都已预置。部署前在目标链的浏览器上查一下工厂合约是否存在。
参考资料
- Ethereum Improvement Proposals·EIP-1014: Skinny CREATE2，页面未标明更新日期；核查日期：2026-10-20。
- Foundry·Deterministic Deployments with CREATE2，页面未标明更新日期；核查日期：2026-10-20。
- Foundry·computeCreate2Address Cheatcode Reference，页面未标明更新日期；核查日期：2026-10-20。
- Foundry·cast compute-address Reference，页面未标明更新日期；核查日期：2026-10-20。
- GitHub·Non-deterministic CREATE2 deployments due to Solidity bytecode metadata (ithacaxyz/account #348)，页面未标明更新日期；核查日期：2026-10-20。
- Ethereum Improvement Proposals·EIP-7997: Deterministic Factory Contract，页面未标明更新日期；核查日期：2026-10-20。
- Foresight News·智能合约安全审计入门篇 —— Deploy Different Contracts to the Same Address，页面未标明更新日期；核查日期：2026-10-20。
