从 main() 到节点运行：Geth 的启动流程

每个复杂系统都有自己的启动序列——将一个静止的二进制文件变成正在运行的服务，需要经历一系列精心编排的步骤。一旦掌握了关键角色，Geth 的启动过程读起来其实相当清晰。整个流程遵循一条明确的管道：解析 CLI 参数、创建协议无关的 Node 容器、在其中接入 Ethereum 服务、开放网络端点，最后启动所有已注册的生命周期组件。

本文将跟随这条管道的每一步，从只有五行的 main() 函数一路走到节点开始处理区块的那一刻。在这个过程中，你会发现 Node 即容器 这一设计模式——它将协议逻辑与基础设施关切彻底解耦，可以说是整个代码库中最重要的架构模式。

CLI 框架与入口点

Geth 使用 urfave/cli/v2 框架处理命令行解析。初始化工作在 init() 中完成，它在 main() 之前运行：

sequenceDiagram
    participant OS as Operating System
    participant Init as init()
    participant Main as main()
    participant App as urfave/cli App

    OS->>Init: Process starts
    Init->>App: app.Action = geth
    Init->>App: Register commands (init, import, console, ...)
    Init->>App: Register flags (nodeFlags, rpcFlags, metricsFlags, ...)
    Init->>App: AutoEnvVars(flags, "GETH")
    OS->>Main: main()
    Main->>App: app.Run(os.Args)
    App->>App: Parse flags, dispatch to action

init() 主要做三件事：将 app.Action 设为 geth（默认命令）、注册所有子命令（如 init、import、console、attach），以及注册涵盖节点配置、RPC 设置、指标和调试选项的大量参数。

有一个值得注意的细节：flags.AutoEnvVars(app.Flags, "GETH") 会自动为每个参数生成对应的环境变量名。例如，--datadir 参数对应的环境变量就是 GETH_DATADIR，完全不需要手动编写样板代码。

实际的 main() 只有五行：

func main() {
    if err := app.Run(os.Args); err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
}

当没有指定子命令时，urfave/cli 会将控制权交给 app.Action，也就是 geth 函数。

启动路径：geth() → makeFullNode() → startNode()

geth() 是整个启动序列的核心——仅用十三行代码就完成了一个完整以太坊节点的创建与运行：

func geth(ctx *cli.Context) error {
    if args := ctx.Args().Slice(); len(args) > 0 {
        return fmt.Errorf("invalid command: %q", args[0])
    }
    prepare(ctx)
    stack := makeFullNode(ctx)
    defer stack.Close()
    startNode(ctx, stack, false)
    stack.Wait()
    return nil
}

整体分四步：prepare() 初始化日志和内存缓存；makeFullNode() 创建 Node 容器并接入 Ethereum 服务；startNode() 启动所有组件；stack.Wait() 阻塞直到节点关闭（通过信号或 API 调用触发）。

sequenceDiagram
    participant G as geth()
    participant P as prepare()
    participant MFN as makeFullNode()
    participant SN as startNode()
    participant N as Node

    G->>P: Setup logging, metrics
    G->>MFN: Create Node + Ethereum service
    MFN-->>G: return stack (*node.Node)
    G->>SN: Start all services
    SN->>N: utils.StartNode() → Node.Start()
    G->>N: stack.Wait() — blocks until shutdown

提示： 排查启动问题时，重点始终在 prepare() → makeFullNode() → startNode() 这三个调用上。它们构成了完整的启动故事。

Node 即容器模式

正如第一篇中所介绍的，node.Node 结构体是一个与协议无关的服务容器。它对以太坊本身一无所知，只负责管理 P2P 网络、RPC 服务器、数据库和服务生命周期：

type Node struct {
    eventmux      *event.TypeMux
    config        *Config
    accman        *accounts.Manager
    log           log.Logger
    stop          chan struct{}
    server        *p2p.Server
    state         int           // initializingState → runningState → closedState
    lifecycles    []Lifecycle
    rpcAPIs       []rpc.API
    http          *httpServer
    ws            *httpServer
    httpAuth      *httpServer   // JWT-authenticated for Engine API
    wsAuth        *httpServer
    ipc           *ipcServer
    inprocHandler *rpc.Server
    databases     map[*closeTrackingDB]struct{}
}

Node.New() 构造函数负责配置 P2P 服务器、创建各类 RPC 端点服务器（HTTP、WebSocket、IPC 及其认证变体）、初始化账户管理器，并对数据目录加文件锁以防止并发访问。

注意那两个带认证的服务器（httpAuth、wsAuth）——它们专门服务于 Engine API。node.httpAuth.disableHTTP2 = true 这行代码是一个务实的选择：Engine API 不需要 HTTP/2，禁用它可以避免与共识层客户端交互时的潜在问题。

