先分清账户里有多少，和有多少计入共识权重
ethereum.org的Staking withdrawals页把验证者侧余额处理写成两条并行路径：Legacy验证者（页面所称Type 1）超过32 ETH的超额余额会定期自动转到已绑定的提款地址，且“高于32 ETH的奖励并不增加该验证者在网络上的权重”；Compounding验证者（Type 2）则把奖励复利进有效余额（effective balance），上限到2048 ETH，从而增加权重并可能获得更多奖励，只有超过2048 ETH的部分才会被自动扫出。
同一页还强调：验证者运营者必须提供提款地址后，提款流程才启用；完全退出质押后才会取回剩余余额。把这些句子合在一起，“区块链验证者”场景里至少要分开两本账：链上/账户可见的实际余额变化，以及真正进入共识权重与奖励计算的有效余额边界——旧资料里“固定按32 ETH理解一切”不能无条件套到所有凭证类型。
奖励公式用的是effective_balance，不是随意取整后的展示数
ethereum.org的Proof-of-stake rewards and penalties页写明：每个epoch的奖励从base_reward推演，而base_reward在最优条件下由验证者的effective_balance与全网活跃余额共同决定：base_reward = effective_balance * (base_reward_factor / (base_rewards_per_epoch * sqrt(sum(active_balance))))，其中base_reward_factor为64。页面随后用证明、提议等份额说明实际到手是base_reward的若干比例。
因此，核对“有效余额”时应以该公式的输入字段为准：它直接缩放基础奖励；而withdrawals页对Type 1的说明又指出超额余额可被提走却不抬升权重。两者并不互相替代——一个回答“奖励怎么算”，一个回答“超额余额怎样离开验证者账户”。
客户端视角：凭证类型决定超额会不会自动扫出
Lighthouse Book的Validator Sweep页从客户端运维角度补充：Capella之后，提款凭证为0x00时奖励仍锁在信标链；为0x01时，高于32 ETH的奖励会随“validator sweep”周期性转到提款地址，且该扫表过程自动、不额外收费。Pectra之后，0x02凭证还可通过执行层交易做部分提款，可提至验证者余额不低于32 ETH（文中举例余额40 ETH时可提最多8 ETH）。
写作边界：本文只分类实际余额流向与有效余额/权重用途，不给出质押、并表、提款地址修改或退出排队的操作教程，也不把任一客户端页面写成唯一规范；奖励与罚没的具体数值仍以ethereum.org开发者文档公式与提款页类型说明为准。