Go 语言调用 go-ethereum 的核心是正确初始化 *ethclient.Client 并理解 RPC 上下文生命周期；需用 context.WithTimeout 设置超时，地址须经 common.IsHexAddress 校验，BlockByNumber 返回 nil 时须显式判空。
Go 语言调用 go-ethereum 的核心不是“学教程”，而是正确初始化 *ethclient.Client 并理解 RPC 上下文生命周期。
为什么 ethclient.Dial 常报 context deadline exceeded？
这不是网络连不上，而是你没传或传错了 context.Context —— go-ethereum 所有 API（如 BalanceAt、BlockByNumber）都强制要求带超时上下文。直接用 context.Background() 在生产环境极易卡死或堆积 goroutine。
- ✅ 正确做法：始终用
context.WithTimeout(context.Background(), 10*time.Second) - ❌ 错误写法：
client.BalanceAt(ctx, addr, nil)中的ctx是context.Background()且未设限 - ⚠️ 注意：Geth 节点若启用了
--http.timeout（如60s），你的 client 端 context timeout 必须比它更短，否则会提前中断
common.Address 和 common.HexToAddress 容易出错在哪？
地址字符串校验不严格导致静默失败 —— common.HexToAddress("0x123") 不 panic，但返回的是截断后的非法地址；调用 BalanceAt 时返回 0，你以为余额为 0，其实是地址根本无效。
- ✅ 验证方式：用
common.IsHexAddress(s string)先判断是否合规（含 0x + 40 字符 + 大小写混合校验） - ✅ 安全转换：
if common.IsHexAddress(addrStr) { addr = common.HexToAddress(addrStr) } - ⚠️ 特别注意：
common.HexToAddress不做 checksum 验证（EIP-55），需手动调用common.IsHexAddress或用common.UnmarshalText配合 error 检查
读区块数据时，BlockByNumber 返回 nil 但无 error？
这是 Geth 的“优雅失败”设计：当区块不存在（如高度超出当前链头、或快同步模式下历史区块被剪裁），BlockByNumber 直接返回 nil, nil，而不是 error。新手常因此漏判空指针 panic。
立即学习“go语言免费学习笔记（深入）”；
- ✅ 必须显式判空：
if block == nil { log.Printf("block %d not found", num) } - ✅ 查最新块高建议用
HeaderByNumber(ctx, nil)（nil表示最新头），再取Number().Int64() - ⚠️ 同步模式影响：启用
--syncmode=light时，BlockByNumber对非头区块大概率返回 nil；私链开发请用--syncmode=fast或snap
go-ethereum 的 Go binding 表面简单，实则每层都藏着上下文、地址有效性、区块存在性三重隐性契约。漏掉任意一环，程序不会立刻报错，而是在某个交易失败、余额为 0 或日志静默时才暴露问题 —— 这正是最该花时间写单元测试的地方。
