以太坊区块链浏览器搭建：架构选型、索引器与运维调优

1. 动手之前：先想清楚自建浏览器要解决什么

很多人对“以太坊区块链浏览器搭建”的第一印象，是装个软件、点几下、网页跑起来就完事了。真动手之后才会发现，浏览器只是最外面那层皮，难的是它背后那套数据管道：一个能稳定应答 RPC 的节点、一个不丢块不重块的索引器、一张能扛住查询的数据库表结构，以及一套还算体面的前端。任何一环掉链子，页面上就是转圈圈或者干脆显示“无数据”。我在第一次搭的时候，光是把索引器追平主网就折腾了两天，中间还因为一次重组把数据写脏，回滚重来。这篇就把这套东西从头到尾拆开讲一遍，包括我踩过的坑和后来摸索出来的参数。

先界定一下范围。标题里的“以太坊区块链浏览器”，指的是一个能查区块、查交易、查地址余额和转账记录、能看合约源码和事件日志的 Web 界面。它跟公网上那几家大浏览器功能上是一回事，区别在于数据源完全由你自己掌控。适合谁来读：一是有链上数据审计或监控需求的团队，公共接口限流一卡就抓瞎；二是做链上应用开发，需要在内网环境反复调试合约调用和事件；三是教学或研究场景，想要一个可解释、可修改的浏览器去观察链的运行细节。如果你只是想查一笔转账确认了没有，说实话没必要自建，直接用现成的更省事。

1.1 公共浏览器的三个隐性成本

不自己搭，就得依赖别人。这里面有三笔账很多人一开始没算清楚。第一笔是接口限流。公共浏览器的开放 API 通常按每秒请求数或每日调用量计费，免费额度对小项目够用，一旦你要批量拉取某个地址三年的交易历史，或者监控几百个合约的事件，很快就会撞墙。撞墙之后的报错往往还很含糊，返回一个空数组，让你以为是这个地址真的没数据。

第二笔是数据口径不可控。同一个地址的余额，不同浏览器在极端情况下可能给出不一样的答案，原因可能是对内部交易（internal transfer）的统计方式不同、对失败交易的展示策略不同、或者索引延迟不同。你做对账的时候，这种口径差异是致命的——你没法向别人解释“为什么我们系统显示的数字跟浏览器差了三块钱”。

第三笔是隐私与合规约束。把内部地址清单、业务流水批量送到第三方接口去查，本身就是一种数据外流。有些团队出于这个考虑，宁可自己在内网跑一套，哪怕性能差一点。这三笔账算下来，自建的门槛其实没想象中高，因为开源方案已经很成熟了，真正的成本在运维和调优上，不在从零造轮子。

1.2 三条技术路线的取舍

实际能走的路大概有三条，我在不同项目里都试过，各有各的适用场景。

第一条是轻量展示型：跑一个支持扩展 RPC 的归档节点，配一个轻前端。这类方案的好处是部署极快，一个 Docker Compose 文件搞定，前端直接调节点的ots_系列接口和标准eth_接口，不建自己的索引库。缺点是重查询很慢，比如“某地址的全部交易历史”，节点只能靠遍历区块来算，一个活跃地址可能让你等上半分钟。它适合内网小范围使用、以查单笔交易和区块为主的场景。

第二条是完整索引型：用成熟的开源浏览器套件，自带索引器、Postgres 存储和完整前端。功能最全，合约验证、代币列表、内部交易、图表都有，代价是资源占用高，索引器追主网需要时间，数据库也会长得比较快。生产环境我基本都走这条。

第三条是自研索引型：自己写一个 worker 从节点拉块，解析后写进自己的表，前端只做你需要的功能。灵活度最高，页面可以完全按业务定制，但工作量也最大，reorg 处理、幂等写入、数据修复这些坑得自己填一遍。如果你只需要监控几类特定事件，而不是做一个通用浏览器，这条反而最划算。

