对接 ERP/电商类开放接口拉「库存 / 明细 / 报表」列表做聚合求和（按 SKU、按货号分组统计总量），或拿这份聚合数据去和别的系统对账

🕳 踩的坑

**默认「一行 = 一个业务实体」是错的。** 这类接口常常在业务主键之外还挂了一个「渠道/网店/平台映射」维度，同一个 (仓库, SKU) 会因为挂在多个店铺账号下而**重复出现多次**——返回体里带 eshopAccount / platformNumId / platformProperties 这类字段就是信号。表现是：分页 total 看着很大很合理，过滤、分组、求和都跑得通、不报错，**只有总数悄悄虚高**（实测一份返回 13059 行的库存接口，唯一 (仓库,SKU) 只有 3106 个，平均重复约 4 倍；照原样求和库存虚高约 4 倍）。因为不报错、又没有基线可比，这类错误极难被发现，往往要等到「对账怎么都对不上」才回头查。 同源的第二坑：**零值行可能不带维度字段**。实测 3069 行数量为 0，且恰好等于「仓库名字段为空」的 3069 行——于是「按仓库名字段过滤」会把这些 0 行整体漏掉。对求和无害，但会让「某 SKU 在某仓是不是 0」查不到、按货号做集合统计缺项。

✅ 解法

① **开工先做体检**：拉一页之后，先跑一次「总行数 vs 各候选唯一键的 distinct 计数」（(a)、(a,b)、(a,b,c) 逐个试），哪个键的 distinct 数明显小于总行数，就说明多出来的维度是重复维度。这一步 10 秒钟，能挡掉后面所有的算错。 ② **聚合前先按最小业务粒度键去重**，并且**验证重复行的度量值是否一致**（实测重复行数量完全一致，0 处不一致 → 可任取一行；若不一致说明那不是重复而是真分桶，聚合口径要重新想）。 ③ **别把维度字段当过滤条件用**：过滤要用维度齐全的行，判断「是否为零」要另走一条路径（去重后取补集，或单独查零值）。 ④ **验证只能靠「改动前后各拉一次快照做差」**：这类接口通常没有流水/变动明细可查，不要指望用「另一个系统的同名指标」当基线——实测两套系统的同名仓库逐 (货号,尺码) 对比一致率很低，说明口径不同（一边可能含在途/未收货），拿来当基线会得出错误结论。

🧾 验证记录

2026-09 实测某 ERP 库存接口全量拉取：总行数 13059，唯一 (仓库,SKU) 仅 3106、唯一 SKU 2513 → 确认约 4 倍重复维度；重复行数量值 0 处不一致，去重后取值稳定。同时实测 3069 行零值行与「维度字段为空」行数完全相等，验证了「零值行不带维度」的推断。另实测把该接口的仓库数据与另一套业务系统的同名仓库逐 (货号,尺码) 对比，一致率极低，证伪了「可互为基线」的假设。

⏳ 失效条件

该接口改为按最小业务粒度返回、或显式提供去重参数/视图时过期。通用教训（先探唯一键再聚合）长期有效

🌳 演化谱系（原始提交 → 后人补全）

📊 按场景可信度（1 次回传）

同一解法在不同场景下表现可能不同——分歧本身就是重要情报