先明确要核验的对象
币圈做策略时，资料来源通常包括交易所公开行情、交易接口返回的数据、公告页面、产品规则、第三方数据平台以及策略作者提供的截图或报告。核验前应先写清楚资料要支持什么结论，例如交易对是否存在、某段时间的成交量如何、接口是否返回历史K线，或某项规则是否适用于指定账户类型。问题越具体，越容易判断证据是否足够。
资料核验至少要区分四个层面：来源是谁，数据通过什么地址取得，传输内容是否完整，数据是否适合当前策略。一个使用HTTPS的网址只能说明通信使用了相应的安全传输机制，不能单独证明页面内容、运营主体或数字本身一定正确。
核验网址、接口和响应信息
HTTP是一种请求与响应协议。客户端提出请求，服务器返回响应，响应中通常包含状态码、内容类型、缓存控制、时间等元数据。核验交易所资料时，应记录完整域名、接口路径、请求参数、取得时间、响应状态以及返回内容的格式，避免只保存一张无法追溯的截图。
首先检查域名是否属于交易所官方使用范围，接口文档中的主域名和实际请求地址是否一致，是否存在拼写近似、非官方镜像或多次跳转。随后核对响应状态与内容类型：成功状态并不代表业务数据正确，返回的错误页面、登录页面或限流提示也可能被程序误当成行情数据。策略程序还应检查字段名称、时间单位、数量单位和空值处理方式。
HTTP语义强调客户端要根据响应状态和内容决定后续行为。对应到资料核验，程序遇到异常状态、字段变化、权限错误或格式不符时，应停止写入数据或标记为待复核，而不是继续把结果加入回测样本。缓存、代理和中间服务也可能影响内容的新旧程度，因此需要关注响应中的时间及缓存相关信息，并与文档说明进行比对。
用来源角色检查可信关系
可验证凭证模型把参与者分为发布者、持有者和验证者，并强调“凭证可以被验证”不等于其中声明必然真实。这个区分适合用于交易所资料：官方接口或公告可以被视为资料发布渠道，策略作者是资料持有和整理者，使用者则是验证者。验证来源身份后，仍要独立检查数据范围、生成规则和业务含义。
因此，不能因为某份报告标注了交易所名称、带有数字签名或来自看似正规的平台，就直接接受其中所有结论。应核对发布主体、原始链接、取得时间、数据字段、计算方法和适用条件。若报告只给出收益曲线，却没有原始行情、手续费假设、滑点处理和样本区间，使用者无法据此复核策略结论。
同一事实最好由相互独立的证据交叉核对。例如把交易所接口返回的交易对信息与官方规则页面比对，再检查历史数据中的时间连续性和关键字段。第三方数据可以用于发现异常或补充背景，但涉及策略输入的核心数值，应尽量追溯到能够复查的原始渠道。
策略数据的实用核验流程
适用的基础流程可以分为五步。第一步，固定数据定义，明确现货还是合约、交易对、时间周期、价格类型、成交量口径和时区。第二步，保存来源地址、请求参数、响应原文摘要及取得时间。第三步，检查接口身份、状态码、内容类型和字段结构。第四步，把关键记录与另一独立渠道或官方说明进行抽样比对。第五步，记录异常、缺失、修订和无法确认的部分，并在回测或分析中标注数据版本。
核验时还应注意时间顺序。实时数据、延迟数据和历史修订数据的用途不同；取得时间晚于信号生成时间的数据，不能被倒填进过去的策略判断。对于K线，应确认开盘、最高、最低、收盘和成交量的定义，以及未完成K线是否会变化。对于公告或规则，应保存页面标题、发布日期信息和原文位置，避免把搜索摘要或转述当成完整依据。
这些步骤用于提高资料可追溯性和技术判断质量，不代表任何策略一定有效，也不能推出未来表现。使用者仍需根据自身合规要求、平台规则和数据授权范围决定是否采用。
常见问题
问：HTTPS是否足以证明交易所资料可靠？答：不足。HTTPS主要解决通信过程中的加密和身份校验问题，仍需核对域名归属、发布主体、数据定义和内容完整性。
问：有数字签名或可验证凭证的数据是否一定真实？答：不一定。可验证性主要说明签名、格式或发布关系可以被检查，数据所声明的事实仍需结合发布者、时间、范围和业务规则判断。
问：多个网站显示相同数字，是否就能确认？答：不能简单确认，因为多个网站可能复制同一原始错误或使用同一数据供应商。应优先寻找独立取得路径，并比较取得时间、字段定义和计算口径。
问：发现接口返回成功但数据为空怎么办？答：先检查请求参数、权限、交易对、时间范围、分页和限流状态，再查看响应结构。无法解释前，应将该批数据标为异常，避免直接用于策略回测或自动化决策。