下面这张表是我自己的选型参考，按“要多久能用上”和“后期维护成本”两个维度排的：

1.3 一个容易被忽略的前置决策

在选路线之前，有个问题必须先回答：你要索引全链，还是只索引你关心的部分？这个问题直接决定了磁盘预算和索引时间。全链索引意味着每一笔转账、每一个事件日志都要落库，主网跑下来数据库轻松几百 GB，索引器追平需要几十个小时。而如果你只是做业务监控，实际上可能只关心几十个合约地址，那完全可以只解析这些地址相关的事件，数据库能压到几 GB，索引器几分钟就追平了。

我刚入门时犯的错就是“既然要做就做全的”，结果第一版跑起来磁盘爆了，索引器还落后主网两百多万块，页面上的数据永远是几小时前的。后来改成先只索引核心合约、跑通链路、验证数据正确性，再逐步扩大范围，整个过程顺畅多了。这个思路值得记住：先把管道跑通，再谈覆盖范围。管道不通的时候，扩大范围只会让问题更难定位。

2. 整体架构与选型拆解

一套能用的浏览器，拆开看就是四层：数据源层、索引层、存储层、展示层。每一层的技术选择都会反过来影响其他层，所以不能孤立地挑工具。我在下面把每层的职责和我倾向的选择讲清楚，顺带说明为什么这么选。

2.1 四层结构各自干什么

数据源层是一个执行层节点，负责回答 RPC 请求。它的关键指标不是“能不能启动”，而是“能不能稳定扛住索引器的连续拉取”。索引器追块的时候是高频连续请求，一秒钟几十上百次eth_getBlockByNumber，节点如果同时还在做全量同步，CPU 和磁盘 IO 会被抢得很惨。所以生产环境我一般把节点和索引器分在两台机器上，或者至少给节点留足 IO 余量。

索引层是一个常驻进程，维护一个“我已经处理到第几块”的游标，从节点拉块、解析交易和日志、批量写库、推进游标。它的核心要求是幂等和可重入：同一块处理两遍不能产生重复数据，进程被杀掉重启后能从正确的位置接着跑。

存储层通常是关系型数据库。选它的理由是查询模式太适合了：按地址查交易、按区块号范围查、按事件签名过滤，这些用 SQL 写起来又短又快。表结构设计上最需要注意的是索引，链上数据的表会很大，一个缺索引的查询能把整台机器拖死。

展示层是前端加一层反向代理。前端负责把后端接口的数据渲染成页面，反向代理负责 TLS、限流和静态资源缓存。这层技术含量最低，但配置错了最容易出现“页面能打开但数据加载失败”的情况，九成是跨域或者反向代理把大响应截断了。

2.2 存储与容量估算

这里给一个可以照着算的估算方法，因为磁盘买小了后期迁移非常痛苦。假设你索引全链，主网当前交易总量按亿级计，一条交易记录包含哈希、发送方、接收方、数值、gas 相关字段、输入数据摘要、时间戳，加上主键和几个二级索引，单行落盘大约三百到五百字节。两亿条交易就是 60 到 100 GB。

事件日志（log）比交易多得多，一个区块里几十上百条很常见。单条日志包含地址、四个 topic、data、区块号和日志序号，加上索引大约两百到三百字节，量级上通常是交易表的两到三倍。地址余额表相对小，但地址数量是千万级，也要预留几十 GB。再算上索引本身的膨胀（通常按数据量的 20% 到 30% 估）、数据库的 WAL 和临时空间，最终留一倍余量是稳妥的。

节点这边的数字变化比较快，但量级可以参考：执行层全节点用快照同步，落盘在 1 TB 出头；如果要做归档节点（保留所有历史状态），2.5 TB 以上。这个数字每半年都在涨，所以买盘的时候直接上 4 TB NVMe，别买刚好够用的容量。我吃过一次亏，买了 2 TB，半年后开始删数据腾空间，那段时间天天盯着磁盘告警，体验极差。

