cross-platform-products-ai-analyst/docs/CrawlerFeasibility.md

当前阶段平台爬虫可行性评估（天猫 / 京东）

• 文档状态：Draft
• 版本：v0.5
• 更新时间：2026-04-02
• 关联文档：
  • docs/RequirementsDoc.md
  • docs/PRD.md
  • docs/FeatureSummary.md
  • docs/DevelopmentPlan.md

1. 评估目的

本文件用于回答当前阶段最关键的技术问题：在不依赖官方开放平台、且不把完整浏览器自动化作为默认主路径的前提下，天猫和京东的商品搜索、详情抓取与评论抓取，是否可以形成可持续、可恢复、可观测的稳定交付链路。

本轮评估采用以下边界：

1. 当前实现范围只包含天猫与京东。
2. 淘宝作为下一优先平台，放入后续扩展规划。
3. 抖音电商暂不进入当前实现阶段，只保留风险结论。
4. 评估以 2026-04-02 的实时页面与请求链路观察为准，不以官方开放平台能力作为唯一交付前提。
5. 最终判断标准不是“是否单次抓通”，而是“是否能形成可维护、可恢复、可审计的稳定交付能力”。
6. 若稳定交付必须依赖客户端上下文模拟或私有签名复现，这种依赖应被显式写入方案，而不是在评估阶段被默认排除。
7. 在授权会话与治理边界内，应尽可能探索一切可实现且可维护的路径，包括尽量对齐真实网页端搜索、跳转、查看与上下文建立行为，以提升链路稳定性并降低异常判定。

2. 最新范围结论

当前阶段的结论可以直接收敛为六点：

1. 天猫和京东都存在可行的非浏览器主路径，但这个“非浏览器”不是匿名静态 HTTP，而是“服务端会话驱动的同构请求回放 + Hydration 解析”。
2. 从交付视角，平台是否可做，取决于会话获取、模板刷新、阻塞恢复和观测告警能否一起做成工程能力，而不是是否存在一次性可用链路。
3. 浏览器仍然必要，但应被定义为受控恢复通道：负责登录、验证码、模板刷新、风控恢复和接口发现，不应承接常规搜索、详情和评论吞吐。
4. 若稳定交付依赖“客户端上下文模拟（含设备指纹相关字段补齐）”或“私有签名复现”，这些能力应被定义为受限工程依赖；它们不等于绕过登录，但会显著提高维护成本、漂移风险和治理要求。
5. 工程实施不应过早锁死为单一路径，而应并行探索请求回放、Hydration、受控浏览器、客户端上下文补齐与行为一致性调度等路线，最后以成功率、恢复成本和可治理性收敛。
6. 淘宝应作为下一优先扩展平台，因为天猫 PC 搜索实际已落在淘宝搜索与 mtop/h5api 基础设施之上，后续复用价值高。
7. 抖音电商当前阶段应延后实现；理由不是“永远不可做”，而是网页链路不清晰、成本高、与当前双平台闭环目标不一致，现阶段不适合承诺稳定交付。

补充说明：

1. 本文所说“同构请求”指尽量对齐平台页面真实请求族、Header、Cookie、动态参数和调用节奏。
2. 本文允许使用授权会话、模板回放、Hydration、受控浏览器恢复等工程手段，以稳定交付为目标。
3. “客户端上下文模拟（含设备指纹相关字段补齐）”与“私有签名复现”不应被直接等同于绕过登录；前提仍是用户正常登录并在授权会话内运行。
4. 但这类能力不应被包装成低维护、低风险能力，而应明确标记为受限工程依赖，单独承担版本漂移、恢复、审计和人工介入成本。
5. 若某平台关键动态参数无法在授权会话内通过现有上下文或受限工程依赖稳定刷新，应直接判定为 Blocked 或 NotCommittable，而不是继续对外承诺稳定交付。
6. 本文所说“行为一致性”指尽量对齐真实网页端入口、导航顺序、请求上下文、停留节奏和查看链路，以减少异常流量特征并提升链路稳定性。

