通过Infura在主/测试网运行Uniswap交易对监听脚本日志稀疏问题咨询

完全不符合以太坊主网的实际链上事件规模。作为参照：正常以太坊主网的Uniswap V2 Factory合约，日均产生的PairCreated事件通常在数百到数千量级，全天持续运行的脚本只捕获3-5个属于典型的监听异常。
即便是Sepolia、Goerli这类公共测试网，全天持续监听的正常捕获量也不会只有3-5个，普遍能达到几十到上百的水平，出现极低捕获量基本可以判定脚本存在问题。

结合你当前使用Infura节点+ethers.js on监听的技术栈，大概率是以下几类问题：

• Infura免费/基础套餐的订阅节流限制
  免费档、低阶付费档的Infura节点，对websocket事件订阅存在内置的节流规则：不会全量推送所有匹配合约地址的日志，会主动过滤Gas价格低、交易对知名度低、来自陌生地址的创建交易，只推送其风控规则内的少量事件。很多开发者刚接触的时候会默认节点会全量推送日志，实际上免费档的订阅本身就是裁剪过的，哪怕监听器逻辑没有问题，也会漏掉绝大多数事件。
• 合约ABI定义和链上实际事件签名不匹配
  你当前写的PairCreated事件ABI存在明显偏差：主网Uniswap V2 Factory的真实事件签名是event PairCreated(address indexed token0, address indexed token1, address indexed pair, uint256)，你在代码里漏了第三个pair参数的indexed标识。
  这种偏差会直接导致ethers计算出来的事件主题哈希和链上实际的事件哈希不匹配，本地监听器会默认按ABI中标记的indexed参数个数匹配日志的topics数组长度，绝大多数实际链上的日志会被直接判定为“非监听目标事件”丢弃，只有极少数参数长度刚好能对上的日志会被碰巧解码触发回调，最终表现就是全天只能零星收到3-5个事件。
• 长连接掉线无重连逻辑导致的假死状态
  factory.on模式依赖websocket长连接实时接收节点推送的新日志，免费档Infura节点每24小时会强制断开一次长连接，加上公网网络抖动的影响，如果代码里没有写连接断开后的自动重连、重新订阅逻辑，监听器会进入表面正常运行、实际已经收不到任何新事件的假死状态。你以为脚本全天在跑，实际上有效监听时长可能只有启动后的1-2小时，自然捕获的事件数极低。
• 纯实时监听无补漏机制的天然漏损
  只靠on回调做实时监听，本身就是“尽力捕获”的模式：只要出现一次连接中断、节点丢日志，中断期间发生的所有PairCreated事件就会完全漏掉。如果没有做定期轮询补漏（比如每隔10个区块主动拉取上次处理区块高度到当前高度的所有PairCreated日志），在免费节点连接稳定性差的场景下，漏损率会非常高。
• 监听的Factory地址和你预期的网络/版本不匹配
  如果实际填的Factory地址是测试网已经废弃的旧版合约、或者网络链ID配置错了（比如本来要接主网，实际连到了测试网的冷门Factory），这个地址本身全天的新交易对创建数就只有3-5个，那捕获量就是正常的，但这种情况不属于主网的实际事件规模。

内容的提问来源于stack exchange，提问作者t-nail