2.3 硬件与网络预算

CPU 方面，节点同步阶段是重灾区，十六核起步比较舒服，索引器和数据库各给四到八核。内存上节点建议 32 GB，数据库 16 GB 起，索引器本身吃不了太多。真正卡脖子的是磁盘：必须是 NVMe SSD，而且要看随机读写 IOPS，不能只看顺序带宽。链上数据访问模式是典型的小块随机读，机械盘或者低端 SATA SSD 在同步阶段会直接把你拖到怀疑人生。

网络这块分两个阶段。初次同步时下载量很大，按天算是几百 GB 级别，带宽不够就只能慢慢等，没有别的办法。追平之后进入增量阶段，每天新增的区块数据量很小，主要开销变成你的索引器向节点发起的 RPC 请求，这部分走内网，基本不构成瓶颈。所以别在同步期间做任何带宽敏感的事，我一般会把同步安排在夜里跑，白天该干嘛干嘛。

3. 核心原理：链上数据怎么变成可查的网页

这一节讲的是原理，但它不是纯理论，因为理解了原理你才知道出问题该往哪查。我见过太多人把浏览器当黑盒，日志一报错就懵，其实底层就那几件事。

3.1 JSON-RPC 的能力边界

节点对外提供的是一组 RPC 方法，浏览器能展示什么，完全取决于这些方法能返回什么。最基础的几个：eth_blockNumber拿最新块高，eth_getBlockByNumber拿某个块的完整内容（交易列表、时间戳、gas 使用量），eth_getTransactionReceipt拿回执（状态、日志、gas 实际消耗），eth_getBalance拿余额，eth_getCode拿合约字节码，eth_call做只读调用。

这里有个关键限制：标准接口不提供“按地址查历史交易”。节点只能按块查，不能按地址倒查。这就是为什么必须要有索引器——它把区块顺序扫一遍，把每笔交易按发送方和接收方两个维度都写进表里，之后你才能一句 SQL 查出某个地址的所有流水。理解了这一点，你就明白索引器不是可选项，是必需品。

另一个容易踩的坑是eth_getLogs的范围限制。为了防止单次查询把节点拖垮，客户端通常会对区块范围设上限，超过就直接报错。索引器在设计回补逻辑时，必须把大范围拆成小批次，一次查几千块，而不是一口气查十万块。我第一版就是没拆，回补历史数据时直接报query returned more than 10000 results，改成每批两千块之后就好了。

3.2 索引器的游标与幂等写入

索引器的核心是一个循环，伪代码大概长这样：读游标拿到下一个待处理块号，向节点要这个块的完整数据，解析出交易和日志，在一个数据库事务里写入所有行并更新游标，然后进入下一轮。看起来简单，真正的难点在两处。

第一处是批量写入的粒度。一块一块写，事务开销太大，追块速度上不去；一次写一千块，事务太大，失败回滚成本高，而且内存占用会飙。我的经验值是每批 50 到 200 块提交一次，具体看单块的交易密度。这个参数调优很直接：观察索引器的“块/秒”吞吐，慢慢往上加批量，直到吞吐不再上升或者内存开始告警，就退回来一档。

第二处是游标和数据的原子性。游标必须和数据在同一个事务里更新。如果先写数据再更新游标，中间进程挂了，重启后重复处理，靠唯一索引兜底还能救；如果先更新游标再写数据，中间挂了就会永久丢块，页面上的某段历史永远是空的，而且你还很难发现。这个顺序不能错，我见过有人为了性能把游标更新拆到独立事务里，后来对账时发现少了三千多块，只能全量重扫。

提示：游标表建议单独一张，只存一行，字段为last_indexed_block和updated_at。每次启动时先读这张表，如果为空就从你配置的起始块开始，不要默认从 0 开始——从 0 开始全扫一遍的时间成本你可能承受不起。

