CPU 内存都够，节点却追不上链头：公链全节点的资源瓶颈在盘上

一台 8 核 32G 的机器，跑着以太坊执行层加共识层两个进程，监控面板上 CPU 利用率长期徘徊在两三成，内存占用一半出头，负载也不高。可区块高度就是离链头差着几千个块，而且这个差值只会变大不会变小。运维的第一反应通常是同步线程没吃满，把客户端的并行参数调大，或者干脆换 16 核。换了之后头两天好像快了一点，第三天又回到老样子。重启一次，缓存全丢，从头去追状态，追了十几个小时还是卡在同一个位置附近。真正卡住这台机器的东西，在监控面板的第一页上根本看不到。

CPU 没打满却追不上链头：第一反应往往是错的

全节点同步不是"下载一堆区块然后存起来"这么简单。它本质上是一次状态重建：从对等节点拉回区块头与区块体，在本地逐笔重放交易，把每一笔产生的结果写进状态树，同时不断校验状态根是否和区块里记录的一致。这里面真正耗时的部分不是网络下载，也不是签名验算，而是对一棵体量在 TB 级、节点数以亿计的状态树做海量小随机读和反复覆写。

为什么"CPU 空闲"恰恰指向 IO 而不是算力

CPU 利用率低而进度停滞，说明执行线程大部分时间在等数据。同步线程要读一个账户的余额、读一个合约槽位，路径是几十层的哈希查找，每一层都要落一次盘。这些读请求单个只有 4KB 上下，彼此之间毫无顺序可言，任何预读和顺序合并都帮不上忙。于是磁盘队列排满、单次读写延迟冲到十几甚至几十毫秒，CPU 却在空转等返回。这种状态下加核数，等于给一条堵死的路口多开几条车道，一点用没有。

判断方法很直接：在节点机器上跑 iostat -x 1，看数据盘所在设备的 %util 是否长期贴着 100%，await（单次 IO 平均等待毫秒数）是否持续在两位数以上，同时 top 里的 iowait 占比明显高于用户态。如果这几个指标同时成立而 CPU user 态只有三成，瓶颈位置就已经确证了。另一个旁证是客户端日志里反复出现状态修复（state heal）相关的条目，进度条长时间不推进。

重启为什么会加重而不是缓解

重启之后追不上，是这类故障最有迷惑性的地方。很多人以为重启能"清掉脏状态"，实际效果是反的：内存里的状态缓存被清空，下一次读取全部落到冷盘上，随机读的量比重启前更大。而状态树的规模在这段时间里并没有缩小，它只会增长。所以你会看到一个很典型的现象——重启后同步速度短暂冲高（那是在跑顺序写入的部分），随后跌回原来的水平甚至更低，因为冷缓存让每一次随机读都要真刀真枪地碰盘。

说白了，这是一次介质选型的失败，不是一次算力配置的失败。它不会因为时间推移自愈，也不会因为多加内存根治，只会在链上数据继续增长的过程中越来越明显。

不同节点类型的资源画像差别很大，别用一套配置套全部

先厘清一件事：以太坊全节点不是一个进程，而是执行层客户端加共识层客户端两个进程，通过本地 RPC（通常走 JWT 认证的 Engine API）通信。两者对资源的要求完全不同，执行层吃存储和随机 IO，共识层吃内存和相对稳定的网络。任何只谈"一个节点"的配置建议，都缺了一半。

执行层客户端之间的存储差异

Geth 是最常见的选择，也是资源画像最"重"的一个。它用哈希式状态树存历史状态，归档模式下公开资料给出的量级可以达到 12TB 以上，且仍在持续增长。Nethermind 官方建议磁盘提供 10k 以上 IOPS，这是公开文档里少见地直接点名 IOPS 数值的执行层客户端，也从侧面说明存储性能在这类负载里的权重。Besu 提供 Bonsai 这类存储布局，主打降低历史状态的冗余占用。Erigon 换了一套完全不同的思路，用 MDBX 做底层存储、把状态扁平化，因此它的全节点与归档节点占用都压到 2–3TB 量级。Reth 是较新的 Rust 实现，公开资料给出的参考值是全节点约 1.2TB、归档约 2.2–2.8TB。

