数据管道的六阶段验证：别等最后才发现错误

六道关口，各自的问题#

1
拉取 → 解析 → 清洗 → 计算 → 评分 → 渲染
2
 ↑       ↑      ↑      ↑      ↑      ↑
3
检查点  检查点  检查点  检查点  检查点  检查点

每一关都是独立的出错源。最坑的是相邻两关的偏差会互相掩盖——上游多算了一倍，下游以为那是正确值，一路带到最末端。

核心教训：每阶段都要有验证点#

不要在最后一个阶段才发现数据问题。做法是在管道每一段出口都放一个”检查点”，用断言守住：

• 拉取完 → 断言”条数 >= 0 且与源系统一致”（分页有没有拉全）
• 解析完 → 断言”关键字段全部非空、类型正确”（有没有解析断字段）
• 清洗完 → 断言”过滤后的集合等于预期集合”（过滤条件有没有改错边界）
• 计算完 → 断言”总账与明细账对得上”（有没有重复计算）
• 渲染前 → 断言”数据格式能被前端直接消费”（前端不用自己推导）

每段出口的断言，把”最后才知道错”变成”当场就知道错在哪一段”。

边界场景是最常漏的#

很多管道 bug 不是主流程错，是边界场景没覆盖：

• 空数据（今天一条都没有，不是异常，但要能显示”0”）
• 极值（单条记录异常巨大，不能把均值拉爆）
• 重复数据（同一批被拉了两次，幂等要挡住）
• 口径切换（统计规则变了，历史数据要不要重新算？）

给每个边界场景写一条独立断言，而不是只在”happy path”上验证。

和”缓存失效”是一对#

管道验证守的是”算得对不对”，缓存同步失效守的是”看的是不是新结果”。一个管上游、一个管下游，两者都漏才是”改了完全没反应”。

结论#

数据系统的可靠性不靠”仔细写代码”，靠在管道的每一段出口都放检查点。六个阶段，六道关卡，任何一道先发现问题，你就知道往哪一段回查，而不是把整个管道从头到尾再审一遍。

别等最后一个阶段才发现数据问题——每一段都加验证点。