3.3 重组处理与确认数策略

链有个特性叫重组（reorg）：短时间内最长的链可能被另一条更长的链取代，之前已经“确认”的区块会失效。对浏览器来说，这意味着你已经索引的某些数据可能变成“不存在的历史”。处理不好，页面上的交易会出现又消失，余额算出来是错的，非常影响信任。

工程上的标准做法是延迟索引：索引器只处理距离链头 N 个块之前的数据，N 一般取 12 到 64。这样等真正处理到某个块时，它已经被足够多的后续块压住，重组概率极低。代价是页面数据有延迟，N 取 12 大概延迟两三分钟。对大多数场景这个延迟完全可以接受，我在生产上用的是 30，实测下来几乎没遇到过需要回滚的情况。

如果真的遇到了重组，需要一个回滚流程：检测到某个块的父哈希与本地记录不符，就把该块之后的所有数据删掉，游标回退到分叉点前一块，重新索引。这个逻辑必须实现，哪怕它一年只触发几次。判断依据可以存每个块的哈希，索引新块时校验父哈希是否等于上一块的哈希，不等就说明分叉了。这个校验成本极低，但能帮你省下一次数据错乱的排查。

3.4 合约源码验证的链路

浏览器上一个合约页面能显示源码、ABI、读写方法，靠的是“源码验证”这个功能。流程是：用户提交源码文件和编译参数，后端用对应版本的编译器重新编译，把得到的字节码与实际部署的字节码比对，一致就存下来。听起来直白，实际操作中失败率高得惊人。

失败原因基本集中在几个点：编译器版本填错（尤其是带 nightly 后缀的版本）、优化开关与优化轮数不一致、EVM 版本参数不一致、构造函数参数没附上、合约引用了外部库需要填库地址、源码是多文件结构但只提交了主文件。我在做验证功能时统计过一轮，八成以上的失败是前三个原因。所以前端表单上最好把这几个字段做成必填并给出提示，能省掉大量沟通成本。

4. 实操：从零搭一套能用的浏览器

下面是我在一个内部项目里实际跑通的流程，按顺序做基本能少走弯路。环境是 Linux，用容器编排来管理各个组件，主要是为了方便升级和回滚。所有路径和参数都可以按自己的实际情况调整。

4.1 环境准备与目录规划

先确认几件事：磁盘挂载在哪个路径、Docker 和 Compose 装好没有、防火墙策略怎么放行。我习惯把所有持久化数据放在一个独立挂载点下，按组件分目录，这样备份和迁移都简单：

/data/chain/node # 节点数据 /data/chain/db # 数据库数据 /data/chain/indexer # 索引器配置与日志 /data/chain/web # 前端配置与证书

节点数据目录一定要单独挂盘，别跟系统盘混在一起。原因很实在：节点写盘非常频繁，混在一起会让系统日志和数据库互相抢 IO，出问题时你连日志都刷不出来。我第一次搭的时候图省事全放在一块盘上，结果同步到一半整机卡死，SSH 都连不上，只能硬重启。

4.2 启动执行层节点

节点启动参数里，跟浏览器相关的就那几个：开启 HTTP RPC、指定暴露的接口、设置监听地址。下面是一份精简过的启动配置，重点是--http.api这一项，浏览器需要eth、net、web3，如果要展示调用追踪还得加debug和trace：

node \ --datadir /data/chain/node \ --http \ --http.addr 0.0.0.0 \ --http.port 8545 \ --http.api eth,net,web3,debug,trace \ --http.vhosts '*' \ --http.corsdomain '*' \ --syncmode snap \ --cache 8192 \ --maxpeers 50

--cache 8192是给数据库缓存分配 8 GB 内存，这个值建议设成机器内存的四分之一左右，太小会让同步阶段的磁盘读放大。--syncmode snap是快照同步，比全量逐块执行快得多，代价是不保留历史状态，所以查历史余额会失败。如果你确实需要查任意历史块的余额，那就得上归档模式，磁盘和时间成本都要翻倍，这个取舍要提前想清楚。

