Data Streams和Data Feeds怎么选？

Data Feeds与Data Streams都提供经过去中心化预言机网络处理的数据，但交付方式不同。Feeds先把聚合值推到链上供多个应用共享；Streams让应用在需要时取得签名报告，并在交易中验证。选择依据是执行模型，不是简单的“新旧版本”。

两条数据路径

Data Feeds路径是：数据源 → 预言机节点聚合 → 达到偏差或心跳条件 → 链上aggregator更新 → 应用从代理读取。价格在链上已经存在，调用者支付普通读取与业务交易成本。

Data Streams路径是：应用向服务请求指定市场报告 → 获得带时间与签名的报告 → 把报告连同业务交易提交 → 链上Verifier验证 → 合约使用报告结算。数据不是持续为所有人推送，而是随使用拉取。

决策维度	Data Feeds	Data Streams
交付模式	链上push	链下取报告、链上验证
延迟目标	适合共享的持续状态	面向更低延迟按需结算
链上读取	代理latestRoundData	验证报告后使用字段
集成依赖	Feed地址与新鲜度检查	API授权、报告schema与Verifier

Streams不是“信任API返回值”

应用取得的报告包含可验证签名和时间字段，目标链合约通过Verifier检查。客户端不能只解析JSON价格后自行传入普通uint；要提交规范编码的报告，并核对feed ID、观察时间、有效窗口和目标Verifier。

Feeds也不是“永久实时”

链上值按更新策略变化。消费者仍需检查updatedAt和业务允许的最大延迟。对于大量协议共同使用的主流价格，链上共享Feed简化了组合；对于低延迟衍生品，等待下一次链上推送可能不满足结算需求。

选择题可以这样回答

若多个合约需要同一公开基准、能接受Feed更新节奏，优先评估Data Feeds；若每次订单需要更细时间粒度，且产品能处理报告请求、验证费用和失败回退，再评估Data Streams。两者也可组合：Streams负责交易结算，Feeds用于风险检查或异常回退，但必须明确切换条件，不能静默用旧值替代。

上线前查询当前支持链、市场、schema和计费计划；缓存报告时不能跨过允许时间窗口；Verifier失败应阻止结算并留下原始报告用于审计。

报告时间字段决定能否用于这笔订单

Streams报告通常不只有价格，还会包含feed ID、观测时间、有效窗口及不同市场字段。合约应把报告与订单的市场、方向和执行时间绑定，拒绝把另一个feed的有效签名报告移作当前订单。报告可被公开传播并不等于可在任意时间重放，Verifier验证通过后仍需执行应用自己的新鲜度与唯一性规则。

压测时要覆盖API超时、Verifier拒绝、链拥堵导致报告过期、计费余额不足和主备服务切换。若配置Feeds作为回退，应公开最大偏差、切换等待时间和恢复条件，避免交易者根据两套价格源之间的差异选择性成交。

Feed字段详解见Chainlink roundData，储备类数据的范围见Proof of Reserve，L2可用性检查见Sequencer Uptime Feed。