3. 实时验证与证据

3.1 天猫

实时观察：

1. https://www.tmall.com/robots.txt 返回 User-agent: *、Disallow: /*?*。
   参考：https://www.tmall.com/robots.txt
2. https://list.tmall.com/robots.txt 对通用抓取客户端返回 User-agent: *、Disallow: /。
   参考：https://list.tmall.com/robots.txt
3. 2026-04-02 的实时页面测试中，PC 搜索实际落在 https://s.taobao.com/search?q=iPhone%2015&tab=mall。
4. 同次测试里，页面请求链路出现 https://h5api.m.taobao.com/h5/... 的多个 mtop 请求，且伴随 sign、t、appKey=12574478、umidtoken、bx-ua、bx-et 等动态参数。

判断：

1. 天猫搜索并不是一个“独立、稳定、静态”的天猫专属 HTTP 页面抓取问题，而是淘宝/天猫共用 H5API 基础设施的问题。
2. 因此天猫更适合走“会话驱动的请求回放”而不是“直接抓列表 DOM”。
3. 这也意味着后续接入淘宝时，可直接复用较大比例的请求模板、参数分类逻辑和字段映射框架。

3.2 京东

实时观察：

1. 2026-04-02 对 https://search.jd.com/Search?keyword=iPhone%2015 的实时测试中，页面直接跳转到 passport.jd.com 登录页。
2. 对 https://item.jd.com/100068388535.html 的实时测试中，页面同样跳转到登录页。
3. 但在商品页初始化请求链路里，仍可观察到 api.m.jd.com 的 PC 商品接口调用，例如 functionId=pc_detailpage_wareBusiness，并伴随 h5st、x-api-eid-token、uuid 等参数。
4. 同时可观察到 cactus.jd.com/request_algo、jra.jd.com/jsTk.do、sgm-w.jd.com/h5 等风控/参数初始化请求。
5. https://item.jd.com/robots.txt 的公开信息非常有限，不能据此推断搜索或详情路径可稳定匿名抓取。
   参考：https://item.jd.com/robots.txt
6. 2026-04-02 登录后复测中，https://search.jd.com/Search?keyword=iPhone%2015 返回的是 Vite 壳页 HTML，响应内不再稳定包含商品卡片；同 query 的 pc_search_searchWare API 回放可稳定返回 30 条候选。
7. 同次复测中，pc_detailpage_wareBusiness 与 getLegoWareDetailComment 在授权会话下可稳定返回价格、店铺、库存、主图、标签与评论正文。

判断：

1. 京东 PC 端存在明确的接口层，不是只能靠浏览器 DOM 抓；其中搜索页 HTML 已明显退化为前端壳页，不能再把稳定 DOM 解析当作默认主路径。
2. 但接口调用明显依赖会话与动态参数上下文，不能把它当作无状态公开接口。
3. 当前更稳的默认路线应收敛为“授权会话下的搜索/详情/评论 API 回放”，浏览器负责登录、模板刷新与阻塞恢复。
4. 因此京东的非浏览器路线是可行的，但必须建立在“先会话、后请求”的体系上。

3.3 淘宝

当前不进入实现，但应提前写入路线图：

1. 天猫搜索已实质依赖淘宝搜索与 mtop/h5api 请求族。
2. 因此淘宝不是一条全新技术线，而更像是天猫适配栈的横向扩展。
3. 这也是把淘宝放在抖音之前的主要原因。

3.4 抖音电商

当前阶段不进入实现，保留结论如下：

1. 网页链路与电商域链路边界不清晰。
2. 风控、动态参数和稳定回放成本明显高于当前双平台路线。
3. 即使未来要做，也不应阻塞当前天猫 / 京东闭环。

4. 非浏览器方案可行性判断

4.1 平台能力矩阵