同步过程可能持续一到三天，取决于网络和磁盘。这段时间可以做别的事，但别急着重启节点——反复重启会让它重新校验已有数据，反而更慢。观察进度的方式很简单，调一次eth_blockNumber看块高，跟公共浏览器上的最新块高对比，估算剩余时间。

4.3 部署数据库与索引器

数据库用 PostgreSQL，版本选 14 以上。建库之后先把关键参数调一下，主要是共享缓冲区和工作内存，默认值对链上数据来说太小：

ALTER SYSTEM SET shared_buffers = '4GB'; ALTER SYSTEM SET work_mem = '64MB'; ALTER SYSTEM SET maintenance_work_mem = '1GB'; ALTER SYSTEM SET max_connections = 200;

索引器的配置里，几个字段必须填对：节点的 RPC 地址、数据库连接串、起始块、确认数、批量大小。起始块这个值有讲究，如果你想看历史数据，就填一个你想要的最早块；如果只是做实时监控，直接填当前块减一万，能省掉几天索引时间。确认数建议 30，批量大小从 50 开始试。

索引器启动后先看日志里的“块/秒”吞吐。如果只有个位数，八成是节点响应慢或者数据库写入慢，得分开排查：单独写个脚本连续调eth_getBlockByNumber测节点延迟，如果单次超过 100 毫秒，说明节点在同步或者 IO 被打满；如果节点很快但索引慢，就去数据库看是不是缺索引或者事务太大。这个分离排查的思路很好用，能把问题快速定位到一层。

4.4 前端与反向代理

前端部署最省事的方式是用官方镜像，通过环境变量指定后端地址。反向代理这一层我踩过的坑最多，列几个必须注意的点。

响应体大小限制。某些合约的 ABI 或者大区块的日志列表返回体能有几 MB，代理默认的缓冲区小了会返回 502，报错信息还指向代理本身，让人误以为是后端挂了。把proxy_buffer_size和proxy_buffers调大就行。

超时设置。合约验证是个重操作，要下载编译器、编译、比对，慢的时候二三十秒。代理默认 60 秒超时有时候不够，尤其是编译器需要现场下载的情况，设到 120 秒比较稳。

跨域配置。如果前端和后端不在同一个域名下，一定要配好 CORS，并且注意预检请求要放行。这个错误的表现是页面能打开，但所有数据接口都报跨域，浏览器控制台一片红。

配置好之后先用浏览器访问首页，确认能看到最新块高在滚动。这一步行了，说明数据链路通了，剩下的都是细节。

4.5 合约验证的关键配置

如果你要开放源码验证功能，有几个配置项必须提前定好：编译器版本的下载源、支持的编译器版本列表、是否需要 API key 才能提交。编译器下载源建议在本地缓存一份，别每次都去外网拉，一是慢，二是外网不稳的时候功能直接不可用。

我在一个离线环境里部署过，做法是提前把常用版本的编译器二进制下载到本地目录，然后配一个本地文件服务，把索引器的编译器下载地址指过去。这个改造不难，但能省掉大量“验证功能时好时坏”的问题。另外记得把优化开关、优化轮数、EVM 版本这几个表单字段做成下拉选择而不是自由输入，能显著降低用户填错导致验证失败的比例。

4.6 监控与备份

监控至少要盯三个指标：节点块高与公共链头的差值、索引器游标的块高与节点块高的差值、数据库磁盘占用。前两个差值持续增大就说明有问题，第三个是容量预警。我用一个简单的定时脚本每分钟采集一次，超过阈值就发通知，比事后发现页面数据是几小时前的要好得多。

