用abigen生成Go结构体需：1.从对应go-ethereum源码编译abigen；2.使用合约最终编译的ABI JSON；3.命令中--type名与合约名一致；4.检查生成方法参数类型是否正确。
怎么用 abigen 生成可调用的 Go 结构体
abigen 是 go-ethereum 提供的 ABI 转 Go 代码工具，不是可选步骤，是必须环节——没有它，你就只能手写 ABI 解析逻辑，极易出错且无法校验参数类型。
常见错误现象：abi: cannot parse type "tuple" 或 invalid memory address，基本都源于 ABI 文件不匹配或 abigen 版本与合约编译器版本不兼容（比如用 solc 0.8.24 编译的合约，却用老版本 abigen 解析）。
-
abigen必须从对应版本的go-ethereum源码编译：进入go-ethereum/cmd/abigen目录执行go build，别用go install随便拉一个全局版本 - ABI 文件必须是部署前最终编译输出的 JSON（Remix 的 “Compile Details” → “ABI”，或
solc --abi Token.sol -o ./out），不能是 IDE 自动生成的简化版 - 生成命令中
--type名称建议与合约名一致（如Token），避免后续调用时混淆token.TokenTransactor和token.TokenSession - 生成后检查
func (*Token) Transfer签名是否含opts *bind.TransactOpts和to common.Address, value *big.Int—— 类型不对说明 ABI 解析失败
如何正确初始化 ethclient 并连接到链
连不上链，后面所有调用都是空转。最常被忽略的是协议与端口匹配问题：HTTP 不等于 IPC，本地 Geth 用 IPC 时硬写 http://localhost:8545 必然超时。
使用场景：开发用本地 Anvil/Foundry、测试网用 Alchemy/Infura、主网慎用公开 RPC（gas 估算不准、响应慢）。
立即学习“go语言免费学习笔记（深入）”；
- 本地节点优先用 IPC：
ethclient.Dial("\\.\pipe\geth.ipc")（Windows）或ethclient.Dial("/home/user/.ethereum/geth.ipc")（Linux/macOS） - HTTP 连接务必确认端口已开启且
--http.api eth,net,web3已配置；否则会报context deadline exceeded - 不要复用同一个
*ethclient.Client实例做高频并发调用——它内部有连接池但无自动重试，突发大量请求易触发i/o timeout - 加个简单健康检查：
_, err := client.BlockNumber(context.Background())，启动时就 panic 掉配置错误，比运行中报错好定位
调用 Transfer 等写操作为什么总卡住或失败
Transfer 不是普通函数调用，它是一笔交易：需要签名、广播、等待上链。90% 的“没反应”，其实是卡在等待 receipt，而不是合约执行失败。
典型表现：ctx.Done(): context deadline exceeded，或日志里一直打印 waiting for transaction... 却没下文。
- 必须传入有效的
*bind.TransactOpts：含From地址、Signer、Nonce（推荐用auth, _ := bind.NewKeyedTransactor(key)自动管理） - Gas 估算失败很常见：
client.SuggestGasPrice(ctx)在部分 RPC（如 Infura Sepolia）可能返回 0，得 fallback 到固定值（如big.NewInt(25000000000)） - 别直接用
contract.Transfer(...)后就结束——要显式等 receipt：tx, _ := contract.Transfer(auth, toAddr, value); _, err := bind.WaitMined(ctx, client, tx) - 如果合约本身 require 失败（如余额不足），错误不会在
Transfer()返回，而是在WaitMined的 receipt 中体现为Status=0，需手动检查receipt.Status == 1
监听合约事件时为什么收不到 Log
监听不是“订阅推送”，而是轮询区块日志。收不到 event，八成是过滤条件写错了，或者区块确认延迟没处理好。
性能影响明显：监听范围太宽（如从 block 0 开始）会导致第一次同步极慢，甚至 OOM。
- 过滤必须指定
contractAddress和topics：用contract.FilterTransfer(&opts, nil, nil)生成的topic才可靠，别手写common.HexToHash("...") - 起始区块别写死
big.NewInt(0)，改用client.BlockNumber(ctx)减去若干确认数（如 -100），避免因重组丢 log - 监听循环里必须加
time.Sleep(3 * time.Second)，否则高频轮询会让 RPC 崩溃或限流 - Receipt 中的
Logs是 raw data，需用contract.ParseTransfer(log)（abigen 生成的方法）解包，否则字段全是空
Golang 调用合约真正难的不是语法，是每个环节都依赖外部状态：链是否同步、key 是否解锁、gas 是否够、event topic 是否对齐……漏掉任意一环，程序就静默失败。调试时先打日志看哪一步 nil 或 err != nil，比猜更有效。