classDiagram
    class Node {
        -config *Config
        -server *p2p.Server
        -lifecycles []Lifecycle
        -rpcAPIs []rpc.API
        -http *httpServer
        -httpAuth *httpServer
        -ipc *ipcServer
        -databases map
        +Start() error
        +Close() error
        +Wait()
        +RegisterLifecycle(Lifecycle)
        +RegisterAPIs([]rpc.API)
        +RegisterProtocols([]p2p.Protocol)
    }
    class Lifecycle {
        <<interface>>
        +Start() error
        +Stop() error
    }
    class Ethereum {
        +Start() error
        +Stop() error
    }
    Node o-- Lifecycle
    Ethereum ..|> Lifecycle

构建 Ethereum 服务：eth.New()

eth.New() 是整个代码库中最长的单个函数——近 250 行代码，将整个以太坊协议的各个部件串联在一起。其执行顺序如下：

flowchart TD
    A["Open chaindata database"] --> B["Load chain config + genesis"]
    B --> C["Create consensus engine<br/>(beacon wrapping clique or ethash)"]
    C --> D["Create BlockChain"]
    D --> E["Initialize FilterMaps log index"]
    E --> F["Create legacy tx pool + blob pool"]
    F --> G["Create TxPool aggregator"]
    G --> H["Create handler<br/>(P2P coordinator)"]
    H --> I["Create Miner<br/>(payload builder)"]
    I --> J["Create EthAPIBackend + gas oracle"]
    J --> K["Register APIs, Protocols,<br/>Lifecycle with Node"]

该函数通过 stack.OpenDatabaseWithOptions("chaindata", ...) 打开链数据库，加载或初始化链配置，创建共识引擎，构建完整的区块链对象，初始化交易池（包括传统类型和 blob 类型），创建 P2P handler，配置 miner，并接入 API backend。

关键的注册步骤发生在 eth.New() 的末尾：

stack.RegisterAPIs(eth.APIs())
stack.RegisterProtocols(eth.Protocols())
stack.RegisterLifecycle(eth)

这三行调用将 Ethereum 服务连接到 Node 容器。Node 不知道、也不关心自己运行的是以太坊——它只负责管理生命周期并暴露 API。

配置的分层结构

Geth 的配置经由多个层次流转，每一层都更加具体：

flowchart TD
    CLI["CLI Flags<br/>(--syncmode, --cache, ...)"] --> ETH_CFG["ethconfig.Config<br/>Protocol-level defaults"]
    CLI --> NODE_CFG["node.Config<br/>Infrastructure settings"]
    ETH_CFG --> CHAIN_CFG["params.ChainConfig<br/>Fork schedule"]
    ETH_CFG --> BC_CFG["core.BlockChainConfig<br/>Runtime parameters"]
    CHAIN_CFG --> RULES["params.Rules<br/>Per-block fork flags"]

ethconfig.Defaults 提供了合理的默认值——snap 同步模式、2GB 数据库缓存、60 分钟 trie 超时、RPC 调用 5000 万 gas 上限。CLI 参数会覆盖这些默认值，最终生成的 Config 结构体驱动所有子系统的构建。

params.ChainConfig 尤为有趣——它采用了双重激活机制：早期分叉（从 Homestead 到 GrayGlacier）通过区块号激活，而合并后的分叉（Shanghai 及以后）则通过时间戳激活。这一点在结构体字段中一目了然——HomesteadBlock *big.Int 对应的是 ShanghaiTime *uint64。

主网、Sepolia、Holesky、Hoodi 等预置网络的 ChainConfig 已作为包级变量定义在 params/config.go 中，在这些已知网络上启动节点无需任何手动配置。

三阶段生命周期与注册机制

Node 有一个简单的状态机，共三个状态，定义在 node/node.go 中：

const (
    initializingState = iota
    runningState
    closedState
)

服务只能在 initializingState 阶段注册。RegisterLifecycle 方法对此做了强制约束：

func (n *Node) RegisterLifecycle(lifecycle Lifecycle) {
    n.lock.Lock()
    defer n.lock.Unlock()
    if n.state != initializingState {
        panic("can't register lifecycle on running/stopped node")
    }
    // ...
    n.lifecycles = append(n.lifecycles, lifecycle)
}

调用 Node.Start() 时，节点状态切换到 runningState，随即开放所有网络端点（P2P、RPC），并依次调用每个已注册生命周期的 Start() 方法。如果某个生命周期启动失败，已经启动的组件会按相反顺序全部停止——这是一种干净的回滚机制。

关闭流程同样有序。Node.Close() 按注册的逆序停止各生命周期，然后依次关闭 RPC 端点、P2P 网络，最后关闭所有已追踪的数据库。closeTrackingDB 包装器确保通过 Node 打开的数据库在关闭时自动释放，防止资源泄漏。

提示： geth() 末尾的 stack.Wait() 阻塞在一个 channel 上，该 channel 在 Node.doClose() 中关闭。要触发优雅关闭，发送中断信号（SIGINT/SIGTERM）即可——信号处理器会调用 stack.Close()，从而解除 Wait() 的阻塞，让 geth() 正常返回。

节点运行起来之后，下一篇文章将深入探讨区块到来时发生了什么：区块如何流经 BlockChain manager、如何经过共识引擎的验证，以及如何在 EVM 中逐笔执行交易。