这些数字都是公开资料参考值，实际需实测确认，而且它们随链上活动单调增长。但差异本身是稳定的：同样是归档节点，选哈希式实现和选扁平化实现，容量需求可以差出一个数量级，这直接决定了你是买一块 4TB 的盘还是买一整台存储型机器。

共识层客户端的画像

Lighthouse、Prysm、Teku、Nimbus 这几个共识层客户端，存储占用都在约 200GB 量级（公开资料参考值，持续增长），差距远没有执行层那么夸张。以 Teku 官方给出的组合基线为例，全节点搭配执行层的参考是 4 核 2.8GHz、16GB 内存、2TB SSD、10Mbps 以上带宽。共识层对内存相对敏感，因为要维护验证者集合与分叉选择的状态；对 CPU 的要求集中在签名聚合验证上，核数需求不高但对主频有实际体感。

剪枝节点的位置

剪枝（pruned）节点处在全节点和归档节点之间：保留最新状态，丢弃大部分历史状态，只保留能够重新验证所需的部分。它的容量介于两者之间，随机 IO 压力不比全节点小——因为剪枝本身就是一个持续的重写入过程，会产生额外的写放大。如果业务只需要查询最近状态和广播交易，剪枝节点通常是容量与成本更合适的落点。

存储到底要多大：看量级，更要看增长曲线

官方 node 文档给出的存储基线是 2TB SSD。这条基线在今天的实际分布里仍然成立，但它是下限而不是舒适区。snap 同步后的全节点常见占用在 1.3–2.5TB 区间，取决于客户端版本、是否剪枝、以及运行时长。共识层再叠加大约 200GB 量级。

为什么必须留 30%–50% 余量

把 2TB 盘用到 1.9TB 再想着扩容，是很常见的翻车路径。余量不是浪费，它有四个具体用处：一是写放大，客户端在压缩状态、做修剪、生成快照时会临时占用成倍空间；二是客户端大版本升级经常需要新旧数据目录并行一段时间，等于短暂占用两份；三是磁盘本身在接近写满时性能会明显下滑，尤其是 TLC/QLC 盘在剩余空间不足时可用作 SLC 缓存的块变少，掉速会更早出现；四是留出做本地备份或快照的余地。

按 2TB 起步、预留 30%–50% 余量来倒推，实际下单时更合适的是 4TB 这一档，或者先用 2TB 但确认机器支持后续加盘与在线扩容。这个取舍取决于预算是一次性投入还是按月租，也取决于这台节点的生命周期预期。

增长速率决定了扩容窗口

公开资料给出的参考值是：Geth 在 snap 同步完成之后，数据仍以每周约 14GB 的量级增长。按这个速率粗略推算，一年新增量在 700GB 上下。也就是说，一块 2TB 的盘在放满 1.3TB 数据后，理论上的可用窗口大约是一年到一年半。真正容易被忽略的是，这个速率不是恒定的——链上活跃度上升时它会加快，而历史状态只会累积不会回退。

什么时候必须扩到 4TB？给出三个可操作的判断线：一是剩余空间低于 25% 且没有下降趋势的拐点；二是计划做归档或准备把执行层客户端换成哈希式实现；三是准备承担对外 RPC 查询且不能接受因盘满导致的停服。满足任意一条，就应该把扩容提前排进计划，而不是等告警。

随机读 IOPS 是硬门槛，吞吐数字好看没有用

很多云盘的宣传口径是顺序吞吐 GB/s，这个指标对全节点几乎没有参考价值。状态树访问是 4KB 级别的随机读，衡量它的单位是 IOPS 和延迟，不是带宽。同步与出块处理的速度，在磁盘成为瓶颈的那一段区间里，几乎随 IOPS 线性变化——IOPS 翻倍，同步时间大致减半；IOPS 不够，加多少核都补不回来。

介质与形态的实际分档

公开资料里比较一致的观察是：数据中心级或消费级 TLC NVMe，初始同步通常能在数小时到一天内完成；SATA SSD 只能说勉强，能跑但余量极小，遇到链上活跃期就可能掉队；机械硬盘基本追不上，随机寻道时间在毫秒量级，与状态树的访问模式完全不匹配。这个分档不是"快慢"的差别，是"能不能完成初始同步"的差别。

