电商数据抓取最危险的失败，不是任务报错，而是任务显示“成功”后，把错误、重复、过期和口径不一致的数据悄悄写进了正式存储。增长负责人经常在周报里看到商品数上涨、库存突然归零、销售额与平台后台对不上，最后才发现：真正的问题不是报表公式，而是入库前没有把“缺失、重复、异常和历史变化”区分开。
我处理这类数据链路时，最先看的通常不是抓取工具，而是三件事：一条记录能不能被唯一识别，一次抓取能不能被完整追溯，一条异常数据能不能在进入正式分析表前被隔离。只要其中一项缺失，数据量越大，后续存储越容易从“有瑕疵”变成“不可解释”。
电商数据抓取至少包含采集、解析、标准化、校验、写入、更新和分析几个环节。接口返回 HTTP 200，或者任务日志显示“完成”，只能说明某个技术步骤执行完毕，并不能说明数据具备业务可用性。
例如，接口可能返回了一个登录失效页面，但解析器仍然提取出“商品名称”和“更新时间”；商品详情页可能因为页面改版，只抓到了价格，却没有抓到 SKU；任务重试可能把同一批数据写入两次。数据库只负责保存它收到的内容，并不会自动判断这些内容是否可信。
我对这类问题的判断是：存储层出现混乱，往往是上游质量问题被延迟暴露，而不是数据库突然失控。
同一个字段出现不同含义，比字段完全缺失更难处理。库存为 0，可能表示商品确实无货，也可能表示接口没有返回库存；价格为 0，可能是免费商品，也可能是解析失败后的默认值；订单金额为空，可能是订单未完成，也可能是字段转换错误。
如果系统没有把这些状态区分开，后续的 SQL、报表和可视化工具就会把不同含义当成同一种数值处理。结果是，增长团队看到的不是“数据异常”，而是一份看起来完整、实际无法解释的经营报表。
有些团队建立校验规则时只有一个动作：异常就拒绝入库。这种方式看似严格，却可能让一条有 90% 字段可用的数据直接消失，也可能因为一个临时字段缺失导致整批数据断流。
更稳妥的做法是把异常分为阻断、隔离、告警放行和自动修复四类。主键缺失、来源不明、结构完全改变，通常应该阻断；价格字段格式不统一，可能适合自动转换；部分非核心字段缺失，则可以先隔离或告警放行。
在电商数据中，“商品”不是一个足够精确的身份。平台商品 ID、店铺商品 ID、SPU、SKU、活动商品 ID，可能分别代表不同层级。一个商品有多个规格时，商品详情页的 ID 可能相同，但 SKU、价格和库存不同。
我见过一种典型错误：技术团队用商品详情页 URL 作为唯一键，后来平台在活动页、搜索页和店铺页返回了不同 URL。同一商品因此被保存成三条记录。数据库里的自增 ID 都不重复，开发人员检查主键时也没有报错，但业务上已经发生了重复统计。
所以，数据库的自增主键只能回答“这是第几条存储记录”，不能回答“这是不是同一个业务对象”。后者必须依赖平台、店铺、商品 ID、SKU 或其他业务字段组合判断。
增长负责人经常问“昨天的数据为什么变了”，但技术团队需要先确认“昨天”指的是什么时间。抓取时间是系统发起采集的时间，业务时间可能是订单创建时间，平台更新时间是源站记录发生变化的时间，入库时间则是数据写入存储的时间。
如果只保留一个 created_at 字段，后续很难判断数据到底是昨天产生的、昨天抓到的，还是昨天写入的。跨时区平台、夜间任务和延迟接口尤其容易把当天数据写入前一天的日报。
真正难查的不是一眼就能看出的乱码，而是结构上合法、业务上错误的数据。比如接口返回空数组，程序将其识别为“当前没有商品”；接口返回促销价字段为空，程序用原价填充；库存接口超时，程序把空值转成 0。
这类数据能够正常写入数据库，也能正常被 BI 工具读取，因此在技术日志中往往没有明显错误。直到运营人员发现商品数量骤降、库存曲线断崖式变化，问题才被发现。
下面是一组示意数据，用来说明同一个 SKU 如何在没有质量校验的情况下形成存储混乱。它不是某个平台的公开数据，而是按照常见电商字段结构构造的排查样本。
| 平台 | 店铺 | 商品 ID | SKU | 价格 | 库存 | 抓取时间 | 批次 |
|---|---|---|---|---|---|---|---|
| 平台A | 旗舰店甲 | 10086 | 10086-黑色-M | 199.00 | 35 | 2026-09-12 09:00 | B001 |
| 平台A | 旗舰店甲 | 10086 | 10086-黑色-M | 199 | 35 | 2026-09-12 09:03 | B001 |
| 平台A | 旗舰店甲 | 10086 | 10086-黑色-M | 199.00 | 0 | 2026-09-12 10:00 | B002 |
| 平台A | 旗舰店甲 | 10086 | 10086-黑色-M | 199.00 | 35 | 空 | B003 |
这四条记录表面上都能被数据库接受，但至少存在四个问题：同批次重复写入、价格类型可能不一致、库存 0 的含义不明、第三条记录缺少抓取时间。若增长团队直接按记录数统计商品或按最新写入时间取值，最终结果会出现不同程度的偏差。
任务完成只代表程序没有在运行层面崩溃。它不代表本次抓取量符合历史范围，也不代表每个关键字段都有值，更不代表源站返回的结构没有发生变化。
我建议至少做批次级校验：记录总量是否较过去七天均值异常下降，关键字段空值率是否突然上升，商品 ID 的去重率是否发生变化，价格和库存的分布是否出现极端值。如果批次记录数从 100 万降到 20 万，程序却仍然显示成功，这恰恰是最需要告警的情况。
自增 ID 只能保证每次 INSERT 生成一个不同的编号。如果同一个 SKU 被插入十次，系统会得到十个不同的自增 ID，但业务重复率仍然是 90%。
真正需要设计的是幂等键。例如，库存快照可以考虑使用“平台 + 店铺 + SKU + 抓取时间粒度”，商品主数据则可能使用“平台 + 店铺 + 商品 ID + SKU”。不同对象的唯一键不应机械复用，订单、商品、价格快照和库存快照的生命周期并不相同。
把空值转为 0，确实可以减少报表中的空白，但它同时抹去了数据状态。对库存来说，0 是一个明确的业务事实；空值则可能表示没有抓到、接口未返回、字段不适用或尚未同步。
在存储层，建议保留原始空值，并增加状态字段，例如 inventory_value、inventory_status、inventory_checked_at。分析层再根据业务场景决定是否将某种状态排除、估算或展示为 0。
只保留最新商品价格和库存，短期看确实省空间，但它会牺牲问题追溯能力。增长团队后续会问：价格是什么时候下降的？投放调整前库存是多少？促销期间的异常是源站问题还是抓取延迟？没有历史快照，就无法回答。
我通常会把数据分成当前状态和历史快照两层。当前状态服务于快速查询，历史快照服务于趋势分析和问题回放。两层都不必无限保存，可以依据经营价值设计保留周期。
如果每天有数百万条记录，把所有异常交给人工处理，系统很快会形成新的积压。人工审核应当用于高价值、低频、需要业务判断的异常，而不是承担格式清洗和重复去除。
日期格式、货币单位、文本空格、状态枚举等问题适合自动修复；主键缺失、金额异常、来源不明等问题适合隔离；只有涉及业务语义判断的记录，才值得进入人工复核队列。
所有质量判断都应先从身份开始。没有稳定身份，后面的去重、更新、历史追踪和跨表关联都没有基础。
我会先画出对象层级：平台、店铺、商品、SKU、订单和活动。然后逐个回答三个问题：这个对象的业务主键是什么？这个主键在哪个范围内唯一？平台编码变化时，是否有内部统一 ID？
| 对象 | 常见业务身份 | 不能直接替代的字段 | 主要风险 |
|---|---|---|---|
| 店铺 | 平台 + 店铺 ID | 店铺名称 | 改名后被识别成新店或覆盖旧店 |
| 商品 | 平台 + 店铺 + 商品 ID | 商品标题、商品 URL | 标题修改或链接变化造成重复 |
| SKU | 商品 ID + SKU ID 或规格组合 | 规格文本 | 规格顺序、语言和空格变化造成重复 |
| 订单 | 平台 + 店铺 + 订单号 | 支付时间、买家昵称 | 重复抓取或订单状态更新写错记录 |
身份稳定后，才需要判断记录是有效、缺失、延迟、取消、下架还是异常。很多系统只保存一个业务数值，却没有保存状态，导致后续无法区分“没有值”和“值为零”。
以订单金额为例，至少要区分已支付、待支付、已取消、已退款和接口未返回。以商品库存为例，也要区分有货、无货、预售、不可见和抓取失败。状态字段不是额外装饰，而是业务数据能够被正确解释的条件。
只有身份和状态确定后，数值范围校验才有意义。价格不能为负数是基础规则，但“价格为 0”并不一定错误；库存不能为负数也很常见，但预售商品可能使用特殊库存编码。
因此，范围规则不能只写成一个固定数字，而要绑定对象、状态和平台口径。例如，普通实物 SKU 的库存可以要求大于等于 0，预售商品则应使用独立状态，不把特殊编码直接写入库存数值。
越靠近源数据的地方，越容易保留上下文；越靠近报表的地方，越容易发现业务影响。比较成熟的链路不是只做一次校验，而是在三个位置分别承担不同职责。
下面案例采用九数云作为分析看板场景，数据为情景模拟，用于说明如何把抓取、存储和分析问题串起来。假设一个团队每天抓取多个平台的商品、价格、库存和销量数据，并将结果汇总到分析看板中。
某周一，团队发现商品总数比上周五增加 18%，但总销量只增加 1.5%，广告投放没有明显变化。运营人员第一反应是平台上新加速，增长负责人则需要判断：商品真的增加了吗，还是同一批商品被重复写入？
在九数云中，可以先按平台、店铺、商品 ID 和 SKU 展开明细，再把记录数、去重后的业务对象数、批次数和最近更新时间放到同一分析视图里。这样做的价值不在于“做出一张漂亮图表”，而在于把总量指标拆成可追溯的组成部分。
排查结果显示，原始记录数增长 18%，去重后的商品数只增长 2.1%。进一步按抓取批次分组后，发现周一早上的任务有两次重试，第二次重试没有使用幂等写入，导致同一批商品被再次写入。
这类问题如果只看商品总量，很容易被误判为业务增长。更稳妥的看板设计应该同时展示原始记录数、业务对象数、重复记录数和重复率，并支持下钻到具体批次和 SKU。
重复商品记录会放大商品数，但不会自然增加订单或销量。如果销量指标按订单号去重，而商品指标没有去重，两个指标的增长曲线就会产生结构性背离。
这不是报表平台“算错了”，而是两个指标使用了不同粒度。商品数按记录统计，销量按订单统计，二者被放在同一张趋势图中比较，业务人员却误以为它们处在同一统计口径下。
如果看板只能展示最终数值，不能回到批次、来源和原始记录，增长负责人只能看到“结果不对”，却无法判断是采集、转换、入库还是口径问题。
下面的代码用于示意批次内的重复检查。实际字段和数据库语法应根据系统调整，不能直接当作所有环境的通用脚本。
SELECT platform, shop_id, sku_id, capture_batch, COUNT(*) AS record_count, MIN(ingested_at) AS first_ingested_at, MAX(ingested_at) AS last_ingested_at FROM product_snapshot GROUP BY platform, shop_id, sku_id, capture_batch HAVING COUNT(*) > 1 ORDER BY record_count DESC;
这类查询只能发现重复现象，不能自动判断哪一条是正确记录。后续还需要结合抓取时间、原始响应、处理版本和更新策略，判断是重复重试、平台重复返回，还是业务上确实存在多个快照。
常见原因包括没有业务唯一键、重试不幂等、分页游标重复、不同采集入口使用不同编码，以及平台商品链接变化。修复时不要只做全表去重，因为简单保留一条记录可能误删真实的历史快照。
更合理的方式是先明确表的用途。主数据表应保证当前对象唯一，快照表可以允许同一 SKU 在不同时间存在多条记录，但同一 SKU、同一批次、同一抓取时间粒度不应重复。
建议在原始层保留原值，在标准化层增加状态，在分析层根据指标规则处理。库存、销量、价格和订单金额都不应采用“一律空值转 0”的简单策略。
价格字段可能同时出现数字、带货币符号的文本和空字符串；日期字段可能混合斜杠、短横线、时间戳和本地化文本。字段类型冲突会导致排序、求和、连接和分组产生隐蔽错误。
标准化时应记录转换是否成功。不能把无法转换的内容直接替换成 0 或空值，否则转换失败会被伪装成正常数据。
如果只保留当前价格，就无法分析价格变化；如果库存表使用商品 ID 直接更新，就无法判断某次下降是真实销售还是抓取错误。对于价格、库存、上下架状态等变化频繁的字段，至少应保留带时间和批次的历史快照。
平台销售额可能分别包含或不包含优惠、运费、税费和退款。库存可能是可售库存、总库存或活动库存。相同字段名不代表相同业务含义，跨平台汇总前必须建立口径映射。
跨日任务和不同平台时区是常见来源。建议明确保存 source_event_time、captured_at、ingested_at 三类时间，并在分析层声明日报使用哪一个时间字段。
接口返回登录页、验证码页、限流提示或错误 JSON 时，解析器可能仍然写入部分字段。应在采集后增加响应类型校验，例如检查状态码、内容类型、关键字段结构和响应体特征。
没有来源和批次，问题就无法追溯。建议至少保留 source_platform、source_shop、capture_task、capture_batch、parser_version、captured_at 和 ingested_at。若涉及高价值数据，还应保留原始响应的定位信息或对象存储地址。
如果每天只有几万到几十万条记录，第一阶段不必急着引入复杂的数据质量平台。更重要的是完成最小闭环：原始数据可保留、批次可识别、业务主键已定义、异常可查询、报表口径有说明。
建议先建立三张逻辑表：原始采集表、标准化明细表和业务分析表。原始表尽量少改动，标准化表负责类型和单位统一，分析表负责指标计算。即使物理上暂时使用同一个数据库，也要在逻辑上分层。
当平台数量增加后，最大的风险不再只是重复，而是同名字段代表不同含义。此时应建立平台字段字典，明确商品、SKU、订单、金额、库存、退款和时间的统一定义。
跨平台汇总前，至少要回答：销售额是否含退款？库存是可售还是总量？订单按创建、支付还是完成统计？商品 ID 是否在店铺范围内唯一？没有这些定义，任何跨平台看板都只能提供“看起来统一”的数字。
高频抓取场景最容易发生重复写入和部分成功。建议每次任务生成唯一批次号，记录任务开始时间、结束时间、源平台、参数、处理版本和结果统计。
写入时采用明确的幂等策略：相同业务键和相同快照时间是更新、忽略还是进入冲突表，必须提前定义。不要让数据库的默认行为替代业务规则。
实时库存或价格场景不适合因为一个非核心字段缺失就让整条链路停摆。但允许放行必须有边界，例如仅允许非核心字段缺失，核心数值异常仍然进入隔离区，并触发负责人告警。
放行的数据不能伪装成完全正常。可以增加 quality_status、quality_score 或 validation_message，让下游知道这条数据是否经过完整校验。
如果数据会影响结算、预算分配、库存采购或大额投放，就不应只依赖“告警后放行”。主键缺失、金额异常、订单状态未知和时间不一致，应尽可能阻断或隔离，并要求人工确认。
此类场景可以接受更高延迟，换取更强的可追溯性。增长负责人需要明确：实时但不可信的数据，往往比延迟十分钟但可解释的数据更危险。
| 方案 | 优势 | 短板 | 适用场景 |
|---|---|---|---|
| 只保留最新状态 | 存储成本低，查询简单 | 无法回放变化，难以定位历史错误 | 只关心当前商品目录的小型场景 |
| 保留全部快照 | 趋势分析和问题追溯能力强 | 成本、分区和清理策略更复杂 | 价格、库存和竞品监测 |
| 冷热分层保存 | 兼顾查询速度和历史保留 | 需要设计归档和访问规则 | 数据量较大且需要长期复盘的团队 |
直接阻断适合高风险字段和关键业务，但可能造成数据断流；隔离适合部分可用的数据，但需要下游明确排除隔离记录；告警放行可以保持时效，却必须承受数据不完整的风险。
我的建议是采用“字段级风险”而不是“整条记录一刀切”。主键、平台、批次和时间属于身份与追溯字段，异常时优先阻断；商品描述、图片地址等非核心字段，可以根据业务需要隔离或放行。
自动修复适合规则明确、风险可控的问题，例如去除文本空格、统一日期格式、转换货币单位。人工审核适合价格异常、订单状态冲突、商品身份无法匹配等需要业务判断的问题。
自动修复必须保留修复前后的值和规则版本。否则某次规则调整造成数据变化时，团队只能看到结果发生了变化，却不知道是谁改了什么。
不一定。先比较原始记录数、去重后的业务对象数和有效批次数。如果原始记录涨幅远高于去重对象涨幅，优先检查重复写入、分页重复和任务重试。
不能直接删除。先判断这些记录属于重复主数据、不同时间的历史快照，还是同一批次的重复写入。删除前应保留备份，并记录删除规则，否则可能把真实的价格或库存变化误删。
需要区分真实无货和抓取失败。检查原始响应、库存字段空值率、接口状态、最近一次成功抓取时间和平台页面值。如果系统把空字符串、超时和字段缺失统一转成 0，问题通常发生在标准化环节。
规则实现是技术工作，但规则含义必须由业务共同确认。哪些字段是必填，哪些异常可以放行，销售额是否包含退款，库存采用什么口径，这些都不是数据库能够自动决定的。
通常有必要。原始数据是定位解析错误、平台结构变化和转换问题的重要证据。小团队可以设置较短的保留周期，不必永久保存，但不建议一开始就只留下清洗后的结果。
分析工具可以帮助发现重复、空值、趋势突变和口径差异，也可以通过明细下钻提升排查效率，但它不能替代业务主键设计、幂等写入和原始数据保留。工具能把问题看得更清楚，不能替团队定义数据含义。
电商数据抓取的真正分水岭，不是每天能抓多少条，而是团队能否解释每一条关键数据。它来自哪个平台、哪个店铺、哪一次任务？是在什么时候抓到的？经过了哪些转换？为什么被写入当前表？如果出现异常，能否回到原始响应并恢复当时的业务状态？
我建议增长负责人不要从“还要接入多少平台”开始规划下一阶段，而是先做一次存储体检：随机抽样、批次对比、重复检查、空值检查、时间检查和口径核对。哪怕只抽查 100 条记录，也常常能发现整条链路中最关键的薄弱点。
最值得记住的判断是：数据量扩大，会放大质量问题；数据分层、业务主键、批次追溯和异常分级，才会放大数据价值。当团队能够区分真实的零、未知的空、重复的记录、不同时间的快照和不同平台的口径时，抓取数据才真正具备支持选品、投放、库存和增长复盘的基础。
下一步可以从一张表开始：列出所有核心字段，写清楚字段含义、是否必填、允许的取值范围、异常处理方式、来源和负责人。先把这张表变成可执行的校验规则，再把规则接入采集、入库和分析环节。这样做不复杂，却能避免最昂贵的错误，让一份看似完整的数据，误导整个增长团队。
我刚接手一个多平台商品数据项目，抓取任务显示成功，但数据库里的商品数量每天都在增加，报表却和平台后台对不上。我想知道，这到底是抓取重复、主键设计错误，还是清洗和入库环节出了问题？
我在一次实际排查中遇到过类似情况：一个商品在数据库里看似有 3 条记录，实际上是同一 SKU 在不同抓取批次被重复写入。系统使用了自增 ID 作为主键，却没有建立“平台、店铺、商品 ID、SKU”这组业务唯一标识，因此每次重试都会生成新记录。
最常见的存储混乱主要有五类：同一商品重复入库，历史价格和库存被覆盖，空值与 0 值混用，日期和金额字段类型不统一，以及不同平台的商品编码直接混在一起。它们的共同点是：数据库看起来有数据，但数据之间无法稳定关联。
存储症状常见根因直接后果 SKU 数量异常增加缺少业务唯一键或重试不幂等销量、商品数被重复统计 昨天的价格消失只保留当前值，更新时覆盖历史无法复盘价格变化 库存突然变成 0抓取失败被写成默认值 0误判缺货并错误补货 金额无法聚合数字和文本混存，单位不一致报表计算失败或结果偏差 增长负责人不必先看代码，可以先抽查同一 SKU 在连续三个批次中的记录。
如果商品标识、抓取时间、来源平台和批次号无法同时还原，就说明问题已经不只是“抓取少了几条”，而是存储模型缺少可追溯性。
我曾经看到库存报表里大量商品库存变成 0，运营团队马上准备下调投放预算，后来才发现其中一部分只是接口超时，没有真正返回库存。我想知道，入库时应该如何区分空值、0 值和抓取失败？
空值和 0 值在电商场景里不是同一个意思。0 通常表示系统确认商品没有库存、没有销量或金额确实为零；空值则可能表示未知、未返回、字段缺失或尚未完成同步。如果把所有异常都转成 0，报表会把“没有得到答案”伪装成“答案就是零”。我建议至少保留三个状态字段：业务值、数据状态和异常原因。
例如库存字段可以是 NULL，数据状态标记为 missing，异常原因记录为 timeout；只有平台明确返回库存为 0 时，才把业务值写成 0，状态标记为 valid。
原始情况业务值状态是否进入正式指标 平台明确返回库存 00valid可以 接口超时NULLfailed不应按 0 统计 字段未返回NULLmissing不应按 0 统计 库存字段为负数原始值保留invalid进入隔离区 一个实用判断方法是比较“库存为 0 的比例”和“抓取失败率”是否同时上升。
如果某天库存为 0 的商品比例从 8% 突然升到 41%，而接口响应时间也明显变长，优先怀疑采集链路，而不是全站商品同时售罄。对增长团队而言，最危险的不是出现空值，而是空值被悄悄转换成可参与计算的 0。前者会触发告警，后者可能让投放、补货和选品团队基于错误数据做出看似合理的决定。
我们的表里保存了商品价格、库存和销量，但技术同事无法回答某条数据来自哪个平台、哪次任务，甚至不知道它是否经过人工修正。我想知道，增长负责人至少应该要求存储系统保留哪些追溯信息？
没有来源和批次信息时，数据问题会从“可以修复的异常”变成“无法证明的争议”。例如报表显示某商品昨天价格下降 30%，团队需要知道这是平台真实变价、解析错误、人工修改，还是另一家店铺的数据被误写进来；如果记录里只有商品 ID 和当前价格，基本无法判断。
在我参与的一次数据回溯中，团队花了近一天比对三个系统，最后发现不是报表算法错，而是两个平台使用了相同的外部商品编码。由于表中没有 source_platform 和 shop_id，跨平台合并时把两条不同商品当成了同一条记录。建议至少保留以下字段： source_platform：来源平台；
shop_id：店铺或商家标识；crawl_batch_id：抓取批次号；crawled_at：实际抓取时间；ingested_at：写入存储时间；parser_version：解析规则版本；raw_record_id：原始记录定位信息；data_status：有效、缺失、异常或隔离状态。
这几个字段的价值不在于让表看起来更专业，而在于支持三类动作：按批次重放、按来源定位、按版本解释变化。尤其是 crawled_at 和 ingested_at 必须分开，因为任务延迟时，入库时间并不代表业务数据产生的时间。
如果当前系统还没有这些字段，可以先做一个低成本改造：不急着重建全部历史表，先在新批次中补齐来源、批次、抓取时间和处理版本，并保留一小部分原始响应作为回溯样本。能先回答“这条数据从哪里来、何时来、经过什么处理”，比盲目增加采集规模更重要。
我们最初的做法是发现字段缺失就整批任务失败，结果一个商品字段异常，几万条正常数据也无法更新。后来又改成全部放行，数据库里出现了很多脏数据。我想知道，阻断、隔离、告警和自动修复应该如何选择？
一律拦截和一律放行都不是成熟方案。前者容易造成数据断流，后者会让异常扩散到正式表；更合理的做法是按异常对业务的破坏程度分级，而不是按技术团队是否方便处理来决定。
处理方式适用异常示例 阻断无法确认记录身份或来源商品主键为空、接口返回整页错误信息 隔离主体可识别，但部分字段不可信SKU 有效但价格为负数 告警后放行低风险、短时波动单批次记录量下降 5% 自动修复规则明确且不会改变业务含义日期格式统一、金额单位换算 我通常先看三个指标：异常字段是否影响主键，是否会直接进入核心指标，是否能在后续补全。
如果主键缺失，记录无法可靠关联，应阻断；如果只是价格暂缺，但商品和批次都明确，可以进入隔离区等待补采；如果只是日期格式不同，则可以自动标准化。还要特别防止“整批失败”的粗暴策略。一次任务有 100,000 条记录，其中 200 条价格异常，不应让 99,800 条正常记录全部无法入库。
更好的设计是把正常记录写入正式表，异常记录写入隔离表，同时保留本批次的异常率和失败原因。最终要建立的不是一个追求零异常的系统，而是一个能让异常被看见、被分类、被回放的系统。增长负责人可以要求技术团队明确四个问题：什么情况必须停、什么情况暂存、什么情况只告警、什么情况允许自动修复。
只要处理边界清楚，数据规模扩大后也不容易失控。
读者评论
文章把“抓取成功”和“数据可用”区分得很清楚，尤其是空值被转成库存 0 的例子，确实容易制造虚假波动。实际落地时还需要结合业务设定告警阈值。
用自增 ID 解决重复数据的误区很典型。平台、店铺、商品和 SKU 的身份层级不同，唯一键应按数据对象设计，这对后续去重和历史追踪都很重要。
保留当前状态和历史快照两层的做法比较实用，既能支持日常查询，也方便回溯价格和库存变化。不过历史数据的保存周期和成本仍需提前规划。
文章提出将异常分为阻断、隔离、告警放行和自动修复，避免了“一有问题就拒绝入库”的简单做法。批次量、空值率和去重率等指标也适合纳入日常监控。