1. 项目概述用浏览器就能“听”以太坊链上正在发生什么你有没有试过打开一个网页不装插件、不连钱包、不写一行后端代码就在控制台里直接看到刚刚被矿工打包进区块的交易不是查某个地址的历史记录而是像调频收音机一样实时捕获全网广播出来的每一条公开消息——转账、合约调用、NFT铸造、甚至DAO投票提案。这个项目标题说的正是这件事Read Public Messages from the Ethereum Network with Simple Web Programming。核心关键词就三个Ethereum以太坊、Public Messages公开消息、Simple Web Programming简易网页编程。它解决的不是“怎么发交易”而是“怎么当一个安静但高效的链上监听者”。适合谁前端工程师想快速验证合约事件、产品经理需要实时看测试网活动、学生做区块链课程作业、甚至社区运营者想自动抓取新发布的空投公告——只要你会写fetch()和console.log()就能上手。它不依赖Node.js服务端、不碰私钥、不走RPC代理中转全程在浏览器沙盒内完成用的是以太坊最基础、最开放的通信层WebSocket订阅机制。很多人以为读链上数据必须靠Alchemy或Infura这类中心化服务商其实以太坊节点原生就支持eth_subscribe而主流公共节点如QuickNode、Alchemy的免费层、甚至自建Geth节点都已开放该接口。关键在于你得知道怎么用标准Web API去“接住”它传来的JSON-RPC流式数据而不是只用eth_getLogs这种轮询式快照查询。我第一次在Chrome控制台里看到{jsonrpc:2.0,method:eth_subscription,params:{subscription:0xabc...,result:{...}}}实时刷屏时那种“原来链真的在说话”的感觉比写完一个DeFi前端还让人兴奋。2. 整体设计思路与方案选型逻辑2.1 为什么放弃HTTP轮询坚定选择WebSocket长连接初学者最容易踩的坑就是用fetch()反复调eth_getLogs或eth_getBlockByNumber来“模拟监听”。我试过——写个setInterval(() fetch(...), 2000)结果发现三秒一刷漏掉的交易比抓到的还多。原因很实在以太坊出块时间平均12秒但交易池mempool里的交易是毫秒级流动的尤其在NFT抢购或空投申领高峰一笔交易从广播到被打包可能只隔300ms。HTTP轮询本质是“盲猜时间点”你永远不知道上次请求和下次请求之间发生了什么。而WebSocket是真正的双向通道客户端发个订阅指令节点就持续把匹配的消息推过来零延迟、无遗漏。更关键的是带宽和请求配额消耗天差地别。我用同一套测试脚本对比轮询每秒1次1小时耗掉3600次API调用WebSocket长连接1小时只算1次初始连接心跳保活剩余全是免费推送。这对免费额度有限的公共节点比如Alchemy每月10M次请求简直是救命稻草。技术上eth_subscribe返回的subscription ID是会话级标识断线重连时用eth_unsubscribe清理再重订比维护一堆时间戳和区块高度的轮询状态清爽太多。所以方案定调必须用WebSocket且必须封装重连逻辑——这是整个项目稳定性的基石。2.2 为什么不自己搭节点公共节点够用吗有人会问“自己跑个Geth不是最可控”理论上对但实操中95%的轻量级需求根本没必要。自建节点要占2TB硬盘归档模式、8GB内存、持续带宽光同步主网就要3天以上。而公共节点如QuickNode、Alchemy、Infura它们背后是分布式节点集群SLA保障99.9%且已预同步好所有历史数据。重点来了它们开放的WebSocket端点和你本地Geth的--ws端口协议完全一致。我拿同一段订阅代码分别连wss://eth-mainnet.alchemyapi.io/v2/xxx和ws://localhost:8546收到的JSON-RPC格式、字段名、错误码全部相同。这意味着你的前端代码一次编写可无缝切换本地调试和生产部署。唯一要注意的是认证方式Alchemy/QuickNode要求在WebSocket URL里带API Key如wss://eth-mainnet.alchemyapi.io/v2/YOUR_KEY而本地Geth默认无认证。这个差异在代码里用一个配置项就能解决不影响核心逻辑。所以结论很明确开发阶段用本地节点调试上线用公共节点成本、速度、稳定性三赢。我给团队定的规矩是——除非你要做高频链上风控或MEV监听否则别碰自建节点省下的运维时间够你多写十个DApp。2.3 为什么聚焦“Public Messages”哪些消息能被浏览器直接读到标题里强调“Public Messages”这绝不是随便写的词。以太坊链上数据分三层区块头公开→ 交易正文公开→ 合约内部状态需执行才能知。浏览器能直接读的仅限前两层。具体来说你能实时捕获的“消息”有三类第一新区块广播newHeads每个新区块生成时节点推送完整区块头含number、hash、parentHash、timestamp等。这是最基础的“链在前进”信号延迟通常2秒。第二新交易广播newPendingTransactions交易刚进入mempool就被推送含hash、from、to、value、gasPrice等。注意这里to为空表示合约创建交易value为0不代表没价值可能是代币转账。第三合约事件日志logs这才是最有价值的“消息”。当合约执行emit Event(...)时日志写入区块可通过logs订阅精准过滤。比如监听Uniswap的Swap事件只需指定address合约地址和topics事件签名哈希节点只推符合条件的日志流量直降90%。而你绝对读不到的私钥签名、账户余额需eth_getBalance主动查、未公开的合约存储变量如mapping(address uint) private balances。所以项目定位非常清晰不做“全能链浏览器”只做“高保真链上广播接收器”专精于实时性、低开销、易集成。3. 核心细节解析与实操要点3.1 WebSocket连接建立与认证的关键参数浏览器里建立WebSocket连接看着就一行代码但藏着三个致命细节。先看标准写法const ws new WebSocket(wss://eth-mainnet.alchemyapi.io/v2/YOUR_API_KEY);第一个坑URL协议必须是wss://WebSocket Secure。现代浏览器强制要求HTTPS页面只能连WSSHTTP页面连WS会被拒绝。如果你在本地file://协议下测试会直接报SecurityError。解决方案只有两个要么用http-server起个本地HTTP服务npx http-server要么把HTML丢到GitHub Pages或Vercel上。我建议后者因为真实场景就是部署在HTTPS域名下。第二个坑连接成功不等于可用必须等readyState 1且收到open事件。新手常犯的错是ws.send()写在new WebSocket()后面没加事件监听。正确姿势是ws.onopen () { console.log(WebSocket connected); // 此时才能发订阅请求 ws.send(JSON.stringify({ jsonrpc: 2.0, method: eth_subscribe, params: [newHeads], id: 1 })); };第三个坑错误处理不能只靠onerror。onerror只捕获网络层错误如DNS失败而JSON-RPC协议错误如API Key无效、订阅方法不支持会通过onmessage返回错误响应。必须解析每条消息ws.onmessage (event) { const data JSON.parse(event.data); if (data.error) { console.error(RPC Error:, data.error.message); // 这里要触发重连逻辑 } else if (data.method eth_subscription) { // 成功订阅data.params.subscription 是ID } };我在线上环境加了双保险onclose事件触发时如果ws.readyState ! 0非关闭中就启动指数退避重连1s, 2s, 4s...最大30s同时onmessage里检测到error.code -32602参数错误就立刻停止重连——说明是代码写错了不是网络问题。3.2 订阅newPendingTransactions的实战陷阱监听待处理交易看似简单但实际落地时有两个反直觉现象。第一你收到的交易哈希hash是十六进制字符串但长度固定66位0x开头64字符。很多新手用parseInt(hash)想转数字结果溢出变NaN。正确做法是保持字符串或用BigInt(hash)ES2020。第二也是最关键的newPendingTransactions推送的只是交易哈希不是完整交易对象你想看from、to、value必须立刻用eth_getTransactionByHash查。但这里有个时间窗口问题交易刚进mempool时节点可能还没来得及索引eth_getTransactionByHash返回null。我实测过95%的交易在哈希推送后100ms内可查到但总有5%要等300-500ms。所以代码必须带重试const getTxWithRetry async (hash, maxRetries 3) { for (let i 0; i maxRetries; i) { const tx await fetch(https://eth-mainnet.g.alchemy.com/v2/YOUR_KEY, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ jsonrpc: 2.0, method: eth_getTransactionByHash, params: [hash], id: 1 }) }).then(r r.json()); if (tx.result) return tx.result; await new Promise(r setTimeout(r, 100 * (i 1))); // 指数退避 } throw new Error(Failed to get tx ${hash}); };这个重试逻辑救了我三次——有一次在测试Uniswap V3流动性添加时因交易Gas费偏低在mempool滞留了2秒没重试的话就彻底丢失了。3.3 过滤合约事件日志logs的精准匹配技巧监听特定合约事件才是本项目的价值高地。比如你想抓OpenSea的NFT上架事件目标合约是0x7Be8076f4EA4A4AD0809612aD594685966873502事件是Offered(uint256 tokenId, address indexed seller, uint256 price)。这里topics的构造是核心难点。第一步计算事件签名哈希web3.utils.sha3(Offered(uint256,address,uint256))→0x2b4c76d0...。但注意topics[0]必须是这个哈希而topics[1]、topics[2]对应indexed参数。seller是indexed所以topics[1]填卖家地址的keccak256哈希不是地址本身。我写了个工具函数const getTopicForAddress (addr) { // 地址转小写补零到64位再哈希 const padded addr.toLowerCase().padStart(64, 0); return web3.utils.sha3(padded).toLowerCase(); };然后订阅ws.send(JSON.stringify({ jsonrpc: 2.0, method: eth_subscribe, params: [logs, { address: 0x7Be8076f4EA4A4AD0809612aD594685966873502, topics: [ 0x2b4c76d0..., // Offered事件签名 null, // 不过滤seller填null表示任意 null // 不过滤price ] }], id: 2 }));重点来了topics数组里null的位置很讲究。如果你想只监听特定卖家的上架就把topics[1]换成getTopicForAddress(0x...)如果想监听价格0.1 ETH的price是uint256需转为32字节大端序十六进制如0.1 ETH 100000000000000000 0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000......。这个转换我用web3.utils.toHex(web3.utils.toWei(0.1, ether))生成再补零到64位。实操中宁可多订阅几个topics组合也别在前端做复杂过滤——节点推送的流量远小于你JS遍历的CPU开销。4. 实操过程与核心环节实现4.1 从零搭建一个“实时区块浏览器”前端我们来写一个真正能跑的HTML页面功能实时显示最新区块号、时间、交易数并点击区块哈希可展开查看完整信息。整个过程不依赖任何构建工具纯原生JS。先建index.html!DOCTYPE html html head titleEthereum Live Monitor/title style body { font-family: Segoe UI, sans-serif; margin: 2rem; } .block-card { border: 1px solid #eee; border-radius: 8px; padding: 1rem; margin: 1rem 0; } .tx-list { margin-top: 0.5rem; font-size: 0.9em; } /style /head body h1Ethereum Live Monitor/h1 div idstatusConnecting.../div div idblocks/div script // WebSocket连接管理 let ws null; const API_KEY YOUR_ALCHEMY_KEY; // 替换为你自己的 const WS_URL wss://eth-mainnet.g.alchemy.com/v2/${API_KEY}; const connect () { ws new WebSocket(WS_URL); ws.onopen () { document.getElementById(status).textContent Connected ✅; // 订阅新区块 ws.send(JSON.stringify({ jsonrpc: 2.0, method: eth_subscribe, params: [newHeads], id: 1 })); }; ws.onerror (err) { document.getElementById(status).textContent Connection Error ❌; }; ws.onmessage (event) { const data JSON.parse(event.data); if (data.error) { console.error(Subscription error:, data.error); return; } if (data.method eth_subscription data.params?.result) { // 成功订阅保存subscription ID const subId data.params.subscription; console.log(Subscribed with ID:, subId); } if (data.params?.result?.number) { // 收到新区块渲染到页面 renderBlock(data.params.result); } }; ws.onclose () { document.getElementById(status).textContent Disconnected, retrying...; setTimeout(connect, 5000); // 5秒后重连 }; }; const renderBlock (block) { const blocksDiv document.getElementById(blocks); const blockEl document.createElement(div); blockEl.className block-card; blockEl.innerHTML strongBlock #${parseInt(block.number, 16)}/strong span stylecolor:#666; margin-left:1rem;${new Date(parseInt(block.timestamp, 16) * 1000).toLocaleString()}/span divHash: code${block.hash}/code/div divTransactions: ${block.transactions.length}/div div classtx-list Transactions: ${block.transactions.map(tx code${tx}/code).join(, )} /div ; blocksDiv.insertBefore(blockEl, blocksDiv.firstChild); // 插入最前 // 只保留最近10个区块 if (blocksDiv.children.length 10) { blocksDiv.removeChild(blocksDiv.lastChild); } }; // 页面加载完成启动连接 window.addEventListener(load, connect); /script /body /html关键点解析parseInt(block.number, 16)以太坊所有数字都是十六进制字符串必须转十进制才可读。new Date(parseInt(block.timestamp, 16) * 1000)时间戳是秒级Unix时间需乘1000转毫秒。insertBefore(..., firstChild)让最新区块永远在顶部符合“实时监控”直觉。自动清理旧区块避免DOM无限增长拖慢页面这是生产环境必备技巧。部署时把YOUR_ALCHEMY_KEY换成你在Alchemy控制台创建的Key免费层够用丢到Vercel或Netlify打开就能看到主网区块实时刷屏。我测试时平均延迟1.2秒——比区块浏览器还快因为没经过服务端渲染。4.2 扩展功能监听Uniswap V2的Swap事件并计算交易额现在升级需求不只看区块还要抓具体DeFi交易。以Uniswap V2的Swap事件为例合约地址0x5C69bEe701ef814a2B6a3EDD4B1652CB9cc5aA6f事件签名Swap(address indexed sender, uint256 amount0In, uint256 amount1In, uint256 amount0Out, uint256 amount1Out, address indexed to)。我们要实时计算每笔Swap的USD金额。难点在于amount0In/Out是代币原始精度如USDC是6位小数需除以10^decimals且要查代币价格。这里用CoinGecko免费API无需Key// 在onmessage里添加事件处理分支 if (data.params?.result?.address 0x5C69bEe701ef814a2B6a3EDD4B1652CB9cc5aA6f) { const topics data.params.result.topics; if (topics[0] 0xd78ad95fa46c994b6551d0da85fc275fe613ce37657fb8d5e3d130840159d822) { // 是Swap事件解析log数据 const dataStr data.params.result.data; // data字段是hex string按ABI解码每个uint256占32字节 const amount0In BigInt(0x dataStr.slice(2, 66)); const amount1In BigInt(0x dataStr.slice(66, 130)); const amount0Out BigInt(0x dataStr.slice(130, 194)); const amount1Out BigInt(0x dataStr.slice(194, 258)); // 假设这是WETH/USDC池amount0是WETH18位小数amount1是USDC6位 const wethAmount Number(amount0In) / 1e18; const usdcAmount Number(amount1Out) / 1e6; // 查WETH价格简化版实际应缓存 fetch(https://api.coingecko.com/api/v3/simple/price?idsethereumvs_currenciesusd) .then(r r.json()) .then(priceData { const ethPrice priceData.ethereum.usd; const tradeUsd wethAmount * ethPrice; console.log(Swap: ${wethAmount.toFixed(4)} ETH → ${usdcAmount.toFixed(0)} USDC | ~$${tradeUsd.toFixed(0)}); }); } }注意data字段是连续的十六进制字符串必须按ABI编码规则切片。Uniswap V2的Swap事件data部分严格按顺序排列4个uint256所以切片位置是固定的232*266, 663298...等等。这个硬编码在V2是安全的但V3就不同了——V3的Swap事件data包含更多字段必须用eth-abi库解析。所以我的经验是对已知ABI的合约手写切片最快对动态ABI必须引入ethersproject/abi。另外CoinGecko API有调用频率限制线上环境一定要加本地缓存如localStorage存1分钟内价格。4.3 生产级重连与状态同步机制上面的代码在实验室很稳但放到真实网络里会遇到三类断连短暂网络抖动5秒WebSocket自动重连即可节点维护重启30秒重连后需重新订阅且可能丢失期间消息客户端休眠笔记本合盖浏览器可能终止WebSocket唤醒后需全量恢复。解决方案是“双状态同步”内存状态用Map存当前所有活跃订阅ID如newHeads、logs等持久化状态用localStorage存最后收到的区块号lastBlockNumber。重连成功后先发eth_subscribe恢复所有订阅再用eth_getBlockByNumber(lastBlockNumber1, false)开始轮询直到追上最新区块再切回WebSocket。代码框架const state { subscriptions: new Map(), // key: subId, value: type lastBlockNumber: parseInt(localStorage.getItem(lastBlock) || 0, 10) }; ws.onopen () { // 恢复所有订阅 state.subscriptions.forEach((type, subId) { ws.send(JSON.stringify({ jsonrpc: 2.0, method: eth_subscribe, params: [type], id: Math.random() })); }); // 启动追赶模式 catchUpFrom(state.lastBlockNumber 1); }; const catchUpFrom async (startNum) { let blockNum startNum; while (true) { const block await fetchBlock(blockNum); if (!block) break; // 到头了 renderBlock(block); state.lastBlockNumber parseInt(block.number, 16); localStorage.setItem(lastBlock, state.lastBlockNumber.toString()); blockNum; } };这个机制让我在一次Alchemey节点升级中客户端断连12分钟恢复后自动补全了所有丢失区块用户无感知。记住永远不要相信“连接不断”的神话设计时就要假设它随时会断。5. 常见问题与排查技巧实录5.1 “Connection closed before receiving a handshake response” 错误详解这是新手遇到最多、最懵的错误。表面看是WebSocket连接被拒但根因有三种第一API Key无效或过期。Alchemy控制台里Key状态是Active但可能被误删或权限不足。验证方法用curl直接测curl -X POST \ -H Content-Type: application/json \ --data {jsonrpc:2.0,method:eth_blockNumber,params:[],id:1} \ https://eth-mainnet.g.alchemy.com/v2/YOUR_KEY如果返回{error:{code:-32602,message:Invalid API key}}立刻去控制台检查Key。第二URL协议错误。开发时用http://localhost:3000起服务但WebSocket URL写了ws://而非wss://。Chrome控制台会报Mixed Content警告然后静默关闭连接。解决方案要么用https://本地服务npx local-ssl-proxy要么改用wss://公共节点。第三浏览器扩展干扰。某些广告拦截插件如uBlock Origin会主动阻断WebSocket连接。临时禁用所有扩展用隐身窗口测试。我曾为这问题调试2小时最后发现是Privacy Badger在作祟。提示遇到此错误第一步打开Chrome开发者工具→Network标签页→Filter选WS→点击连接→看Headers里的Status Code。如果是403基本是Key问题如果是0大概率是协议或扩展问题。5.2 “Error: Invalid params: must provide an array for topics” 的根源这个错误出现在eth_subscribe logs时看似是topics格式错实则常因两个低级失误失误一topics数组里混入了undefined。比如你写topics: [eventSig, sellerTopic, undefined]JavaScript序列化后变成[eventSig, sellerTopic, null]但节点期望的是[eventSig, sellerTopic]长度3的数组第三个元素是null不是省略。正确写法是动态构造数组const topics [eventSig]; if (sellerAddress) topics.push(getTopicForAddress(sellerAddress)); // 不要push(undefined)失误二address参数传了数组。文档说address可以是单地址或地址数组但很多公共节点包括Alchemy只支持单地址字符串。如果你传[0x..., 0x...]会直接报错。验证方法用eth_getLogs先试curl命令里address填单个地址能通填数组就400。注意topics数组长度决定过滤强度。[sig]表示只匹配该事件[sig, null, topic2]表示匹配事件且第三个indexed参数等于topic2[sig, topic1, null]表示匹配事件且第一个indexed参数等于topic1。null代表“任意值”不是“忽略该参数”。5.3 如何判断消息是否真的“实时”延迟测量实战所谓实时必须量化。我在页面加了个“延迟仪表盘”订阅newHeads时记录Date.now()为t0收到区块后取block.timestamp转为毫秒t1当前系统时间t2延迟 t2 - t1链上时间到你看到的时间。实测数据主网节点提供商平均延迟P95延迟备注Alchemy1.3s3.2s全球CDN亚洲用户稍慢QuickNode0.9s2.1s美西节点最优自建Geth0.4s0.8s仅限同机房运维成本高有趣发现延迟和区块大小正相关。大区块150交易平均延迟比小区块高0.6s因为节点需要更长时间打包和广播。所以如果你的应用对延迟极度敏感如MEV机器人必须监控block.transactions.length对大区块做特殊处理。实操心得别信厂商宣传的“亚秒级延迟”。自己搭个计时器连续测100个区块画个分布图这才是真实水位线。5.4 内存泄漏预警如何避免监听器堆积导致页面卡死WebSocket长连接本身不占内存但onmessage里如果频繁document.createElement又不销毁DOM会爆炸。更隐蔽的是事件监听器泄漏比如每次重连都ws.onmessage handler旧的handler不会自动解绑。现代浏览器虽有GC但大量闭包引用仍会导致内存缓慢增长。我的防御三板斧第一用addEventListener替代onmessage赋值ws.addEventListener(message, handleMessage); // 重连时先移除 ws.removeEventListener(message, handleMessage);第二DOM节点加唯一ID更新时复用而非重建const blockEl document.getElementById(block-${blockNum}); if (blockEl) { blockEl.innerHTML updatedHtml; // 复用 } else { // 创建新节点 }第三用WeakMap存DOM关联数据避免强引用const blockData new WeakMap(); blockData.set(blockEl, { timestamp: Date.now(), txCount: 10 }); // GC时自动清理上周我帮一个客户排查他们页面运行8小时后内存占用从100MB涨到1.2GB根源就是setInterval里不断appendChild新元素。加了上述三招内存稳定在80MB左右。6. 进阶应用与安全边界提醒6.1 能否监听私有交易或未公开合约答案与原理明确回答不能且永远不可能。这不是技术限制而是以太坊共识层的设计哲学。所有“Public Messages”都源于区块链的公开账本特性区块头、交易原文、事件日志全部明文存储在每个全节点硬盘上任何联网设备都能下载验证。而“私有”数据有两类链下隐私如Tornado Cash的零知识证明验证过程在链上但输入数据存款地址、取款地址通过ZK-SNARK压缩成短证明原始数据永不上传。浏览器能读到的只有证明本身无法反推。链上加密如使用AES加密交易data字段虽然交易上链但解密密钥只在双方手中。节点推送的仍是加密后的data你拿到也看不懂。所以本项目的能力边界非常清晰它是一个高保真“公开广播接收器”不是“全能链上解密器”。想获取私有信息必须走链下通道如The Graph的子图索引、或中心化API聚合商而这已超出“Simple Web Programming”范畴。我建议用户建立正确认知接受公开数据的透明性正是Web3信任的基石试图绕过它反而违背初心。6.2 性能压测单页面最多能同时监听多少个事件这没有标准答案取决于三个变量浏览器内存每个WebSocket连接约占用2MB内存含缓冲区节点配额Alchemy免费层限制100个并发订阅CPU处理能力每条消息的JSON解析、DOM更新、价格查询都是同步阻塞操作。我做了极限测试在MacBook Pro M1上同时开启50个logs订阅不同NFT合约页面内存升至1.8GBCPU峰值85%但滚动依然流畅。当开到100个时Chrome开始警告“Page is using a lot of memory”DOM更新明显卡顿。所以我的经验阈值是生产环境单页面≤30个订阅开发环境≤50个。超过此数必须做分组懒加载比如只监听用户当前关注的3个合约其他折叠。关键技巧用IntersectionObserver监听区块卡片是否在视口不在时暂停其内部的价格查询定时器进入视口再激活。这能让100个订阅的页面内存降到600MB。6.3 最后一个忠告永远校验subscription ID与unsubcribe很多人以为订阅完就万事大吉其实eth_unsubscribe才是专业性的分水岭。不主动取消节点会一直推送浪费带宽和你的CPU。更严重的是某些节点如旧版Geth对未清理的订阅有连接数上限导致新订阅失败。正确流程页面卸载前beforeunload调用ws.send(eth_unsubscribe)每个订阅成功后把subscription ID存入state.subscriptions重连时先遍历state.subscriptions发取消请求再发新订阅。const unsubscribeAll () { state.subscriptions.forEach((_, subId) { ws.send(JSON.stringify({ jsonrpc: 2.0, method: eth_unsubscribe, params: [subId], id: Math.random() })); }); state.subscriptions.clear(); }; window.addEventListener(beforeunload, unsubscribeAll);我见过最惨的案例一个团队的监控页面忘了写unsubscribe跑了三个月节点累积了2万多个僵尸订阅最终触发节点熔断保护整个团队API被限流。所以记住订阅是开始取消是结束两者同等重要。我在实际项目中发现最稳定的方案永远是“简单粗暴”用最少的依赖、最直白的API、最保守的重试策略。与其纠结WebSocket库选哪个不如把onmessage里的错误解析写扎实与其追求监听100个合约不如把一个Swap事件的金额计算做到毫秒级精准。区块链的世界变化太快但底层的JSON-RPC协议十年未变——抓住不变的才能应对万变。这个项目教会我的不是怎么炫技而是如何用浏览器原生能力谦卑地倾听一条公链的心跳。
浏览器直连以太坊WebSocket实时监听链上公开消息
发布时间：2026/6/9 11:47:29
1. 项目概述用浏览器就能“听”以太坊链上正在发生什么你有没有试过打开一个网页不装插件、不连钱包、不写一行后端代码就在控制台里直接看到刚刚被矿工打包进区块的交易不是查某个地址的历史记录而是像调频收音机一样实时捕获全网广播出来的每一条公开消息——转账、合约调用、NFT铸造、甚至DAO投票提案。这个项目标题说的正是这件事Read Public Messages from the Ethereum Network with Simple Web Programming。核心关键词就三个Ethereum以太坊、Public Messages公开消息、Simple Web Programming简易网页编程。它解决的不是“怎么发交易”而是“怎么当一个安静但高效的链上监听者”。适合谁前端工程师想快速验证合约事件、产品经理需要实时看测试网活动、学生做区块链课程作业、甚至社区运营者想自动抓取新发布的空投公告——只要你会写fetch()和console.log()就能上手。它不依赖Node.js服务端、不碰私钥、不走RPC代理中转全程在浏览器沙盒内完成用的是以太坊最基础、最开放的通信层WebSocket订阅机制。很多人以为读链上数据必须靠Alchemy或Infura这类中心化服务商其实以太坊节点原生就支持eth_subscribe而主流公共节点如QuickNode、Alchemy的免费层、甚至自建Geth节点都已开放该接口。关键在于你得知道怎么用标准Web API去“接住”它传来的JSON-RPC流式数据而不是只用eth_getLogs这种轮询式快照查询。我第一次在Chrome控制台里看到{jsonrpc:2.0,method:eth_subscription,params:{subscription:0xabc...,result:{...}}}实时刷屏时那种“原来链真的在说话”的感觉比写完一个DeFi前端还让人兴奋。2. 整体设计思路与方案选型逻辑2.1 为什么放弃HTTP轮询坚定选择WebSocket长连接初学者最容易踩的坑就是用fetch()反复调eth_getLogs或eth_getBlockByNumber来“模拟监听”。我试过——写个setInterval(() fetch(...), 2000)结果发现三秒一刷漏掉的交易比抓到的还多。原因很实在以太坊出块时间平均12秒但交易池mempool里的交易是毫秒级流动的尤其在NFT抢购或空投申领高峰一笔交易从广播到被打包可能只隔300ms。HTTP轮询本质是“盲猜时间点”你永远不知道上次请求和下次请求之间发生了什么。而WebSocket是真正的双向通道客户端发个订阅指令节点就持续把匹配的消息推过来零延迟、无遗漏。更关键的是带宽和请求配额消耗天差地别。我用同一套测试脚本对比轮询每秒1次1小时耗掉3600次API调用WebSocket长连接1小时只算1次初始连接心跳保活剩余全是免费推送。这对免费额度有限的公共节点比如Alchemy每月10M次请求简直是救命稻草。技术上eth_subscribe返回的subscription ID是会话级标识断线重连时用eth_unsubscribe清理再重订比维护一堆时间戳和区块高度的轮询状态清爽太多。所以方案定调必须用WebSocket且必须封装重连逻辑——这是整个项目稳定性的基石。2.2 为什么不自己搭节点公共节点够用吗有人会问“自己跑个Geth不是最可控”理论上对但实操中95%的轻量级需求根本没必要。自建节点要占2TB硬盘归档模式、8GB内存、持续带宽光同步主网就要3天以上。而公共节点如QuickNode、Alchemy、Infura它们背后是分布式节点集群SLA保障99.9%且已预同步好所有历史数据。重点来了它们开放的WebSocket端点和你本地Geth的--ws端口协议完全一致。我拿同一段订阅代码分别连wss://eth-mainnet.alchemyapi.io/v2/xxx和ws://localhost:8546收到的JSON-RPC格式、字段名、错误码全部相同。这意味着你的前端代码一次编写可无缝切换本地调试和生产部署。唯一要注意的是认证方式Alchemy/QuickNode要求在WebSocket URL里带API Key如wss://eth-mainnet.alchemyapi.io/v2/YOUR_KEY而本地Geth默认无认证。这个差异在代码里用一个配置项就能解决不影响核心逻辑。所以结论很明确开发阶段用本地节点调试上线用公共节点成本、速度、稳定性三赢。我给团队定的规矩是——除非你要做高频链上风控或MEV监听否则别碰自建节点省下的运维时间够你多写十个DApp。2.3 为什么聚焦“Public Messages”哪些消息能被浏览器直接读到标题里强调“Public Messages”这绝不是随便写的词。以太坊链上数据分三层区块头公开→ 交易正文公开→ 合约内部状态需执行才能知。浏览器能直接读的仅限前两层。具体来说你能实时捕获的“消息”有三类第一新区块广播newHeads每个新区块生成时节点推送完整区块头含number、hash、parentHash、timestamp等。这是最基础的“链在前进”信号延迟通常2秒。第二新交易广播newPendingTransactions交易刚进入mempool就被推送含hash、from、to、value、gasPrice等。注意这里to为空表示合约创建交易value为0不代表没价值可能是代币转账。第三合约事件日志logs这才是最有价值的“消息”。当合约执行emit Event(...)时日志写入区块可通过logs订阅精准过滤。比如监听Uniswap的Swap事件只需指定address合约地址和topics事件签名哈希节点只推符合条件的日志流量直降90%。而你绝对读不到的私钥签名、账户余额需eth_getBalance主动查、未公开的合约存储变量如mapping(address uint) private balances。所以项目定位非常清晰不做“全能链浏览器”只做“高保真链上广播接收器”专精于实时性、低开销、易集成。3. 核心细节解析与实操要点3.1 WebSocket连接建立与认证的关键参数浏览器里建立WebSocket连接看着就一行代码但藏着三个致命细节。先看标准写法const ws new WebSocket(wss://eth-mainnet.alchemyapi.io/v2/YOUR_API_KEY);第一个坑URL协议必须是wss://WebSocket Secure。现代浏览器强制要求HTTPS页面只能连WSSHTTP页面连WS会被拒绝。如果你在本地file://协议下测试会直接报SecurityError。解决方案只有两个要么用http-server起个本地HTTP服务npx http-server要么把HTML丢到GitHub Pages或Vercel上。我建议后者因为真实场景就是部署在HTTPS域名下。第二个坑连接成功不等于可用必须等readyState 1且收到open事件。新手常犯的错是ws.send()写在new WebSocket()后面没加事件监听。正确姿势是ws.onopen () { console.log(WebSocket connected); // 此时才能发订阅请求 ws.send(JSON.stringify({ jsonrpc: 2.0, method: eth_subscribe, params: [newHeads], id: 1 })); };第三个坑错误处理不能只靠onerror。onerror只捕获网络层错误如DNS失败而JSON-RPC协议错误如API Key无效、订阅方法不支持会通过onmessage返回错误响应。必须解析每条消息ws.onmessage (event) { const data JSON.parse(event.data); if (data.error) { console.error(RPC Error:, data.error.message); // 这里要触发重连逻辑 } else if (data.method eth_subscription) { // 成功订阅data.params.subscription 是ID } };我在线上环境加了双保险onclose事件触发时如果ws.readyState ! 0非关闭中就启动指数退避重连1s, 2s, 4s...最大30s同时onmessage里检测到error.code -32602参数错误就立刻停止重连——说明是代码写错了不是网络问题。3.2 订阅newPendingTransactions的实战陷阱监听待处理交易看似简单但实际落地时有两个反直觉现象。第一你收到的交易哈希hash是十六进制字符串但长度固定66位0x开头64字符。很多新手用parseInt(hash)想转数字结果溢出变NaN。正确做法是保持字符串或用BigInt(hash)ES2020。第二也是最关键的newPendingTransactions推送的只是交易哈希不是完整交易对象你想看from、to、value必须立刻用eth_getTransactionByHash查。但这里有个时间窗口问题交易刚进mempool时节点可能还没来得及索引eth_getTransactionByHash返回null。我实测过95%的交易在哈希推送后100ms内可查到但总有5%要等300-500ms。所以代码必须带重试const getTxWithRetry async (hash, maxRetries 3) { for (let i 0; i maxRetries; i) { const tx await fetch(https://eth-mainnet.g.alchemy.com/v2/YOUR_KEY, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ jsonrpc: 2.0, method: eth_getTransactionByHash, params: [hash], id: 1 }) }).then(r r.json()); if (tx.result) return tx.result; await new Promise(r setTimeout(r, 100 * (i 1))); // 指数退避 } throw new Error(Failed to get tx ${hash}); };这个重试逻辑救了我三次——有一次在测试Uniswap V3流动性添加时因交易Gas费偏低在mempool滞留了2秒没重试的话就彻底丢失了。3.3 过滤合约事件日志logs的精准匹配技巧监听特定合约事件才是本项目的价值高地。比如你想抓OpenSea的NFT上架事件目标合约是0x7Be8076f4EA4A4AD0809612aD594685966873502事件是Offered(uint256 tokenId, address indexed seller, uint256 price)。这里topics的构造是核心难点。第一步计算事件签名哈希web3.utils.sha3(Offered(uint256,address,uint256))→0x2b4c76d0...。但注意topics[0]必须是这个哈希而topics[1]、topics[2]对应indexed参数。seller是indexed所以topics[1]填卖家地址的keccak256哈希不是地址本身。我写了个工具函数const getTopicForAddress (addr) { // 地址转小写补零到64位再哈希 const padded addr.toLowerCase().padStart(64, 0); return web3.utils.sha3(padded).toLowerCase(); };然后订阅ws.send(JSON.stringify({ jsonrpc: 2.0, method: eth_subscribe, params: [logs, { address: 0x7Be8076f4EA4A4AD0809612aD594685966873502, topics: [ 0x2b4c76d0..., // Offered事件签名 null, // 不过滤seller填null表示任意 null // 不过滤price ] }], id: 2 }));重点来了topics数组里null的位置很讲究。如果你想只监听特定卖家的上架就把topics[1]换成getTopicForAddress(0x...)如果想监听价格0.1 ETH的price是uint256需转为32字节大端序十六进制如0.1 ETH 100000000000000000 0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000......。这个转换我用web3.utils.toHex(web3.utils.toWei(0.1, ether))生成再补零到64位。实操中宁可多订阅几个topics组合也别在前端做复杂过滤——节点推送的流量远小于你JS遍历的CPU开销。4. 实操过程与核心环节实现4.1 从零搭建一个“实时区块浏览器”前端我们来写一个真正能跑的HTML页面功能实时显示最新区块号、时间、交易数并点击区块哈希可展开查看完整信息。整个过程不依赖任何构建工具纯原生JS。先建index.html!DOCTYPE html html head titleEthereum Live Monitor/title style body { font-family: Segoe UI, sans-serif; margin: 2rem; } .block-card { border: 1px solid #eee; border-radius: 8px; padding: 1rem; margin: 1rem 0; } .tx-list { margin-top: 0.5rem; font-size: 0.9em; } /style /head body h1Ethereum Live Monitor/h1 div idstatusConnecting.../div div idblocks/div script // WebSocket连接管理 let ws null; const API_KEY YOUR_ALCHEMY_KEY; // 替换为你自己的 const WS_URL wss://eth-mainnet.g.alchemy.com/v2/${API_KEY}; const connect () { ws new WebSocket(WS_URL); ws.onopen () { document.getElementById(status).textContent Connected ✅; // 订阅新区块 ws.send(JSON.stringify({ jsonrpc: 2.0, method: eth_subscribe, params: [newHeads], id: 1 })); }; ws.onerror (err) { document.getElementById(status).textContent Connection Error ❌; }; ws.onmessage (event) { const data JSON.parse(event.data); if (data.error) { console.error(Subscription error:, data.error); return; } if (data.method eth_subscription data.params?.result) { // 成功订阅保存subscription ID const subId data.params.subscription; console.log(Subscribed with ID:, subId); } if (data.params?.result?.number) { // 收到新区块渲染到页面 renderBlock(data.params.result); } }; ws.onclose () { document.getElementById(status).textContent Disconnected, retrying...; setTimeout(connect, 5000); // 5秒后重连 }; }; const renderBlock (block) { const blocksDiv document.getElementById(blocks); const blockEl document.createElement(div); blockEl.className block-card; blockEl.innerHTML strongBlock #${parseInt(block.number, 16)}/strong span stylecolor:#666; margin-left:1rem;${new Date(parseInt(block.timestamp, 16) * 1000).toLocaleString()}/span divHash: code${block.hash}/code/div divTransactions: ${block.transactions.length}/div div classtx-list Transactions: ${block.transactions.map(tx code${tx}/code).join(, )} /div ; blocksDiv.insertBefore(blockEl, blocksDiv.firstChild); // 插入最前 // 只保留最近10个区块 if (blocksDiv.children.length 10) { blocksDiv.removeChild(blocksDiv.lastChild); } }; // 页面加载完成启动连接 window.addEventListener(load, connect); /script /body /html关键点解析parseInt(block.number, 16)以太坊所有数字都是十六进制字符串必须转十进制才可读。new Date(parseInt(block.timestamp, 16) * 1000)时间戳是秒级Unix时间需乘1000转毫秒。insertBefore(..., firstChild)让最新区块永远在顶部符合“实时监控”直觉。自动清理旧区块避免DOM无限增长拖慢页面这是生产环境必备技巧。部署时把YOUR_ALCHEMY_KEY换成你在Alchemy控制台创建的Key免费层够用丢到Vercel或Netlify打开就能看到主网区块实时刷屏。我测试时平均延迟1.2秒——比区块浏览器还快因为没经过服务端渲染。4.2 扩展功能监听Uniswap V2的Swap事件并计算交易额现在升级需求不只看区块还要抓具体DeFi交易。以Uniswap V2的Swap事件为例合约地址0x5C69bEe701ef814a2B6a3EDD4B1652CB9cc5aA6f事件签名Swap(address indexed sender, uint256 amount0In, uint256 amount1In, uint256 amount0Out, uint256 amount1Out, address indexed to)。我们要实时计算每笔Swap的USD金额。难点在于amount0In/Out是代币原始精度如USDC是6位小数需除以10^decimals且要查代币价格。这里用CoinGecko免费API无需Key// 在onmessage里添加事件处理分支 if (data.params?.result?.address 0x5C69bEe701ef814a2B6a3EDD4B1652CB9cc5aA6f) { const topics data.params.result.topics; if (topics[0] 0xd78ad95fa46c994b6551d0da85fc275fe613ce37657fb8d5e3d130840159d822) { // 是Swap事件解析log数据 const dataStr data.params.result.data; // data字段是hex string按ABI解码每个uint256占32字节 const amount0In BigInt(0x dataStr.slice(2, 66)); const amount1In BigInt(0x dataStr.slice(66, 130)); const amount0Out BigInt(0x dataStr.slice(130, 194)); const amount1Out BigInt(0x dataStr.slice(194, 258)); // 假设这是WETH/USDC池amount0是WETH18位小数amount1是USDC6位 const wethAmount Number(amount0In) / 1e18; const usdcAmount Number(amount1Out) / 1e6; // 查WETH价格简化版实际应缓存 fetch(https://api.coingecko.com/api/v3/simple/price?idsethereumvs_currenciesusd) .then(r r.json()) .then(priceData { const ethPrice priceData.ethereum.usd; const tradeUsd wethAmount * ethPrice; console.log(Swap: ${wethAmount.toFixed(4)} ETH → ${usdcAmount.toFixed(0)} USDC | ~$${tradeUsd.toFixed(0)}); }); } }注意data字段是连续的十六进制字符串必须按ABI编码规则切片。Uniswap V2的Swap事件data部分严格按顺序排列4个uint256所以切片位置是固定的232*266, 663298...等等。这个硬编码在V2是安全的但V3就不同了——V3的Swap事件data包含更多字段必须用eth-abi库解析。所以我的经验是对已知ABI的合约手写切片最快对动态ABI必须引入ethersproject/abi。另外CoinGecko API有调用频率限制线上环境一定要加本地缓存如localStorage存1分钟内价格。4.3 生产级重连与状态同步机制上面的代码在实验室很稳但放到真实网络里会遇到三类断连短暂网络抖动5秒WebSocket自动重连即可节点维护重启30秒重连后需重新订阅且可能丢失期间消息客户端休眠笔记本合盖浏览器可能终止WebSocket唤醒后需全量恢复。解决方案是“双状态同步”内存状态用Map存当前所有活跃订阅ID如newHeads、logs等持久化状态用localStorage存最后收到的区块号lastBlockNumber。重连成功后先发eth_subscribe恢复所有订阅再用eth_getBlockByNumber(lastBlockNumber1, false)开始轮询直到追上最新区块再切回WebSocket。代码框架const state { subscriptions: new Map(), // key: subId, value: type lastBlockNumber: parseInt(localStorage.getItem(lastBlock) || 0, 10) }; ws.onopen () { // 恢复所有订阅 state.subscriptions.forEach((type, subId) { ws.send(JSON.stringify({ jsonrpc: 2.0, method: eth_subscribe, params: [type], id: Math.random() })); }); // 启动追赶模式 catchUpFrom(state.lastBlockNumber 1); }; const catchUpFrom async (startNum) { let blockNum startNum; while (true) { const block await fetchBlock(blockNum); if (!block) break; // 到头了 renderBlock(block); state.lastBlockNumber parseInt(block.number, 16); localStorage.setItem(lastBlock, state.lastBlockNumber.toString()); blockNum; } };这个机制让我在一次Alchemey节点升级中客户端断连12分钟恢复后自动补全了所有丢失区块用户无感知。记住永远不要相信“连接不断”的神话设计时就要假设它随时会断。5. 常见问题与排查技巧实录5.1 “Connection closed before receiving a handshake response” 错误详解这是新手遇到最多、最懵的错误。表面看是WebSocket连接被拒但根因有三种第一API Key无效或过期。Alchemy控制台里Key状态是Active但可能被误删或权限不足。验证方法用curl直接测curl -X POST \ -H Content-Type: application/json \ --data {jsonrpc:2.0,method:eth_blockNumber,params:[],id:1} \ https://eth-mainnet.g.alchemy.com/v2/YOUR_KEY如果返回{error:{code:-32602,message:Invalid API key}}立刻去控制台检查Key。第二URL协议错误。开发时用http://localhost:3000起服务但WebSocket URL写了ws://而非wss://。Chrome控制台会报Mixed Content警告然后静默关闭连接。解决方案要么用https://本地服务npx local-ssl-proxy要么改用wss://公共节点。第三浏览器扩展干扰。某些广告拦截插件如uBlock Origin会主动阻断WebSocket连接。临时禁用所有扩展用隐身窗口测试。我曾为这问题调试2小时最后发现是Privacy Badger在作祟。提示遇到此错误第一步打开Chrome开发者工具→Network标签页→Filter选WS→点击连接→看Headers里的Status Code。如果是403基本是Key问题如果是0大概率是协议或扩展问题。5.2 “Error: Invalid params: must provide an array for topics” 的根源这个错误出现在eth_subscribe logs时看似是topics格式错实则常因两个低级失误失误一topics数组里混入了undefined。比如你写topics: [eventSig, sellerTopic, undefined]JavaScript序列化后变成[eventSig, sellerTopic, null]但节点期望的是[eventSig, sellerTopic]长度3的数组第三个元素是null不是省略。正确写法是动态构造数组const topics [eventSig]; if (sellerAddress) topics.push(getTopicForAddress(sellerAddress)); // 不要push(undefined)失误二address参数传了数组。文档说address可以是单地址或地址数组但很多公共节点包括Alchemy只支持单地址字符串。如果你传[0x..., 0x...]会直接报错。验证方法用eth_getLogs先试curl命令里address填单个地址能通填数组就400。注意topics数组长度决定过滤强度。[sig]表示只匹配该事件[sig, null, topic2]表示匹配事件且第三个indexed参数等于topic2[sig, topic1, null]表示匹配事件且第一个indexed参数等于topic1。null代表“任意值”不是“忽略该参数”。5.3 如何判断消息是否真的“实时”延迟测量实战所谓实时必须量化。我在页面加了个“延迟仪表盘”订阅newHeads时记录Date.now()为t0收到区块后取block.timestamp转为毫秒t1当前系统时间t2延迟 t2 - t1链上时间到你看到的时间。实测数据主网节点提供商平均延迟P95延迟备注Alchemy1.3s3.2s全球CDN亚洲用户稍慢QuickNode0.9s2.1s美西节点最优自建Geth0.4s0.8s仅限同机房运维成本高有趣发现延迟和区块大小正相关。大区块150交易平均延迟比小区块高0.6s因为节点需要更长时间打包和广播。所以如果你的应用对延迟极度敏感如MEV机器人必须监控block.transactions.length对大区块做特殊处理。实操心得别信厂商宣传的“亚秒级延迟”。自己搭个计时器连续测100个区块画个分布图这才是真实水位线。5.4 内存泄漏预警如何避免监听器堆积导致页面卡死WebSocket长连接本身不占内存但onmessage里如果频繁document.createElement又不销毁DOM会爆炸。更隐蔽的是事件监听器泄漏比如每次重连都ws.onmessage handler旧的handler不会自动解绑。现代浏览器虽有GC但大量闭包引用仍会导致内存缓慢增长。我的防御三板斧第一用addEventListener替代onmessage赋值ws.addEventListener(message, handleMessage); // 重连时先移除 ws.removeEventListener(message, handleMessage);第二DOM节点加唯一ID更新时复用而非重建const blockEl document.getElementById(block-${blockNum}); if (blockEl) { blockEl.innerHTML updatedHtml; // 复用 } else { // 创建新节点 }第三用WeakMap存DOM关联数据避免强引用const blockData new WeakMap(); blockData.set(blockEl, { timestamp: Date.now(), txCount: 10 }); // GC时自动清理上周我帮一个客户排查他们页面运行8小时后内存占用从100MB涨到1.2GB根源就是setInterval里不断appendChild新元素。加了上述三招内存稳定在80MB左右。6. 进阶应用与安全边界提醒6.1 能否监听私有交易或未公开合约答案与原理明确回答不能且永远不可能。这不是技术限制而是以太坊共识层的设计哲学。所有“Public Messages”都源于区块链的公开账本特性区块头、交易原文、事件日志全部明文存储在每个全节点硬盘上任何联网设备都能下载验证。而“私有”数据有两类链下隐私如Tornado Cash的零知识证明验证过程在链上但输入数据存款地址、取款地址通过ZK-SNARK压缩成短证明原始数据永不上传。浏览器能读到的只有证明本身无法反推。链上加密如使用AES加密交易data字段虽然交易上链但解密密钥只在双方手中。节点推送的仍是加密后的data你拿到也看不懂。所以本项目的能力边界非常清晰它是一个高保真“公开广播接收器”不是“全能链上解密器”。想获取私有信息必须走链下通道如The Graph的子图索引、或中心化API聚合商而这已超出“Simple Web Programming”范畴。我建议用户建立正确认知接受公开数据的透明性正是Web3信任的基石试图绕过它反而违背初心。6.2 性能压测单页面最多能同时监听多少个事件这没有标准答案取决于三个变量浏览器内存每个WebSocket连接约占用2MB内存含缓冲区节点配额Alchemy免费层限制100个并发订阅CPU处理能力每条消息的JSON解析、DOM更新、价格查询都是同步阻塞操作。我做了极限测试在MacBook Pro M1上同时开启50个logs订阅不同NFT合约页面内存升至1.8GBCPU峰值85%但滚动依然流畅。当开到100个时Chrome开始警告“Page is using a lot of memory”DOM更新明显卡顿。所以我的经验阈值是生产环境单页面≤30个订阅开发环境≤50个。超过此数必须做分组懒加载比如只监听用户当前关注的3个合约其他折叠。关键技巧用IntersectionObserver监听区块卡片是否在视口不在时暂停其内部的价格查询定时器进入视口再激活。这能让100个订阅的页面内存降到600MB。6.3 最后一个忠告永远校验subscription ID与unsubcribe很多人以为订阅完就万事大吉其实eth_unsubscribe才是专业性的分水岭。不主动取消节点会一直推送浪费带宽和你的CPU。更严重的是某些节点如旧版Geth对未清理的订阅有连接数上限导致新订阅失败。正确流程页面卸载前beforeunload调用ws.send(eth_unsubscribe)每个订阅成功后把subscription ID存入state.subscriptions重连时先遍历state.subscriptions发取消请求再发新订阅。const unsubscribeAll () { state.subscriptions.forEach((_, subId) { ws.send(JSON.stringify({ jsonrpc: 2.0, method: eth_unsubscribe, params: [subId], id: Math.random() })); }); state.subscriptions.clear(); }; window.addEventListener(beforeunload, unsubscribeAll);我见过最惨的案例一个团队的监控页面忘了写unsubscribe跑了三个月节点累积了2万多个僵尸订阅最终触发节点熔断保护整个团队API被限流。所以记住订阅是开始取消是结束两者同等重要。我在实际项目中发现最稳定的方案永远是“简单粗暴”用最少的依赖、最直白的API、最保守的重试策略。与其纠结WebSocket库选哪个不如把onmessage里的错误解析写扎实与其追求监听100个合约不如把一个Swap事件的金额计算做到毫秒级精准。区块链的世界变化太快但底层的JSON-RPC协议十年未变——抓住不变的才能应对万变。这个项目教会我的不是怎么炫技而是如何用浏览器原生能力谦卑地倾听一条公链的心跳。
相关文章
JavaScript的使用方法及基本语法
一.使用方法（一）行内式直接在HTML标签内添加js脚本，一般用于监听事件。<body><input type"submit" value"登录" onclick"javascript:alert(登录失败);"/></body>（二）…
【虚拟机】ALmaLinux安装
文章目录一、前置说明二、创建虚拟机三、开始安装四、安装配置五、远程连接六、静态网络设置（一）查看当前网络状态（二）设置静态 IP2.1 设 IP2.2 设网关2.3 设 DNS2.4 将获取方式从 “自动” 改为 “手动”（三ÿ…
【路径规划】基于Informed-RRT、原生 RRT、RRT星三种算法实现栅格地图机器人路径规划附matlab代码
✅作者简介：热爱科研的Matlab仿真开发者，擅长毕业设计辅导、数学建模、数据处理、建模仿真、程序设计、完整代码获取、论文复现及科研仿真。🍎 往期回顾关注个人主页：Matlab科研工作室👇 关注我领取海量matlab电子书和…
【RT-DETR实战】176、Web端应用开发：基于Streamlit的快速原型
昨天深夜调试模型导出时，突然接到产品经理电话：“明早要给客户演示RT-DETR的实时检测效果，能不能做个网页版？” 我看了眼时间——凌晨1点。 传统Web开发流程显然来不及，这时候就该祭出Streamlit这个神器了。 从命令行到网页的魔法 我们训练好的RT-DETR模型通常活在Pyt…
向量空间即语义坐标系：工业级主题建模的工程化落地
1. 这不是“用AI跑个模型”——而是重构文本理解的底层逻辑“Using AI to Implement Vector-Based Technology in Topic Modeling”这个标题，乍看像一句技术文档里的标准表述，但在我带团队落地过12个企业级文本分析项目后，它实际指向一个被严…
ARM7TDMI-S架构深度解析：LPC2109系列芯片开发实战与经典外设驱动
1. 项目概述与核心价值在嵌入式系统开发的江湖里，有一类芯片因其在特定历史时期的卓越平衡性而被奉为经典，LPC2109/2119/2129系列就是其中之一。它们基于ARM7TDMI-S内核，虽然如今看来主频不高、资源有限，但在十多年前，…
MuleSoft+LLM企业级AI编排：构建安全可控的智能中枢
1. 项目概述：当企业级集成平台遇上大语言模型，不是叠加，而是重定义工作流“AI Orchestration in Action: How MuleSoft and LLMs Fuel the Future of Enterprise AI”——这个标题里藏着一个正在发生的、静默却剧烈的范式迁移。它说的不是“用…
如何免费下载B站4K大会员视频？终极bilibili-downloader使用指南
如何免费下载B站4K大会员视频？终极bilibili-downloader使用指南 【免费下载链接】bilibili-downloader B站视频下载，支持下载大会员清晰度4K，持续更新中 项目地址: https://gitcode.com/gh_mirrors/bil/bilibili-downloader B站视频下…
AI 驱动的 Rust 测试用例自动生成：从手动编写到智能辅助的工程实践
AI 驱动的 Rust 测试用例自动生成：从手动编写到智能辅助的工程实践 一、测试编写的效率黑洞：重复劳动与覆盖率焦虑 Rust 的类型系统与所有权机制在编译期消除了大量运行时错误，但这并不意味着测试可以省略。边界条件、并发场景、错误路径、泛…
5分钟上手：BilibiliDown——你的B站视频下载全能助手
5分钟上手：BilibiliDown——你的B站视频下载全能助手 【免费下载链接】BilibiliDown (GUI-多平台支持) B站 哔哩哔哩 视频下载器。支持稍后再看、收藏夹、UP主视频批量下载|Bilibili Video Downloader 😳 项目地址: https://gitcode.com/gh_mirrors/bi…
【AI】服务化部署：把AI Agent变成API服务
服务化部署：把AI Agent变成API服务📝 本章学习目标：本章聚焦安全与工程化，确保AI Agent稳定可靠运行。通过本章学习，你将全面掌握"服务化部署：把AI Agent变成API服务"这一核心主题。一、引言&…
Playnite：一站式游戏库管理器，告别多平台切换烦恼
Playnite：一站式游戏库管理器，告别多平台切换烦恼 【免费下载链接】Playnite Video game library manager with support for wide range of 3rd party libraries and game emulation support, providing one unified interface for your games. 项目地…
LED驱动技术全解析：从核心架构到实战选型与避坑指南
1. 从一颗灯珠到千亿市场：LED驱动的技术演进与商业逻辑十几年前，当我第一次从料盘上拿起一颗0603封装的白色LED时，它微弱的光晕和高达几块钱的单颗成本，让我很难想象今天它几乎照亮了我们生活的每一个角落。从手机屏幕的一抹背光&…
索引堆及其优化
索引堆及其优化 引言 索引堆是一种数据结构，广泛应用于计算机科学和软件工程领域。它主要用于解决优先队列问题，如最小堆和最大堆。本文将详细介绍索引堆的概念、实现方法以及优化策略。 索引堆的定义 索引堆是一种基于堆数据结构的索引机制。它通过维护一个堆来存储数据…
从零到日增237精准粉丝，我靠CSDN这张AI卡片爆了！手把手复刻全流程，含配置避坑清单
更多请点击： https://intelliparadigm.com 第一章：CSDN AI 数字营销的官方引流卡片是什么功能？ CSDN AI 数字营销平台推出的「官方引流卡片」，是一种面向技术创作者的轻量级、可嵌入式内容分发组件，专为提升博文、教程…
Zotero Duplicates Merger：5步彻底清理文献库重复条目
Zotero Duplicates Merger：5步彻底清理文献库重复条目 【免费下载链接】ZoteroDuplicatesMerger A zotero plugin to automatically merge duplicate items 项目地址: https://gitcode.com/gh_mirrors/zo/ZoteroDuplicatesMerger 还在为文献库中堆积如山的重…
利用随机有限集理论对蜂群的ILQR和MPC控制研究附Matlab代码
✅作者简介：热爱科研的Matlab仿真开发者，擅长数据处理、建模仿真、程序设计、完整代码获取、论文复现及科研仿真。🍎 往期回顾关注个人主页：Matlab科研工作室🍊个人信条：格物致知,完整Matlab代码及仿真咨询…
为什么你的Gemini邮件CTE低于行业均值2.8倍？：从Prompt架构到发送时序的深度归因
更多请点击： https://intelliparadigm.com 第一章：为什么你的Gemini邮件CTE低于行业均值2.8倍？：从Prompt架构到发送时序的深度归因 Gemini邮件的客户转化效率（CTE）显著偏低，根本原因常被误判为…