QLC 是另一个需要单独点名的坑。QLC 盘在 SLC 缓存范围内写入很快，一旦持续写入超过缓存容量，直写速度会掉到接近机械盘的水平，而全节点的写入恰恰是长时间、大批量、不间断的。低 IOPS 云盘的机制不同但结果相似：它往往提供突发 IOPS 额度，短时间跑分很好看，额度耗尽后被限速，同步进度随之断崖式下跌。这两种盘的共同特征是"开始很快，后面垮掉"，非常容易被误判成客户端配置问题。

把盘的优先级排在 CPU 之前：选型时的实际取舍

一万网络这类深耕 IDC 19 年（成立于 2007 年）的服务商在配这类状态型负载时，通常把 NVMe 盘的介质与 IOPS 放在 CPU 之前考虑，并建议独立数据盘与系统盘分开——系统盘跑日志和操作系统，数据盘单独承担状态树的随机 IO，两者互不干扰，也方便单独扩容和做快照。就机型而言，裸金属 E5-2698v4×2 ¥3999 起（海外买 1 送 1）、E5-2620 ¥999 起这类配置可以作为预算比选的起点，实际价格以官网实时价为准；是否要上更高主频的型号，取决于你对初始同步时长的容忍度，而不是取决于核数是否够用。

这里有个很实际的问题：同样的预算，买 16 核配 SATA SSD，还是 8 核配 TLC NVMe？对全节点这个负载，后者是明显更合适的选择。前者会给你一台 CPU 利用率永远三成、区块高度永远滞后的机器。

内存和 CPU 在全节点里的真实角色

内存主要不是给进程本身用的，是给状态缓存用的。客户端会把热点状态放在内存里，避免每次访问都落盘。缓存命中率上去了，随机 IO 的量就下来了——这就是为什么加内存能"缓解"IO 瓶颈，却不能"解决"它：缓存只能覆盖一部分状态，链上数据增长后未命中的部分依旧要碰盘。官方基线是 8GB 起、推荐 16GB 以上；实际部署里 16GB 可用、32GB 更从容，跑归档或对外提供高频历史查询时再往上加。

CPU：核数够用就行，主频更关键

官方基线写的是 2 核以上、推荐 4 核以上。实际场景下 4–8 核通常够用，把预算从 16 核挪到更高主频的 8 核，对同步速度的改善更明显。原因是同步过程里真正吃 CPU 的环节——交易执行、签名验证、状态根计算——大多是难以完全并行的串行或弱并行任务，主频和单核性能的影响大于核数。

CPU 真正被打满的场景有几个：初始同步期间的快照生成、归档节点的重建、对外提供大量 eth_call 历史查询。如果你的业务是后者，那确实需要按 CPU 来配；如果只是维持一个跟随链头的 RPC 节点，CPU 反而是最容易过剩的资源。

出网流量常被低估，计费方式要提前定

全节点的出网流量比大多数人预估的高很多。它不只在同步时下载，还在持续向上游对等节点、向其他正在同步的节点提供区块与状态数据。公开资料给出的常见量级是月度 1.5–3TB，对外提供 RPC 服务的节点会更高。按流量计费的机器在这个量级下，账单很容易超过机器本身的月租。

所以选型时应该优先选不限流量或高流量配额的方案，而不是盯着带宽峰值。官方带宽基线是 10+ Mbps、推荐 25+ Mbps 且不限流量——注意这里推荐的是"不限流量"，不是"更大带宽"。带宽峰值决定同步能多快，流量总量决定账单会不会爆，两者不是一回事。

扩容与日常运维：独立数据盘、快照、升级与监控

独立数据盘是架构前提

把客户端数据目录放在独立的挂载点上，而不是塞在系统盘里。这样系统盘写满不会影响节点，节点数据暴涨也不会拖垮系统。容量扩张时可以直接加盘、迁移目录，或者用逻辑卷做在线扩容。这一步在部署第一天就要定好，后期改造需要停服。

快照与恢复的现实约束

快照要分清系统盘和数据盘。系统盘快照能救回操作系统和配置文件，但救不回状态数据；对运行中的数据库类目录做快照，还存在一致性风险——快照那一瞬间正在写入的状态树可能是半截的。稳妥做法是停机后做数据盘快照，或者用客户端自带的导出/导入机制做冷备。以服务形态而言，免费系统盘快照（每日 3 份 / 30 秒回滚）这类能力主要用于快速恢复系统与配置，数据盘的一致性仍需靠停机快照或定期冷备来保证；硬件故障 10 分钟自动迁移机制能减少宿主机故障带来的停机时间，节点侧的追块仍需自己承担。

