这不是一篇「选品秘籍」。这是一份数据质量报告 —— 我把 510 条 1688 公开商品页结构化后，逐字段数了一遍，发现三个字段层面的坑。任何人拿这类数据去算采购成本，如果不先做这三项校验，算出来的数字会是错的。
数据口径先说清楚（可复现）
样本量：510 条商品记录
来源：1688 公开商品页（抓取时间 2026-09-15 ~ 09-16）
结构化字段：类目 / 标题 / 原链 / 价格 / 价格阶梯 / 起订量 / 运费 / 是否包邮 / 销量 / 回头率 / 店铺 / 账期
验证脚本已跑过两次，下面的每一个数字都是直接统计出来的，不是估计值
字段覆盖率（第一个反直觉的地方）
| 字段 | 非空记录数 | 覆盖率 |
|---|---|---|
| 价格 | 510 | 100.0% |
| 运费 | 509 | 99.8% |
| 回头率 | 462 | 90.6% |
| 销量 | 460 | 90.2% |
| 店铺 | 452 | 88.6% |
| 起订量 | 223 | 43.7% |
价格字段几乎永远有值，所以「价格能抓」这件事给人一种数据质量很高的错觉。但真正决定到手成本的运费和真正决定能不能下单的起订量，覆盖率是断崖式下跌的。只抓价格就等于什么都没抓。
坑一：运费字段里 48% 是零值
509 条有运费值的记录里：
freight = 0 的记录：244 条（47.9%）
freight > 0 的记录：265 条（52.1%）
「运费 0」有两个完全不同的含义：一是真包邮，二是「这个字段没取到，被落成 0」。如果把这 244 条当成包邮，那么接近一半的样本会被系统性低估成本。
判定方法：必须拿另一个独立字段交叉验证，不能单看运费这一个数字。
坑二：包邮标记与运费金额自相矛盾 259 条
用「是否包邮」字段与运费金额做交叉验证，结果比预期更糟：
两个字段都有值的记录：509 条
标记为「包邮」却同时有 freight > 0 的记录：259 条（50.9%）
一半的记录，两个字段互相打脸。
这不是某一家店铺标错了，而是这个量级的普遍矛盾。结论只有一个：这类数据里，任何单一字段都不能当作事实使用，必须成对校验，冲突时以「更保守的那个」为准算成本。
坑三：moq 不等于起订量
这是最容易被误用的一条。
「moq」字段（223 条有值）与价格阶梯的第一档下限（首个 lo）做逐条比对：
可比较记录：223 条
两者不一致：119 条（53.4%）
超过一半的记录，moq 字段与真正的首档起订量不是同一个数。
解释：moq 字段在这类页面上通常代表「能拿到某个价所需的件数」，而首档 lo 才是「最少下多少单」。两者的语义不同，直接用 moq 当起订量会让人算错「第一次到底要压多少钱进货」。
正确做法是两套数字并排保留，标注各自含义，不要让它们互相替换。
价格分布（作为参照系）
对 510 条的价格下限做分位统计：
最小 0.06
25 分位 6.50
中位数 19.50
75 分位 42.00
最大 11,050.00
中位数 19.5 而最大值 11,050 —— 单看均值会被极端值带偏。这类数据的分位统计比均值可信得多。
小结：三条校验规则
运费零值不等于包邮：零值要单独标记为「未取到」，不要落成 0
包邮标记与运费金额必须成对校验：冲突率在本次样本里超过一半
moq 与首档起订量必须并排保留：53.4% 的记录两者不同
这三条不解决任何商业判断问题，但能让基于这类数据的成本测算不再系统性偏乐观。
关于数据
以上统计基于一份 510 条的真实抓取样本，对应的可浏览样本页在这里（公开、免费、无需注册）：
https://1688-price-sample-v2.app.workbuddy.host/
页面上的数据与本文口径一致，可以自行核对。
声明：本文数据来自 1688 公开商品页的批量抓取与结构化，仅用于数据分析与字段可靠性讨论，不构成任何采购、投资或经营建议。商品价格与库存随时变动，如需下单请以平台页面的实时信息为准。