传统ERC721标准在批量铸造场景下的gas开销几乎与铸造数量成正比，每新增一个token就要更新一次所有者的余额映射和tokenId归属。这种设计对单个铸造足够直观，但NFT项目开启批量mint时，用户需要为每一笔交易重复支付大量存储费用。ERC721A通过一种延迟写入和区间映射的数据结构，把批量铸造压缩成一次余额更新，再在查询时通过起止tokenId反推归属，从而让批量铸造的费用只比单次略高。迁移到ERC721A之后，React前端不再逐个调用mint，而是把数量参数传给一个批量铸造函数。
下文将从合约改造、React调用方式和交易状态管理三个层面拆解这次迁移。
一、将ERC721合约改写为ERC721A批量铸造
ERC721A的核心是把用户拥有的代币数量记录为一个整数，而不是为每个tokenId单独维护所有权。常规ERC721在循环中执行_safeMint时，每次都要更新balanceOf、ownerOf和tokenURI等映射；ERC721A的_safeMint在传入数量大于1时，只更新一次用户的数量和全局的已铸造总数，具体的tokenId区间由算法推导。这样做带来的直接好处是，批量铸造10个NFT的gas成本可能只有传统方式的20%到30%。
合约层面需要继承ERC721A，并把原有的单个mint函数替换为接收quantity参数的批量函数。函数内部要校验总供应量、单钱包限额和付款金额，然后直接调用_safeMint(msg.sender, quantity)。下面是一个可用的Solidity合约示例。
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
import "@openzeppelin/contracts/access/Ownable.sol";
import "erc721a/contracts/ERC721A.sol";
contract BatchNFT is ERC721A, Ownable {
uint256 public constant MAX_SUPPLY = 10000;
uint256 public constant MAX_PER_WALLET = 10;
uint256 public mintPrice = 0.01 ether;
constructor() ERC721A("BatchNFT", "BNFT") Ownable(msg.sender) {}
function mintBatch(uint256 quantity) external payable {
require(quantity > 0, "quantity must be positive");
require(_totalMinted() + quantity <= MAX_SUPPLY, "sold out");
require(_numberMinted(msg.sender) + quantity <= MAX_PER_WALLET, "exceeds wallet limit");
require(msg.value >= mintPrice * quantity, "insufficient funds");
_safeMint(msg.sender, quantity);
}
function setMintPrice(uint256 price) external onlyOwner {
mintPrice = price;
}
function withdraw() external onlyOwner {
payable(owner()).transfer(address(this).balance);
}
}
注意其中_totalMinted和_numberMinted都是ERC721A提供的查询函数，不需要额外存储变量就能获得当前总发行量和某个地址已铸造数量。批量函数的付款计算必须用乘法，不能只判断固定单价，否则会出现数量大于1时仍然只收一次费用的漏洞。
二、React前端从单个Mint迁移到批量Mint
前端迁移的主要改动在调用参数和付款金额上。原来单个铸造只需要用户点击按钮，value固定为mintPrice；批量铸造则需要一个数量输入框，把quantity传给合约，并将value设为mintPrice乘以quantity。如果用wagmi，可以使用usePrepareContractWrite来构造批量铸造的调用配置，再通过useContractWrite执行交易。
下面的React组件展示了完整的批量铸造交互。代码中限制了单次最大数量为10，并动态计算发送的以太金额。当交易进入等待状态时，按钮会显示铸造中，避免用户重复点击。
import { useState } from 'react';
import { useContractWrite, usePrepareContractWrite, useWaitForTransaction } from 'wagmi';
import { parseEther } from 'viem';
const BATCH_NFT_ABI = [
{
name: 'mintBatch',
type: 'function',
stateMutability: 'payable',
inputs: [{ name: 'quantity', type: 'uint256' }],
outputs: [],
},
];
export default function BatchMint() {
const [quantity, setQuantity] = useState(1);
const contractAddress = '0xYourContractAddress';
const mintPrice = 0.01;
const { config } = usePrepareContractWrite({
address: contractAddress,
abi: BATCH_NFT_ABI,
functionName: 'mintBatch',
args: [BigInt(quantity)],
value: parseEther((mintPrice * quantity).toString()),
enabled: quantity > 0 && quantity <= 10,
});
const { write, data, isLoading, isError, error } = useContractWrite(config);
const { isLoading: isTxLoading, isSuccess } = useWaitForTransaction({ hash: data?.hash });
return (
<div>
<input
type="number"
min="1"
max="10"
value={quantity}
onChange={(e) => setQuantity(Number(e.target.value))}
/>
<button disabled={isLoading || isTxLoading || !write} onClick={() => write?.()}>
{isTxLoading ? '铸造中...' : `批量铸造 ${quantity} 个`}
</button>
{isSuccess && <p>铸造成功！</p>}
{isError && <p>错误：{error?.message}</p>}
</div>
);
}
其中parseEther来自viem，用于把0.01乘以数量后的小数转换为Wei。enabled条件确保数量在1到10之间时才允许构造交易。迁移时还要注意：如果之前的ABI里mint函数没有quantity参数，现在要改为uint256类型，并且调用时value必须动态计算，不能沿用旧值。
三、批量铸造的状态管理与部署测试
批量铸造的交易等待时间和失败概率比单个mint更高，前端需要明确区分用户提交前、待签名、交易广播、确认失败和确认成功等多个状态。使用useWaitForTransaction可以方便地拿到交易哈希和最终的receipt，但要注意交易写入后可能因为revert而失败，此时不能只依赖isLoading判断，还要展示error中的具体原因。常见的失败原因包括数量超过单钱包限制、总供应量已满或者用户取消了钱包签名。
在本地测试时，建议先使用Hardhat启动节点，并在React项目的环境变量中配置本地RPC地址。以Windows系统为例，合约项目可能位于C:\projects\nft-batch目录，执行测试和部署的命令可以在PowerShell中运行。部署前要把合约地址写入前端.env文件，例如REACT_APP_BATCH_NFT_ADDRESS=0x...。如果使用Hardhat的本地节点，前端网络切换需要保持一致，否则会出现合约地址尚未部署的错误。
cd C:\projects\nft-batch npx hardhat test npx hardhat run scripts/deploy.js --network localhost
批量铸造上线前还要重点检查合约的收款函数和数量边界。由于ERC721A的_safeMint会检查接收地址是否为合约，如果用户通过合约钱包铸造，需要确保该合约实现了标准的接收逻辑。前端可以为用户显示当前已铸造数量、剩余额度以及单笔gas预估，提升批量铸造的成功率和体验。迁移完成后，整个应用既能降低用户的gas支出，又能通过批量购买提升NFT发售效率。
