查 ERC-20 代币余额必须调用合约 balanceOf 方法，不能用 BalanceAt；需准备 ABI（推荐 abigen 生成绑定），设置 to 为代币地址、data 为编码后的 balanceOf 调用数据；用 CallContract 发起只读调用，注意地址带 0x 前缀、节点同步状态及合约有效性验证。
如何用 Go 调用以太坊节点查 ERC-20 代币余额
直接结论：不能只靠 eth_client.BalanceAt，它查的是 ETH 余额；查代币必须调用 ERC-20 合约的 balanceOf 方法，本质是发一个只读合约调用（eth_call）。
常见错误是把代币当成原生资产去查，结果始终返回 0 或报 invalid opcode——因为没指定合约地址和 ABI。
- 必须提前准备好代币合约的 ABI（至少包含
balanceOf函数定义），可用abigen生成绑定，或手动构造abi.ABI - 调用时
to字段必须设为代币合约地址，data是balanceOf(address)编码后的字节序列 - 推荐用
client.CallContract而非Transact，避免误发交易；注意传入的callMsg中From可为空，但Context不能超时
为什么用 abigen 生成合约绑定比手写 call 更可靠
手写 abi.Pack 容易出错：参数类型错位、地址未 checksum 校验、返回值解包失败都会静默返回 0。而 abigen 生成的 Go 结构体强制类型安全，且封装了标准 ERC-20 方法。
- 生成命令示例：
abigen --abi erc20.abi --pkg token --out token.go，其中erc20.abi需含balanceOf函数定义 - 生成后直接调用：
token.NewToken(common.HexToAddress(tokenAddr), client).BalanceOf(&bind.CallOpts{}, accountAddr) - 注意
bind.CallOpts的Context和Pending字段：查最新确认余额设Pending: false；查 pending 状态需显式开启（部分节点不支持）
查询失败的三个高频原因及对应检查点
返回 0 或 panic 不一定代码错，更可能是环境或参数问题。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
invalid argument 0: json: cannot unmarshal hex string without 0x prefix：传入的合约地址或账户地址缺0x前缀，务必用common.HexToAddress解析 - 返回
0但链上实际有余额：检查节点同步状态（eth_syncing返回false）、区块高度是否足够新、代币地址是否正确（例如 USDT 在以太坊主网和 Polygon 是不同合约） -
execution reverted：合约地址不是 ERC-20，或该地址根本不是合约（codeAt返回空），可用client.CodeAt(ctx, addr, nil)验证
性能与并发注意事项
批量查多个地址余额时，并发请求容易触发节点限流（尤其是免费 Infura/Alchemy endpoint），且 Go 的 http.Transport 默认连接池较小。
- 单个客户端实例可复用，但不要在高并发下共享未配置的
rpc.Client；建议设置http.Transport.MaxIdleConnsPerHost = 100 - 避免为每个查询新建
bind.CallOpts，复用并仅修改Context字段更轻量 - 如果查同一代币的多个地址，优先用
multicall合约聚合（需自行部署或使用已有的 Multicall3），单次 RPC 调用替代 N 次
真正麻烦的从来不是调用那行代码，而是地址校验、ABI 匹配、节点可靠性这三环——漏掉任意一环，返回的 0 都看不出真假。