客户端升级与硬分叉

公链客户端升级频率高，硬分叉有明确时间点，错过升级的节点会停在旧链上。运维上要预留新旧数据目录并行的空间（这也是前面强调留 30%–50% 余量的原因之一），并保留回滚路径。升级前记录当前版本与数据目录大小，升级失败时能原路退回。

监控要看的四类指标

第一类是盘的剩余空间与增长速率，用增长速率做线性外推，提前两周预测触顶时间。第二类是磁盘 IO 健康度，包括 await、%util、以及 IOPS 是否被限速（云盘尤其要看这一项）。第三类是区块高度滞后量，即本地高度与链头的差值，这是唯一的业务级健康指标，告警应该打在这里而不是打在 CPU 上。第四类是对等节点数，节点掉出网络后高度会静止不动，但 CPU 和磁盘看起来都很闲，很容易被漏掉。

什么时候不该自建：三个明确的否定条件

自建节点不是默认正确选项。满足下面任意一条，用第三方节点服务更划算。

第一，只偶尔查数据。如果一个月只查几次历史交易，一台 7×24 跑着的存储型机器做完初始同步的成本，远高于按调用量付费的 API。第二，不要求可自证。自建的核心价值是自己验证、不信任任何第三方返回；如果你的业务可以接受信任第三方节点的结果，那这份投入就没有对应收益。第三，团队无法承担 7×24 运维。节点升级、硬分叉、盘满、掉线、状态损坏，这些都要有人响应。没有排班能力的小团队，自建节点的实际可用性往往低于托管服务。

反过来说，需要自己验证交易、需要合规审计可自证的数据源、需要为 DApp 提供稳定且不受第三方限流影响的 RPC，这三类需求才撑得起自建的运维成本。海外节点作为预算比选对象时，可以考虑有中文工单支持的服务商，比如 7×24 中文工单平均 5 分钟响应、5–20G 免费 DDoS 防护这类能力，在处理节点被扫段、被打流的场景时能省掉不少沟通成本；具体价格与规格以官网实时报价为准。

五个真实会踩的坑：为什么坑、怎么判断、怎么避

坑一：用低 IOPS 云盘跑同步，开始很快后面垮掉

为什么坑：云盘普遍用突发 IOPS 额度做性能上限，短时间跑分很好看，额度耗尽后被限速。全节点同步是数小时到数天的持续高 IO，必然撞上这个墙。怎么判断：同步前两小时进度飞快，之后速度断崖下跌，同时云厂商监控里 IOPS 曲线呈阶梯状被削平。怎么避：选盘时看的是"持续 IOPS"而不是"突发 IOPS"或"最大吞吐"；下单前向服务商确认该盘型的稳态 IOPS 配额，并把配额写进配置清单。

坑二：买了 QLC 大容量盘，容量够了速度没了

为什么坑：QLC 依赖 SLC 缓存吸收写入，全节点的写入是长时间不间断的，缓存必然被打穿，之后直写速度大幅下降。怎么判断：盘刚上线时同步速度正常，写入量累积到一定规模（通常是缓存容量的量级）后速度明显下滑，且不再恢复。怎么避：明确要求 TLC 介质；采购时确认 DWPD 与 TBW 指标，全节点属于写入密集型负载，消费级低耐久盘不适合。

坑三：数据目录和系统盘共用一块盘

为什么坑：节点数据增长会把系统盘一起撑满，导致系统无法写日志、无法启动新进程，故障表现是"整台机器诡异失灵"而不是"节点报错"，排查成本极高。怎么判断：检查客户端数据目录是否在根分区下；看 df -h 里根分区使用率是否随同步持续上涨。怎么避：部署阶段就把数据目录挂到独立分区或独立盘，系统盘与数据盘的监控告警分开设置。

坑四：按流量计费，月底账单超出机器月租

为什么坑：全节点月度出网常在 1.5–3TB 量级，远超一般 Web 服务器的出网量，按 GB 计费时账单不可控。怎么判断：在机器上统计网卡出网字节数，按当前速率外推整月总量，再乘以单价。怎么避：优先选不限流量方案；若只能按量，先确认单价并设置用量告警阈值，把出网量纳入日常监控。

