将以太坊交易类型比作邮件的格式版本再合适不过：Legacy交易像老式信件，只能靠手动贴邮票（gasPrice）来决定投递速度；而EIP-1559之后的类型则像现代快递，系统会自动帮你拆分基础费用和小费，让报价更合理。EIP-8140在这个基础上进一步规范了交易类型的注册与扩展机制，使得新的交易类型可以以标准化的方式被钱包、节点和前端框架识别。React应用作为与用户直接交互的前端层，是交易类型迁移的第一现场，本文将完整拆解这次迁移需要做的每一件事。
一、先弄清楚各交易类型的结构与差异
迁移之前必须先理解对象。目前以太坊主网上实际存在的交易类型有三种：Legacy（无类型前缀）、EIP-2930的type 1（引入访问列表accessList）以及EIP-1559的type 2（引入maxFeePerGas与maxPriorityFeePerGas双参数）。EIP-8140并不推翻这些类型，而是建立一套交易类型的扩展规范，允许链和应用以统一方式声明、协商和使用新的类型化交易，避免各钱包各自为政。
从序列化角度看，类型化交易在RLP编码的最外层多了一个类型字节，例如type 2交易的签名哈希前缀是0x02，而Legacy交易直接从RLP列表开始。这意味着前端在估算Gas、填充Nonce、组装签名载荷时，传参结构完全不同。最常见的错误是沿用Legacy的gasPrice字段去构造type 2交易，ethers在v6中会直接抛出参数冲突异常。
对React应用而言，还有一个容易被忽视的差异：钱包返回的transaction hash格式。MetaMask等钱包在签名type 2交易后返回的哈希与Legacy交易的计算方式不同，如果你的应用里有本地预计算哈希做校验的逻辑，必须同步更新。理解了这些底层差异，后面的代码改造才不会流于表面。
二、依赖升级与Provider层的改造
第二步是升级依赖。ethers.js的v5版本对type 2交易支持尚可，但EIP-8140相关的类型协商需要v6.7以上；web3.js则建议直接升到4.x。以ethers为例，先确认版本：
npm ls ethers npm install ethers@latest
升级后，Provider的初始化代码基本无需变动，但获取费用建议的方式要改。旧代码通常直接读取gasPrice，新代码应改用feeData：
import { BrowserProvider, formatUnits } from "ethers";
const provider = new BrowserProvider(window.ethereum);
async function getFeeSuggestion() {
const fee = await provider.getFeeData();
console.log("maxFeePerGas:", formatUnits(fee.maxFeePerGas, "gwei"), "gwei");
console.log("priorityFee:", formatUnits(fee.maxPriorityFeePerGas, "gwei"), "gwei");
return fee;
}注意feeData在某些不支持伦敦升级或EIP-4844的网络中，maxFeePerGas可能为null，因此回退逻辑必不可少。建议在Provider层封装一个统一的buildTxParams函数，根据链ID和能力探测结果决定使用哪种类型的参数，让上层组件完全不感知差异。这种集中式封装也方便后续接入EIP-8140定义的类型协商接口。
三、交易构造与签名的具体改造
以一个典型的React转账组件为例。旧代码通常长这样：
// 旧写法：Legacy交易
async function sendLegacy(to, valueWei) {
const signer = await provider.getSigner();
const gasPrice = await provider.getGasPrice();
return signer.sendTransaction({
to: to,
value: valueWei,
gasLimit: 21000n,
gasPrice: gasPrice
});
}迁移后的写法应改用动态费用字段，并预留EIP-8140类型的扩展位：
// 新写法：type 2动态费用交易，支持类型扩展
async function sendTyped(to, valueWei, extraTypes) {
const signer = await provider.getSigner();
const fee = await provider.getFeeData();
const tx = {
to: to,
value: valueWei,
gasLimit: 21000n,
maxFeePerGas: fee.maxFeePerGas,
maxPriorityFeePerGas: fee.maxPriorityFeePerGas,
type: 2, // 显式声明类型，也可由协商结果动态填充
accessList: [] // type 1/2均支持，预编译合约场景可显著省Gas
};
// EIP-8140：若钱包声明支持扩展类型，合并附加参数
if (extraTypes && extraTypes.supported) {
Object.assign(tx, extraTypes.params);
}
return signer.sendTransaction(tx);
}两点值得强调。第一，显式设置type: 2可以避免某些RPC节点在参数齐全时仍回退到Legacy行为；第二，accessList虽然对普通转账没有收益，但对调用预编译合约（如一批SSTORE操作）能节省可观的Gas，React应用中批量操作的场景应当评估。另外，所有涉及金额的运算建议使用BigInt，ethers v6已移除对 BigNumber 旧用法的部分兼容，越早改造越省事。
四、钱包兼容性检测与优雅降级
前端无法假设所有用户的钱包都支持最新交易类型，兼容性检测是迁移中最容易被跳过的一环。可以在应用启动时通过wallet_getCapabilities或EIP-8140定义的协商方法探测钱包能力，把结果存入全局Context：
import { createContext, useContext, useEffect, useState } from "react";
const CapContext = createContext({ typedTx: false });
export function CapProvider({ children }) {
const [caps, setCaps] = useState({ typedTx: false });
useEffect(() => {
async function detect() {
try {
const res = await window.ethereum.request({
method: "wallet_getCapabilities"
});
setCaps({ typedTx: Boolean(res && res.typedTransactions) });
} catch (e) {
// 不支持该方法的老钱包，降级为Legacy
setCaps({ typedTx: false });
}
}
detect();
}, []);
return <CapContext.Provider value={caps}>{children}</CapContext.Provider>;
}
export const useCaps = () => useContext(CapContext);有了能力上下文，交易发送函数就可以根据typedTx标志在type 2与Legacy之间切换，而不是让用户面对一堆莫名的报错。降级时的用户提示也建议做成中文友好文案，例如当前钱包版本较旧，已自动切换为兼容模式，这比直接弹出英文异常字符串体验好得多。
最后别忘了回归测试。使用Hardhat或Anvil在本地 fork 主网，分别模拟支持和不支持新类型的钱包环境，覆盖交易成功、用户拒绝签名、Gas不足、Nonce过期四类场景。迁移完成后，建议在监控中给交易类型打上标签，观察线上Legacy与新类型的占比变化，确认降级路径是否被频繁触发，从而反推用户钱包生态的升级进度。整个迁移的核心思路可以总结为一句话：类型协商集中在Provider层，参数构造收敛到统一函数，兼容性检测前置到应用启动，三者到位，React应用就能在新旧交易类型之间自由切换。
ReactEIP8140Transaction Types修改时间：2026-09-03 00:19:05