备份策略上，数据库每天做一次逻辑备份，节点数据不做备份（重新同步比恢复备份可能还快，而且备份几个 TB 的成本太高）。数据库备份要验证可恢复性，我见过备份文件天天生成但从来没测过恢复，真出事的时候发现备份是空的。这个检查花不了多少时间，但关键时刻能救命。

5. 常见问题与排查速查

下面这些是我在实际运行中反复遇到或者帮别人排查过的问题，按现象、原因、处理方式整理。真出问题的时候可以照着对号入座。

5.1 节点同步卡住不动

现象是块高长时间不涨，日志里也没有明显报错。原因通常有三类：对等节点太少、磁盘 IO 被打满、系统时间不准导致握手失败。先看连接数，少于十个就说明网络或引导节点配置有问题；再看磁盘使用率，如果持续 100% 那就是 IO 瓶颈，考虑加盘或者降级同步模式；最后检查系统时间，偏差超过几秒会影响节点间通信。

还有一个不太常见但很坑的原因：数据目录权限不对，导致节点能启动但写不进数据，日志里可能只是一行不起眼的警告。排查时直接看数据目录的文件修改时间，如果十分钟没变化，基本就是这个问题。

5.2 磁盘占用增长远超预期

通常不是节点的问题，是索引器或者数据库的问题。先看数据库里哪张表最大，八成是日志表或者交易表。如果日志表异常大，检查是不是把eth_getLogs的返回全部原样存了，包括重复的冗余字段；如果交易表大，看看是不是把输入数据全文存了，对于合约部署交易，输入数据可能有几十 KB。

处理方式上，输入数据可以只存前若干字节加哈希摘要，需要完整数据时再回节点取。日志的 data 字段同理，很多场景只需要 topic 做过滤，不需要完整 payload。这两个改动在我的项目里把数据库压小了将近一半，代价是少数查询要多一次 RPC 调用。

5.3 索引器追不上主网

现象是游标块高一直在涨，但离链头越来越远。这说明单块处理速度低于出块速度。先算一下：出块间隔按十几秒算，如果你的索引器每秒处理不到一块，那永远追不上。

提速的手段按性价比排序：加大批量提交、给热点表补索引、把节点和数据库放到同一内网、把解析逻辑里不必要的字段计算去掉。最有效的一般是批量提交，其次是减少每块的 RPC 调用次数——比如回执可以批量取，不要一块一次请求。我做过一轮优化，把每块三次 RPC 合并成一次批量请求，吞吐直接翻倍。

5.4 数据错乱与重组残留

现象是某个交易在页面上出现了两次，或者某地址余额算出来对不上。先查唯一约束有没有建，交易哈希、日志的（块号, 交易哈希, 日志序号）组合都必须有唯一索引，这是防重复的最后一道闸。如果没有唯一约束，重复索引就会产生重复行。

如果确认是重组导致的，看分叉点在哪：找到本地记录的块哈希与节点返回的块哈希第一次不一致的位置，把该块之后的数据全部删掉，游标回退，重新索引。这个过程要写成一个脚本，别手工删，容易删错范围。

5.5 合约验证失败排查表

这张表覆盖了我遇到的九成情况。剩下那一成通常是源码本身不完整，比如只提交了主合约文件但引用了同目录下的接口文件，这种只能让提交方补全，没有捷径。

5.6 几条独家避坑经验

注意：索引器的起始块不要设成 0。主网从 0 扫到现在，就算每秒处理十块也要好几天，而且早期区块的数据你基本用不上。设成最近一百万块，既能覆盖绝大多数查询需求，又能把索引时间压到几个小时。

第一条，先把确认数调大再调小。初次搭建时用 30 甚至 64，等链路稳定运行一周、确认没有重组异常之后，再考虑降到 12 换取更低延迟。反过来做的话，前期数据错乱的排查会让你怀疑人生。

第二条，数据库连接池别开太大。链上数据的查询经常有慢查询，连接池开太大会导致慢查询把连接占满，后续请求全部排队。把池子控制在几十个，配合语句超时，宁可让个别慢查询失败，也别让整个服务卡死。

