golang如何监听以太坊事件日志_golang以太坊事件日志监听技巧-web3.0-PHP中文网

用 eth_subscribe 实时监听合约事件需连接 WebSocket 节点，手动处理重连、校验地址格式、正确计算 topics 哈希、避免指定区块范围，并并发安全读取日志通道。

golang如何监听以太坊事件日志_golang以太坊事件日志监听技巧

Go 监听以太坊事件最直接的方式就是走 WebSocket + eth_subscribe，但它不是“连上就自动收”，而是需要一个持续活跃的连接和手动错误恢复。HTTP RPC（比如 eth_getLogs）是轮询，而 eth_subscribe 是推送——快，但脆弱。

必须用支持 WebSocket 的客户端，比如 ethclient.Dial("wss://...")，http:// 或 https:// 地址会直接 panic
节点必须开启 ws 支持（Geth 启动加 --ws，Infura/Alchemy 的免费 tier 通常默认开）
订阅后若网络抖动或节点重启，SubscribeFilterLogs 不会自动重连，你得自己监听 watcher.Errors 并重建订阅
别在 defer client.Close() 后再启动监听循环——连接关了，channel 就永远阻塞了

传给 SubscribeFilterLogs 的 ethereum.FilterQuery 看似简单，但三个字段错一个，就收不到日志：地址、topics、区块范围不能混用。

Addresses: []common.Address{contractAddress} —— 必须是小写校验和格式，大写地址（如 MetaMask 复制的）会导致匹配失败
Topics 第一项是事件签名的 keccak256 哈希，比如 Transfer(address,address,uint256) 得算成 keccak256("Transfer(address,address,uint256)")，不是字符串字面量
如果填了 FromBlock 或 ToBlock，WebSocket 订阅会静默失败（它只接受空范围），想扫历史得换 eth_getLogs
监听多个事件？别把不同签名的 topic 混在一个 Topics[0] 里——那是“AND”关系，不是“OR”。要 OR，得开多个订阅或改用 Graph

很多人写完 client.SubscribeFilterLogs(ctx, query, ch) 就进 for { select { case log := ，结果一断网程序就挂住不动——因为错误没被消费，watcher.Errors channel 堵满后整个订阅会卡住。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

必须在同一个 select 里同时监听 ch 和 sub.Err()（不是 watcher.Errors，那是 fsnotify 的）
sub := client.SubscribeFilterLogs(...) 返回的 subscription 有 Err() 方法，它会返回一个只读 channel，一旦底层连接出问题，这个 channel 就会关闭
示例片段：
```
for {
    select {
    case err := 
```

日志里的 Data 和 Topics 都是原始字节，不靠合约 ABI 是没法还原成结构化数据的——比如你看到 Topics[1] = 0xabc...123，根本不知道这是哪个地址转出的币。

别手写 hex 解析 Topics[1] 或 Data 字段——ABI 可能含动态数组、嵌套结构，手动 decode 几乎必错
用 abi.ABI.Events[" eventName "].Inputs.Unpack(...) 才可靠，注意 Topics[0] 是事件签名，Topics[1...] 是 indexed 参数，Data 是非 indexed 参数
ABI JSON 文件必须和链上部署的合约完全一致，哪怕多一个空格，Unpack 就会返回 abi: cannot unmarshal event argument
如果 event 有 indexed address，它出现在 Topics[1]（左对齐、补零到 32 字节），不是 Data 里——这点常被误判为“解析失败”