商品采集被 DataDome 验证打断：用穿云API衔接列表与详情页读取

商品列表上出现了新款，详情采集却返回 DataDome 验证页。如果程序把这次空结果当成“缺货”，业务端就会收到错误告警。对于获准的商品监控，访问失败不应该改变商品事实；它只说明这一轮没有得到可以验证的新观察。

这里讨论的是一种设计场景，不是真实客户成绩报告。目标是让列表到详情的每个环节都有清晰输出，再把穿云API支持的 DataDome 验证处理放进需要它的访问步骤，而不是整条链路都换成黑盒。

列表发现与详情采集不要绑成一个结果

列表阶段记录稳定商品 ID、规范化详情 URL 和发现时间。详情任务用该 ID 去重，避免同一商品从多个分页入口重复进入队列。去除跟踪参数时，保留会改变商品规格或地区的有效参数，不能把不同变体错误合并。

列表成功但详情失败时，商品仍可保持“已发现、详情待读取”。这样恢复任务只需要处理失败详情，不必重新扫描全部列表。更重要的是，不能因为一页列表读取失败就把上一轮所有商品判成已删除。

价格缺失也不一定是失效：部分获准页面本来没有公开价格，或者要求选择规格。字段规则应允许目标的正常差异，不能用一套强制规则把所有商品页面都判错。

先拿一个确实遇到挑战的详情 URL 做兼容性测试。把列表请求与详情请求分别作为测试对象，确认实际接入方式和需要延续的状态。访问适配器返回有效内容后，原来的详情解析器才开始工作。

若列表到详情属于同一连续会话，就按确认要求管理上下文；若不同详情是独立任务，不要无条件共享全局 Cookie。代理路由、访问处理和字段提取各自负责不同部分，边界清楚才容易定位问题。

每条新记录保留商品 ID、来源 URL、采集时间和字段验证结果。监控页面可显示上次成功观察的价格，同时明确标记这次采集失败与数据陈旧程度。不要用 0、空字符串或“无库存”替代未观察到的值。

一轮任务结束后，分别计算成功详情、访问失败和解析失败，分母使用计划读取的详情数。状态码成功率不能代替有效商品记录比例。若后续需要比较工具，比较相同获准样本、相同字段要求下的有效结果与成本，不引用没有测试条件的成功率。

选取有不同规格、不同正常字段表现的几个页面，检查访问处理与解析是否衔接。设置队列并发和重试上限，遵守目标访问条款；当出现明确拒绝或不兼容时暂停对应任务，保留其他已验证的结果。

穿云API的接入评估应覆盖你的真实详情读取动作。准备目标 URL、列表与详情关系、预期字段和失败样本，比只说“这个网站有 DataDome”更能得到针对性的方案。最终要交付的是有来源、可区分新旧的商品数据，而不只是一张页面截图。