第三条，节点和索引器分开部署。这一条我强调过但值得再说一遍，因为它是最高频的性能问题来源。索引器追块时是 IO 密集型，节点同步时也是 IO 密集型，两者挤在一台机器上，谁都跑不快。

6. 性能调优与长期运维经验

搭起来只是开始，真正耗精力的是后面几个月的运行。这一节讲的是我在长期运维中总结出来的、文档里通常不会写的经验。

6.1 只索引真正需要的范围

这个思路在前面提过，这里展开说。如果你的浏览器是给内部业务用的，绝大多数查询集中在少数几个合约和少数几个地址上。那就没必要做全链索引，配置一个地址白名单，索引器只解析白名单地址相关的事件和交易，其他块直接跳过游标。这样做的收益非常明显：索引时间从几十小时降到几分钟，数据库从几百 GB 降到几 GB，查询响应从几百毫秒降到几毫秒。

代价是页面上查一个不在白名单里的地址会显示无数据。这个体验问题可以通过降级处理解决：不在白名单的地址，前端提示“该地址未纳入索引范围”，并提供一个“实时查询”按钮，点了之后后端直接调节点算一遍余额和最近若干笔交易。这个混合方案我在两个项目里用过，用户接受度很高。

6.2 缓存与查询优化

浏览器的查询有明显热点：首页的最新块、最活跃的几个地址、几个主流合约的页面，占了绝大部分流量。给这几类查询加一层缓存，效果立竿见影。最简单的做法是在反向代理层对静态化程度高的接口做短时间缓存，比如最新块列表缓存五秒，合约元数据缓存一小时。

更彻底的做法是在应用层加内存缓存，键用查询参数的哈希，值存序列化后的结果，设一个较短的过期时间。对于“某地址的交易列表”这类分页查询，可以在缓存键里带上页码，避免翻页时反复打数据库。这个改动不大，但能把数据库的峰值压力削掉一大半。

数据库层面，最值得做的优化是给查询条件建复合索引。地址交易查询通常是“按地址 + 按块号倒序”，那就建一个（地址, 块号）的复合索引，比两个单列索引快得多。这个优化我从几百毫秒压到了十毫秒以内，是投入产出比最高的一步。

6.3 升级策略与版本锁定

节点客户端、索引器、数据库这三个组件的版本，我建议锁定，不要追新。链上软件迭代很快，新版本可能改了 RPC 行为、改了数据目录结构、或者引入了新的默认配置，升级之后可能直接起不来。我吃过一次亏：随手升级了节点版本，结果数据目录需要重新迁移，几 TB 的数据要重刷，硬生生耗掉两天。

具体做法是，把每个组件的镜像标签钉死在具体版本号，不要用 latest。升级之前先在测试环境跑一遍，重点验证三件事：索引器能不能连上节点、已有数据能不能正常查询、新块能不能正常索引。三件都通过了再动生产。数据库升级更保守，大版本升级前必须做一次完整备份并验证恢复。

还有一个小细节：节点的启动参数里有些是实验性的，升级后可能被重命名或者移除。把启动参数写在一个版本化的配置文件里，升级的时候对比一下变更有哪些，比升级完发现启动失败再去翻日志要高效得多。

提示：如果条件允许，准备一台备用机做灰度。主库挂掉的时候可以切过去顶一段时间，哪怕性能差一点，也好过完全不可用。

上面这一整套跑下来，一个能用的以太坊区块链浏览器大概需要两到三天完成首次部署，之后一周左右进入稳定状态。我个人在实际操作中的体会是，前期的架构决策比后期的参数调优重要得多——选错了索引范围，后面怎么优化都是事倍功半；选对了，很多问题根本不会出现。另外别一上来就追求功能对齐公共浏览器，先把查块、查交易、查地址这三条主线跑通，剩下的功能按需加，节奏会舒服很多。