平台	当前阶段定位	搜索	详情	评论	推荐主路径	结论
天猫	当前 MVP	中高	中高	中	L0 会话驱动请求回放 + L1 Hydration	可做，但必须接受其底层是淘宝/天猫共用请求体系
京东	当前 MVP	中	中高	中	L0 会话驱动请求回放 + 登录前预检查	可做，但搜索和详情都受会话、风控和动态参数强约束
淘宝	下一优先平台	中高	中高	中	复用天猫适配栈	适合在双平台闭环稳定后接入
抖音电商	当前延后	低	低到中	低	暂不进入当前实现	不纳入当前排期

4.2 当前阶段默认 delivery_requirement

平台	暂定值	原因
天猫	required	稳定交付不应依赖匿名链路的偶然可用性，会话、模板刷新与恢复闭环必须前置
京东	required	当前实时环境下搜索和详情都触发登录页，会话前置是硬要求
淘宝	required	作为后续平台，预计与天猫相似，若进入排期也应按稳定交付标准要求会话优先
抖音电商	not_committable	当前阶段缺少低风险、可维护的稳定链路，不应承诺交付

补充说明：

1. required 不等于只能使用纯 HTTP 回放，也允许在授权会话内接入受限工程依赖以补齐客户端上下文或签名能力。
2. 但一旦引入受限工程依赖，就必须额外满足隔离部署、版本控制、回归验证、审计留痕和快速熔断。

5. 关键难点

当前真正的难点不在“能不能发 HTTP 请求”，而在以下十件事：

1. 会话依赖：两个平台都不能假设匿名链路稳定，必须先解决会话获取、保存、校验和失效恢复。
2. 动态参数生命周期：天猫的 sign/umidtoken/bx-* 与京东的 h5st/x-api-eid-token 都不是静态模板字段，需要区分哪些是会话级、哪些是请求级、哪些是短时有效。
3. 模板热更新：请求模板一旦漂移，系统要能快速重新采样、比对和刷新，而不是整条链路报废。
4. 域名与上下文一致性：天猫与淘宝跨域，京东详情、登录、风控接口分散在不同域名，请求上下文不能只看单接口。
5. 评论分页吞吐：评论抓取若退化为浏览器滚动，整体时长会迅速失控，因此评论能力必须坚持 HTTP 主路径。
6. 阻塞识别与恢复：跳登录、验证码、风控、参数失效都要被产品化为显式状态，而不是笼统记为失败。
7. 可观测性：成功率、阻塞率、模板漂移率、恢复耗时和人工介入频次都必须可量化，否则无法承诺稳定交付。
8. 交付边界：若某平台只能维持“可探索”而不能维持“可恢复、可审计、可持续”的能力，应主动降级为研究态，而不是继续保留在承诺范围内。
9. 受限工程依赖治理：若引入客户端上下文模拟或私有签名复现，必须把依赖模块隔离、版本化、监控化，并明确人工接管和熔断条件。
10. 行为一致性调度：搜索、翻页、进详情、看评论、回退或继续浏览等动作若与真实网页端上下文脱节，链路稳定性会明显下降，因此需要单独设计调度与验证策略。

6. 具体实施计划

6.1 技术路线

当前阶段推荐的统一技术路线如下：

1. 服务端会话中心：统一保存各平台授权会话、有效期、最近校验结果和阻塞标记。
2. 请求模板实验室：保存 HAR、请求样本、参数分类、响应 Schema 和最近一次成功模板。
3. 适配器按能力拆分：每个平台至少拆成 precheck、search、detail、reviews 四个模块。
4. 默认主路径走 HTTP：搜索、详情、评论都先走会话驱动的请求回放或 Hydration 解析。
5. 浏览器做受控恢复通道：登录、验证码、模板刷新、风控恢复、接口发现都可通过浏览器完成，但必须可调度、可观测、可限流，不承接常规抓取吞吐。
6. 若项目明确接受高维护路径，则增加受限工程依赖层：单独承接客户端上下文模拟、签名复现或其他必须的客户端能力补齐，并与主采集链路隔离。
7. 增加稳定性交付控制面：统一暴露健康检查、模板版本、成功率、阻塞率、恢复队列和自动降级策略。
8. 增加行为一致性策略层：按平台沉淀入口选择、搜索后详情访问顺序、分页节奏、停留窗口和上下文延续规则，并以数据回放持续验证。