坑五：按"当前占用"买盘，没给升级和修剪留空间

为什么坑：客户端大版本升级常需要新旧数据目录并行，修剪与快照生成还会产生临时写入，按当前占用刚好买够的盘会在第一次升级时就撑爆。怎么判断：对比当前数据目录大小与盘容量，剩余低于 30% 即为风险区。怎么避：按 2TB 起步、预留 30%–50% 余量下单；监控里加一条"按周增长率外推的触顶日期"告警。

关于全节点资源选型的八个常见疑问

追不上链头一定是磁盘问题吗？怎么确认？

不一定，但磁盘是最常见的原因，也最容易被误判成 CPU 问题。确认顺序可以这样走：先看客户端日志里本地高度与链头的差值是在收敛还是发散——如果发散，说明处理速度低于出块速度。再看磁盘，用 iostat -x 1 观察 %util 是否长期接近 100%、await 是否持续在两位数毫秒；同时看 top 里 iowait 是否偏高而 user 态很低。这三条同时成立基本可以确证。如果不是磁盘，再依次排查对等节点数是否过少（网络层问题）、客户端版本是否落后于当前硬分叉（版本问题）、以及系统时间是否漂移（共识层被网络排斥）。

用云盘行不行？为什么云盘常常不够？

行，但要看是哪一种云盘。云盘的性能模型通常分两层：一个很高的突发 IOPS 峰值，和一个低得多的稳态配额。全节点同步是持续数小时乃至数天的高 IO 任务，突发额度在最初一两个小时就会被耗尽，之后被限制在稳态配额上，而稳态配额往往远低于本地 NVMe 能提供的水平。此外部分云盘的 IOPS 与容量挂钩，容量越小配额越低。如果一定要用云盘，下单前必须确认稳态 IOPS 配额、IOPS 是否随容量提升、以及是否存在每月的 IO 额度上限，并把它与本地 NVMe 的方案做一次工期对比，而不是只看月租差价。

2TB 够用多久？什么时候必须扩到 4TB？

按公开资料给出的增长参考值，Geth 在 snap 同步完成后每周仍增长约 14GB 量级，一年新增量在 700GB 上下。若起始占用落在 1.3–1.5TB，2TB 盘的理论窗口大约一年到一年半，但这是不含余量的算法。实际决策建议以三条线为准：剩余空间低于 25%、计划切换到哈希式归档实现、或需要对外提供不允许中断的 RPC 服务，任意一条成立就应提前扩容到 4TB。需要强调的是，增长速率随链上活动波动，上面是公开资料参考值，实际需结合自身节点实测确认。

归档节点和全节点到底差在哪？我真的需要归档吗？

差别在于是否保留任意历史高度上的完整状态。全节点（尤其是剪枝后）能验证链、能广播交易、能查最新状态，但要查"某个区块高度时这个地址的余额是多少"就无能为力。归档节点保留全部历史状态，因此能对任意高度执行 eth_call。是否需要归档，取决于业务查询是否涉及历史高度。区块浏览器、审计溯源、对账系统通常需要；单纯的钱包广播、DApp 常规读写、交易回执查询通常不需要。如果需要归档，先考虑 Erigon 或 Reth 这类扁平化实现，公开资料给出的量级是 2–3TB，而哈希式实现的归档可达 12TB 以上，两者的硬件成本完全不在一个层级。

初始同步要多久？能不能先加速？

公开资料给出的经验区间是：数据中心级或消费级 TLC NVMe 上，初始同步通常数小时到一天；SATA SSD 明显拉长且余量很小；机械硬盘基本难以完成。能加速的手段有三类：一是换更高 IOPS 与更高主频的硬件，这是最有效的一类；二是使用客户端支持的快照或 checkpoint 同步，跳过从创世块重放的过程；三是调大缓存参数让更多状态留在内存里，属于缓解而非根治。需要注意的是，网络带宽在同步中通常不是主要约束，把带宽从 100Mbps 提到 1Gbps 对总时长的改善远不如换一块好盘。

出网流量一个月大概多少？按流量计费会不会爆？

