事件日志为何会重复：链重组与数据抓取去重方法
事件日志重复通常是因为链重组（Reorg）——以太坊主网临时分叉了，你看到的是旧链和新链上同一笔交易的日志先后被播报了一遍。处理方式是：用(transactionHash, logIndex) 做唯一主键去重，并且只把 removed 标志为 false 或 null 的事件视为最终有效。
1. 为什么重组会导致日志重复
以太坊的链是不断"长"出来的，偶尔会有两个矿工同时挖出新区块，链就会暂时分叉。节点会观察一下哪条链更重，然后抛弃短的那条，这就是链重组。
重组期间，订阅了 logs 接口的应用会经历两次事件推送：
旧链上已经发过一次的日志，会被重新推送一遍，但这次会带一个字段：
removed: true。新链上新区块里包含了同样的交易，节点会再次把这条日志推送过来（没有
removed字段）。
这就导致你的应用收到了两条"同一笔交易产生的事件"，也就是"事件日志重复"。Alchemy 的 API 文档明确标注了这一行为。
2. 如何判断哪条日志才是有效的
步骤1：检查 removed 字段
做什么：在收到的每条事件日志响应里，找到
removed这个布尔值字段。怎么做：
情况A（
removed为true）：这条日志来自一条被废弃的链，无效。不要处理它，或者把它从数据库里删掉（如果你之前已经存了）。情况B（
removed不存在或为false）：这条日志来自当前主链（规范链），最终有效。可以安全地处理或落库。
做到什么程度算完成：你能清楚地区分哪条日志来自旧链、哪条来自新链。
步骤2：用"确认数"机制延迟处理
做什么：不要交易一上链就立刻处理它的日志，等它后面多挖出几个区块再处理。
怎么做：在代码逻辑里设置一个确认深度（比如等待 12-15 个区块确认）。Ethereum.org 和各类索引器方案都建议用这种机制来降低浅层重组带来的脏数据风险。
做到什么程度算完成：你只在交易回执得到足够多的确认后才触发业务逻辑，避免被短时分叉带偏。
前置条件：你正在通过节点的 RPC 接口或 WebSocket 订阅
logs事件，或者在用eth_getLogs做历史查询。如果你只是在 Etherscan 上手工看交易记录，不会遇到这个问题——浏览器已经帮你处理好了。
3. 抓数据的去重方法
如果你在搭建自己的链上索引器，不能在代码里简单"插入新记录"，必须用"插入或更新"的幂等逻辑。
步骤3：用复合主键去重
做什么：在数据库里，用
(transactionHash, logIndex)这两个字段组成联合唯一键。怎么做：
transactionHash：产生这条日志的交易哈希。logIndex：这条日志在交易内的索引位置（从 0 开始）。这两个字段组合在一起，唯一标识一条特定的链上日志。
做到什么程度算完成：你的数据库表设置了这个联合唯一索引，即使节点把同一条日志重放三次，也不会写入重复数据。
步骤4：收到 removed=true 时，删除或标记旧记录
做什么：当收到一条
removed=true的日志时，用它的(transactionHash, logIndex)去数据库里删除对应行。怎么做：这是链上索引器的标准做法。开源项目演示了这种回滚逻辑：维护最近 N 个区块的哈希，一旦发现分叉，立即回退到公共祖先区块，把后续的日志全部清掉。
做到什么程度算完成：数据库里的数据最终只保留新链上的那一份日志，没有残留的无效数据。
风险提醒：如果你只监听
newHeads订阅而不检查removed字段，或者依赖简单的"按区块号递增"逻辑入库，你会在重组发生时漏掉状态变更，数据库里会残留旧链的假数据。这在需要精确统计交易金额（如 DeFi 借贷协议）的场景里会引发严重对账问题。
做完以上设置，怎么确认去重逻辑生效了？
在测试链上模拟一次重组（部分 RPC 节点工具支持强制分叉），观察你的监听服务：如果收到了两次同一笔交易的日志，但第二次被标记为 removed，而你数据库里始终只有一条有效记录——说明你的去重和回滚机制已经生效了。下一步，把确认深度设到你能接受的平衡点（通常 12 个区块）。