6.2 Phase 0：两周 PoC

天猫：

1. 固化搜索请求族和关键参数分类，验证是否能形成可复用的短期模板。
2. 验证详情页首屏字段是否可通过 Hydration 直接解析，必要时补接口回放。
3. 验证评论路径是否可在同一会话体系下稳定分页取样。
4. 对比不同搜索入口、列表到详情跳转方式和上下文建立方式对成功率与阻塞率的影响，沉淀行为一致性策略。

京东：

1. 固化登录前预检查规则，确保搜索前先判断是否可执行。
2. 验证详情接口族是否可以稳定返回商品核心字段。
3. 验证评论路径是否能形成统一的分页模板和错误分类。
4. 验证搜索、详情、评论之间的访问顺序和上下文延续是否影响稳定性，并沉淀最优调度策略。

通用：

1. 建立 Blocked 与交付状态分类：NeedLogin、NeedVerify、TemplateExpired、RiskIntercepted、SchemaDrift，以及不进入承诺范围的 NotCommittable。
2. 建立 strategy_attempts 记录每次尝试的路径、耗时、结果与恢复动作。
3. 建立模板刷新机制：手动登录或恢复后自动重新抓一份样本，更新请求模板。
4. 建立稳定性回归任务：按天回放核心链路，记录模板漂移、阻塞占比和恢复成功率。
5. 识别哪些链路依赖受限工程依赖，并分别记录其版本、漂移频率、人工维护成本和失效影响面。
6. 建立行为一致性实验记录：比较不同入口、动作序列和停留节奏对成功率、阻塞率和恢复成本的影响。

6.3 PoC 退出条件

至少一个当前 MVP 平台同时满足以下条件，才进入正式闭环开发：

1. 搜索候选返回成功率不低于 80%，且统计口径覆盖连续 200 次任务；Blocked、NoResult 记为可解释结果。
2. 商品详情必填字段完整率不低于 85%。
3. 评论样本抓取达到每链接 50 条时，单链接耗时不高于 90s。
4. 连续运行 7 天或 200 次任务，结构化字段漂移率不高于 10%，且不存在需要人工临时修补的系统性失败。
5. TemplateExpired、NeedLogin、RiskIntercepted 等常见阻塞具备明确恢复动作，恢复成功率不低于 70%，单次恢复时长不高于 30min。
6. 浏览器直接承接数据抓取的占比不高于 20%，且浏览器恢复任务本身具备成功率与耗时监控。
7. 若平台稳定性依赖受限工程依赖，则该依赖的版本切换、回归验证、审计留痕和一键熔断必须先通过演练。
8. 若平台稳定性明显依赖行为一致性策略，则该策略必须完成 A/B 回放验证，并能被配置化管理与快速回退。

7. 对文档的强制影响

本次评估要求上游文档统一以下口径：

1. 当前 MVP 平台范围只包含天猫和京东。
2. 淘宝写入下一优先扩展平台，而不是继续放在“其他平台”里。
3. 抖音电商写入延后实现，不进入当前排期和验收。
4. 当前主采集路径明确为“服务端会话驱动的 HTTP 请求回放 + Hydration 解析”。
5. 受控浏览器写成登录、模板刷新和阻塞恢复能力，而不是默认数据采集主通路。
6. 所有上游文档应把“稳定交付”而不是“单次抓通”作为验收口径。
7. 若某条交付链路依赖客户端上下文模拟、私有签名复现或其他受限工程依赖，必须在上游文档中显式写明，而不是继续沿用“纯 HTTP 回放”口径。
8. 任何高维护依赖若缺少版本控制、观测、审计、熔断和人工接管预案，仍不应进入承诺交付范围。
9. 上游文档应明确写入“尽可能探索所有可实现路径并优先选择与真实网页端行为一致的稳定方案”，但不得把不可治理的偶发链路包装成可承诺能力。