公开资料给出的常见量级是月度 1.5–3TB，对外提供 RPC 或归档查询的节点会更高。这个量级的成因是节点在 P2P 网络中持续向其他节点提供区块与状态数据，属于协议本身就要求的贡献，不是配置不当导致的浪费。会不会爆取决于单价与配额，需要按实际单价核算，这里不给出具体金额。判断方法很简单：在机器上统计出网字节数，按当前速率外推一个月，再对比套餐包含的流量额度。结论上，这类负载优先选不限流量或高流量配额的方案，按 GB 计费在 1.5–3TB 量级下风险明显偏高。

节点挂了重新同步要多久？怎么减少损失？

如果数据目录完好，重启后通常不需要从零同步，客户端会从最后一个检查点继续追，耗时取决于落后高度与磁盘性能，可能从几十分钟到十几小时不等。真正糟糕的情况是数据目录损坏或盘写满导致的状态不一致，那就只能重新做初始同步，耗时回到前面说的数小时到一天区间，且期间无法提供服务。减少损失的做法有四条：数据盘做定期快照或冷备、监控盘剩余空间并提前扩容、保留上一次完整的客户端数据目录副本、以及把节点做成主备双实例避免单点。系统盘层面的快速回滚能力（例如每日快照与 30 秒回滚）能缩短配置类故障的恢复时间，但状态数据的一致性仍需靠数据盘自身的备份策略保障。

自建和用第三方节点服务，成本怎么比？

自建的成本项包括：存储型服务器的月租（需实时询价，以官网实时报价为准）、出网流量费用、以及运维人力（升级、硬分叉值守、故障响应）。第三方节点服务的成本项是按调用量或按套餐计费的订阅费。比较的转折点在调用量：调用量低时自建的固定成本无法摊薄，第三方明显更划算；调用量高到一定程度，或对数据可自证有硬性合规要求时，自建的固定成本被摊开，且能避开第三方限流与信任问题。另外别忘了把"初始同步期间的不可用时间"和"硬分叉值守"折算成人力成本。具体金额需实时询价，以官网实时报价为准，本文不给出具体价格数字。

再说一句现实的事：一万网络的机器放在深圳南山自营机柜里，标配 5–20G 免费 DDoS 防护与免费备案协助，对长期暴露在公网的 P2P 端口来说这两项不是可有可无的赠品。但防护挡的是流量型攻击，挡不住客户端版本过旧、硬分叉前没演练、盘写满没人看这三类事故——这三件事的代价往往比一次攻击更高，且只能由运行节点的人自己承担。

先把盘选对，再谈 CPU 和内存（公链全节点篇）

回到开头那台 8 核 32G 的机器。它的配置不是不够，是配错了方向。全节点这类状态型负载的瓶颈顺序是确定的：存储容量决定能不能长期跑下去，随机读 IOPS 和持续写入能力决定能不能追上链头，内存决定能在多大程度上缓解 IO 压力，CPU 才是最后一个需要考虑的资源——而且它通常过剩。

如果只能记住一条选型原则，那就是：先定介质（TLC NVMe，避开 QLC 与低 IOPS 云盘），再定容量（2TB 起步、留 30%–50% 余量，归档场景按客户端实现单独评估），然后定流量方案（不限流量优先），最后才回来看 CPU 核数和内存大小。按这个顺序配出来的机器，CPU 大概率还是会闲着——但那正是它该有的样子。

本文参考的公开资料与适用边界（公链全节点篇）

以太坊官方 node 文档（运行全节点的硬件与带宽基线：CPU、内存、存储、网络要求）。

以太坊执行层客户端官方文档（Geth 的 snap 同步与存储增长、Nethermind 对 10k+ IOPS 的建议、Besu 的存储布局、Erigon 的 MDBX 存储方案、Reth 的全节点与归档节点占用参考值）。

以太坊共识层客户端官方文档（Lighthouse、Prysm、Teku、Nimbus 的资源基线，Teku 全节点组合的 4 核 2.8GHz / 16GB / 2TB SSD / 10Mbps+ 参考值）。

行业公开资料与社区实测汇总（不同介质下初始同步时长的经验区间、全节点月度出网流量量级、归档节点容量在不同存储实现下的差异）。

适用边界说明：本文中的容量、IOPS、流量与同步时长均为公开资料参考值，随客户端版本、链上活跃度、同步方式与硬件环境变化，实际数值需结合自身节点与所在机房实测确认；本文不提供任何实测跑分数据，文中涉及的机型价格以官网实时价为准。具体以签约时最新报价与合同为准。