数据抓取落地指南：从需求到交付
要在 7 天内拿到稳定、结构化、能直接进表格/BI/数据库 的数据，最稳的做法不是先写爬虫，而是先把交付物写成“能验收的结果”，再用阈值快速选路。
拍板结论（先给你可直接执行的路线）：
- 优先选平台（Worker/Actor/托管抓取）：只要你命中任意一个——需要登录/多账号、强 JS/滚动加载、验证码/风控明显、日更且 >1 万条、需要自动入库+告警、站点经常改版。原因很简单：这些场景里，成本大头不是“写出来”，而是重试、断点续跑、去重、监控、版本回滚和持续对抗风控。
- 可以先用脚本/模板代码：同时满足 低频小规模（通常 <2,000 条/天 或一次性 <5,000 条）、字段简单、基本不登录、风控轻、允许偶尔失败且有人能修。
- 先排除“业务团队硬堆脚本+代理”：当你已经需要 浏览器自动化 + 指纹 + 账号池，但团队又没人长期维护，这条路大概率一周后就变成“能跑但不稳”，两周后变成“每天救火”。
1 分钟选型总览（按典型任务直接对号入座）
本文是教程指南（methodology），核心是让你把抓取做成可验收、可估算、可监控、可交付的项目，而不是“写个能跑的脚本”。涉及登录后数据、个人信息、绕过访问控制/付费墙等场景，只做风险识别与替代方案，不提供操作性指引。
1）先把“我要的数据”写成可签收的交付物：schema + 口径 + 验收
抓取项目最常见的失控点不是反爬，而是这三件事没写清： 1) 字段口径（价格含税吗？变体怎么算？评分取哪个口径？） 2) 唯一键与去重规则（同一实体到底怎么认？） 3) 交付方式与验收条款（CSV 列名、类型、缺失阈值、延迟 SLA）
- 最小需求表（复制就能用）
1.2 把“跑通”写成能签收的 4 个 KPI（给阈值）
建议用记录级指标，因为业务关心的是“能用的数据有多少”，不是“请求成功多少”。
- 记录级成功率 = 成功入库记录数 / 目标记录数
- 必需字段缺失率 = 必需字段缺失的记录数 / 总记录数
- 重复率（按唯一键）= (总记录数 - 去重后记录数) / 总记录数
- 时效（延迟）：入库时间 - 采集时间 的 P95（或 P50/P95 都看）
可直接复制的 PoC 验收条款（建议原样塞进任务单）：
在 500 条样本与 5,000 条放大测试中：记录级成功率 ≥ 95%；必需字段缺失率 ≤ 2%；按唯一键去重重复率 ≤ 1%；采集到入库延迟 P95 ≤ 30 分钟（按业务需要调整）。若连续 30 分钟出现 403/验证码激增导致成功率 < 80%，或必需字段发生结构性漂移（字段整体为空/类型改变/口径失真），判定当前方案不通过：必须切换实现路径或回退解析版本。
1.3 两个会改变路线的硬阈值（别靠感觉）
- 规模阈值：稳定日更且 >10,000 条/天 —— 基本必然需要队列、重试、断点续跑、去重与监控；手写脚本不做这些就是事故。
- 交付阈值：只要你要 自动入库 + 定时调度 + 失败告警 —— 你买的其实是“可交付能力”，不是“能抓到一次”。
2）路线决策树：平台 vs 模板代码 vs 自写脚本 vs 外包/定制（带先排除项）
2.1 6 个问题：命中任意一个，默认别再堆脚本+代理
- 需要登录/多账号（Cookie 维持、轮换）？
- 强 JS 渲染或滚动加载，纯 HTTP 抓不到关键字段？
- 验证码频繁/明显人机风控？
- 稳定日更且 >10,000 条/天，或需要高并发跑批？
- 必须自动入库（Webhook/DB/Sheets）并要调度与告警？
- 页面模板多、经常改版、多地区多语言导致字段漂移高？
命中任何一条：优先平台 PoC；强风控且长期运行再评估定制。
2.2 四条路线怎么选（把话说死，不打太极）
A. 平台 Worker/Actor（默认优先：一周交付 + 少维护）
- 适用：中/重度反爬、需要队列重试、需要日志与可追溯、要直接导出/入库。
- 你买到的是：失败可解释、可恢复、可监控、可复跑。
B. 模板代码（有一点工程力的折中）
- 适用：轻/中度站点；典型是列表+详情拼装、分页规则清晰。
- 前提：你们至少有人能处理解析变更、简单重试与限频。
C. 自写脚本（只在“低反爬+低频小规模+字段简单+能维护”时成立）
- 建议同时满足：不登录；非强 JS（或明确可抓接口）；验证码/429 很少；日量 <2,000 或一次性 <5,000；允许偶发失败；有人能修。
- 不满足还硬上：后果通常是成本被重试与风控吞掉，且上线后不可控。
D. 外包/定制（强风控或长期深度定制才划算）
- 适用：强登录强风控、账号体系/验证码处理、复杂行为模拟；或需要长期稳定与内部系统深度耦合（清洗、实体对齐、SLA）。
- 不适用：只是“想省事拿一批数据”——定制的沟通、验收与维护成本会反噬。
2.3 计费模型：你关心的是“失败重试”会不会把预算炸穿
- 按成功结果计费：更贴近业务目标，失败重试不会无限放大你的账单（但你仍要控制规模与去重，避免“成功很多但无用”）。
- 按资源/运行时计费：适合工程团队能持续调优、降低重试；在反爬重的项目里，成本波动更大。
TCO 别只看单价，至少拆四块： 1) 开发/维护人力（最常被低估） 2) 代理/IP/账号/验证码成本 3) 执行成本（运行时、存储、并发） 4) 失败重试损耗（反爬越重越放大）
3）反爬强度分级 + 稳定性交付：你不用会实现，但必须会验收
3.1 三档分级（用信号判断，不靠“感觉封不封”）
3.2 稳定性交付的“六件套”（缺一件就别谈长期跑）
- 限频与队列（把并发变成吞吐）
- 失败重试与断点续跑（批量任务可恢复）
- 去重（唯一键）与幂等写入（避免重复交付/重复计费）
- 日志与失败原因归因（403/429/captcha/timeout/parse_error）
- 解析版本管理与回滚（字段漂移时能快速回退）
- 交付链路自动化（自动入库/通知/告警）
3.3 停机信号（出现就该换路或收缩需求，不要硬扛）
- 403/验证码占比持续上升，成功率跌破警戒线（例如 <80% 持续 30 分钟或连续 3 个批次）
- 必需字段结构性漂移：整体为空、类型变化、口径失真
- 放大到 10%–30% 规模后，延迟与重试呈指数上升，成本曲线不可控
4）一周 PoC 最短路径：把“能跑”变成“可交付”
Day0：把输入一次准备对（否则 7 天都在返工）
- URL/查询样本（覆盖分页/详情/评论/不同排序与地区，建议 20–50 个）
- 字段 schema + 口径 + 唯一键 + 缺失/重复阈值
- 规模与频率（全量/增量、日新增、是否需要补历史）
- 输出与入库（CSV/JSON/API、Webhook、Sheets/数据库）
- 用途与风险记录（来源、用途、保留期、删除责任人）
Day1–Day2：100–500 条小样本，只验三件事
- 必需字段是否稳定
- 唯一键去重是否合理
- 口径是否对得上业务（价格/币种/评分/时间）
Day3–Day4：放大到目标的 10%–30%，专门找“封禁与延迟拐点”
- 403/429/验证码是否随并发上升而激增
- 延迟 P95 是否失控（队列拥堵、重试过多）
- 失败是否集中在某类页面（评论翻页、变体、滚动加载）
Day5–Day7：交付化（多数团队缺的就是这一步）
- 输出严格对齐 schema（列名、类型、缺失值策略）
- 接入你的目标系统（Sheets/DB/对象存储 + 通知）
- 加调度与告警
- 固化解析版本与回滚策略
PoC 判定表（建议直接打分）：
5）四类高频场景：字段示例 → 最容易翻车点 → 推荐路径
5.1 电商（Amazon 类）：变体、价格口径、评论链路
最小字段（先跑稳，再扩）：
- 商品：asin, title, price, currency, rating, review_count, product_url
- 可选：variant_map, availability, seller, fulfillment
最容易失败的点（以及信号）：
- 只抓到默认变体（信号：同 asin 的价格异常波动或与页面不一致）
- 评论翻页/排序口径混乱（信号：review_id 重复、时间线断层）
- 价格口径不清（信号：业务对账失败、币种/含税争议）
- 风控导致“返回 200 但字段空”（信号：成功率高、缺失率飙升）
推荐路径：优先平台 Worker/Actor；能明确抓接口且规模不大时可模板代码；需要复杂清洗对齐再考虑定制。
5.2 社媒（TikTok 类）：滚动加载 + 强风控 + 时效
最小字段：video_id, author_id, publish_time, caption, play_count, like_count, comment_count, video_url
最容易失败的点：
- 无限滚动导致只拿到前 N 条
- 验证码/302 跳登录、账号风控
- 地域与账号态影响结果一致性
推荐路径：增长/运营用途默认平台路线；如果只是低频小样本，可模板代码试跑，但要预设随时切回平台。
5.3 地图（Google Maps 类）：地理漂移 + 去重 + 增量更新
最小字段：place_id, name, primary_category, address, rating, review_count, lat, lng
最容易失败的点：
- 同关键词不同位置/缩放导致结果集合漂移（信号：每次抓到的商家集合变化大）
- 去重失败（信号：重复率高或 place_id 缺失）
- 跨区域策略变化导致局部城市成功率断崖
推荐路径：以 place_id 为唯一键做增量更新；需要稳定周更/日更的，平台优先。
5.4 通用列表/名录/资讯：分页规则与多模板解析
最小字段：url(or item_id), title, publish_time(如有), list_rank, list_page_url
最容易失败的点：
- 游标分页/隐藏参数导致重复或断档
- 详情页多模板导致缺失率集中爆发
推荐路径：轻度站点脚本/模板即可；一旦强 JS 或需要稳定日更与入库，直接上平台。
6）用平台把“结果交付”跑起来：选 Actor/Worker → 跑批 → 入库 → 成本与稳定性验收
平台不是“省事按钮”，它的价值在于把抓取变成可复跑、可追溯、可监控。
6.1 选现成 Actor/Worker 的 6 条硬标准（不满足就别抱幻想）
1) 必需字段覆盖：能直接输出你的必需字段（缺的字段是否能补，补的成本是多少） 2) 反爬能力匹配：是否支持浏览器自动化/代理/限频/会话维持 3) 队列与重试：是否支持断点续跑、并发控制、失败重试 4) 去重能力：是否能基于唯一键去重或保证幂等 5) 日志可追溯：能否看失败原因分布与样本 6) 交付集成：CSV/JSON、Webhook、对象存储、Sheets/数据库
6.2 跑批与调度：先增量、再爬坡
- 先做增量任务（省钱、也更稳）
- 并发从小到大爬坡，每次只改一个变量（并发/代理/频率/账号），用失败原因分布找拐点
6.3 入库优先级：能自动化就别人工
1) CSV/JSON 导出（一次性分析） 2) 对象存储 + 通知（可自动化流程） 3) 直连 Sheets/Airtable（运营协作） 4) 写入数据库/数仓（长期监控、BI）
只要是持续更新，人工下载/复制粘贴都会变成隐性故障点。
6.4 成本估算：先算“去重后你真正需要多少条”
PoC 级估算用这一条就够用：
- 去重后有效记录数 × 更新频率 × 单条成功成本 ≈ 月成本
- 控制预算的关键不是“压单价”，而是：
- 用唯一键去重，避免排序/地理漂移导致的重复
- 先小样本验证口径，避免“成功很多但都不能用”
6.5 CoreClaw 与 Apify 的定位差异（给你明确预期，不做空泛夸奖）
- CoreClaw 更偏“结果交付/少代码/按成功付费”：适合业务团队在一周内交付结构化结果，把不确定的失败重试成本尽量锁住。
- Apify 更偏“平台能力/Actors 生态/编排与集成”：适合更工程化的团队，把抓取作为工作流的一环持续优化；但在反爬重、重试多的任务里，需要更会调优资源与成本。
7）合规与风险边界：能做 / 慎做 / 不要做（并给替代方案）
这里不提供合规背书，只提供立项时可执行的风险分级与改写需求的方法。
7.1 能做（相对低风险）
- 公开可访问信息（不登录、不绕过访问控制）
- 字段最小化、频率合理、不影响对方服务
- 用于市场研究、竞品监控、选品等聚合分析
7.2 慎做（建议走内部合规评审 + 降风险）
- 涉及可能的个人信息：社媒评论、昵称、头像、位置等
- 跨地域抓取与使用（地图/社媒尤甚）
- 用于营销触达、画像、自动化私信/外呼等（风险显著上升）
7.3 不要做（建议直接否决或改需求）
- 登录后数据、私密内容、绕过访问控制/付费墙
- 敏感个人信息采集并用于识别或触达
- 规模化规避明确限制并用于商业化触达
7.4 业务团队也能做到的“最低数据治理动作”
- 留痕：来源、用途、字段、保留期、删除责任人
- 最小化：能不存个人字段就不存
- 权限：谁能看、谁能导出
- 删除：到期可追溯删除
替代方案（触红线时的改法）：
- 优先官方 API / 数据合作 / 授权供应
- 把需求改为聚合指标（趋势、分布、TopN），避免个人级数据
结论：把抓取项目变成“可交付”的三步（外加三条停机信号）
三步拍板： 1) 先写可验收结果：schema + 口径 + 唯一键 + 规模频率 + 交付入库 + KPI。 2) 再按阈值选路：
- 低反爬 + 低频小规模 + 简字段 + 能维护：脚本/模板可行；
- 命中登录/强 JS/验证码/日更>1万/自动入库：默认平台 PoC；
- 强风控 + 长期深度定制：评估定制/外包与数据工程投入。
3) 用 PoC 指标决定继续还是换路：成功率、缺失率、重复率、时效必须可监控；不达标就切换路线或收缩需求，不要把时间烧在“调到能跑”。
三条必须停机的信号：
- 403/验证码持续拉升导致成功率跌破警戒线
- 必需字段结构性漂移（整体为空/类型变/口径失真）
- 放大后重试与延迟指数上升、成本曲线失控
做到这些，你交付的不是“一次性数据文件”，而是一条能持续产出、成本可估、风险边界清晰的数据供给链路。