Web Scraping底层思维框架：用5W1H重构数据采集决策体系-CSDN博客

1. 项目概述：这不是“爬虫教程”，而是Web Scraping的底层思维框架

你点开这篇内容，大概率不是为了找一段能跑通的Python代码，也不是想抄个现成的XPath表达式——你真正卡住的地方，往往是：该不该爬？能不能爬？从哪下手？爬下来的数据怎么用才不白费功夫？为什么昨天还正常的脚本今天就全挂了？这些问题，和你写的第1行 import requests 无关，而和你对Web Scraping这件事本身的认知深度直接相关。 The 5 W’s and H of Web Scraping ，说白了，就是用新闻编辑室最基础的六个提问法（Who、What、When、Where、Why、How），给整个网络数据采集行为做一次系统性“体检”。它不教你怎么写 BeautifulSoup.find_all() ，但它决定了你写这行代码之前，是否已经想清楚了目标网站的反爬策略类型、数据更新频率、结构稳定性、法律边界、以及你自己的业务目标到底需要什么颗粒度的数据。我做过37个不同行业的爬虫项目，从电商比价、招聘趋势分析、到学术文献追踪、本地生活服务监测，踩过最多坑的，从来不是技术实现，而是前期没把这六个问题问透。比如，一个做竞品价格监控的客户，最初只要求“每天抓一次首页价格”，结果上线两周后发现，对手把价格藏在AJAX接口里，且接口带时间戳签名；另一个做舆情分析的团队，花两周写了完美解析微博正文的脚本，却忽略了一个关键事实：微博PC端早已下线，移动端API返回结构完全不同——这就是典型的“What”没定义清，“Where”没确认准。所以，这篇文章不是给你一个工具箱，而是帮你校准罗盘。接下来每一节，我都用真实项目中的决策现场还原，告诉你这六个问题怎么问、问谁、问到什么程度才算过关。

2. 核心需求解析与场景化拆解

2.1 Why：动机决定技术方案的生死线

Why是所有决策的起点，但也是最容易被跳过的环节。很多人一上来就想“怎么抓”，却没想“为什么抓”。可恰恰是这个“为什么”，直接锁定了你的技术选型、资源投入和风险等级。我把它分成三个递进层级：

第一层是业务动因。比如，某跨境电商公司要做“海外小众品牌入驻可行性分析”，核心Why是“降低选品试错成本”。这意味着他们不需要实时数据，但需要历史价格波动曲线、用户评论情感倾向、以及竞品上架时间线。这种需求天然排斥高并发、低延迟的方案，反而适合用分布式调度+离线解析+数据库归档的组合。相反，一个做期货套利的量化团队，Why是“捕捉商品页面秒级价格异动”，这就要求毫秒级响应、WebSocket长连接、甚至浏览器自动化渲染——因为价格可能藏在JS动态计算中，静态请求根本拿不到。

第二层是合规动因。这是国内从业者最容易踩雷的点。很多团队以为“只要不商用就没事”，但现实是：《反不正当竞争法》第十二条明确将“妨碍、破坏其他经营者合法提供的网络产品或者服务正常运行”的行为列为不正当竞争；《数据安全法》第四十五条也规定，非法获取、使用他人数据可能面临高额罚款。去年我们帮一家教育机构做课程信息聚合，目标网站robots.txt明确禁止 /course/ 路径，且页面底部有“数据受版权保护”声明。我们当时立刻叫停，转而建议他们通过官方API申请合作——虽然周期长，但避免了后续法律风险。这个决策依据，就来自对Why的再追问：“我们采集这些课程标题和简介，是为了生成招生简章，还是为了训练推荐模型？”前者属于合理使用范畴，后者则涉及数据二次加工，风险陡增。

第三层是可持续动因。很多脚本跑一周就失效，根本原因不是技术差，而是没想清楚“这个数据源能稳定支撑我多久”。我见过最典型的案例，是一家做本地餐饮点评的创业公司，初期用Selenium模拟点击翻页，效果很好。但三个月后，平台上线了基于Canvas指纹的设备识别，Selenium默认配置直接被标记为机器人。如果他们在Why阶段就问一句：“这个数据源的前端技术栈升级频率如何？是否有公开的技术博客或招聘信息透露其反爬团队规模？”答案可能是“每月至少一次JS混淆更新”，那他们一开始就会选择更轻量、更易维护的方案，比如优先尝试逆向分析XHR接口，而非重依赖浏览器渲染。

提示：每次启动新项目前，强制自己写下三句话：

这个数据最终要驱动哪个具体业务动作？（例：自动生成日报/触发库存预警/训练NLP模型）

如果这个数据源明天关闭，我的业务会停摆吗？有没有备选方案？（例：是否有官方API/第三方数据市场/人工抽样替代）

我的采集行为，是否会让目标网站的普通用户感受到性能下降？（例：单IP每秒请求数是否超过其CDN限流阈值）

2.2 What：数据本质决定解析路径的复杂度

What回答的是“你真正要的是什么”，而不是“网页上显示的是什么”。这是区分新手和老手的关键分水岭。新手看到一个商品页，本能地想“把整个页面HTML存下来”；老手会先问：“我要的到底是‘当前售价’这个数字，还是‘历史最低价’这个字段，抑或是‘价格变动趋势’这个时间序列？”

我们以招聘网站职位信息采集为例。表面看，What是“职位名称、公司、薪资、要求”，但深入拆解会发现：

职位名称 ：看似简单，但实际包含结构化陷阱。比如“Java高级开发工程师（大数据方向）”，括号内是关键技能标签，但有些网站会把“大数据方向”放在单独的 <span class="tag"> 里，有些则混在主标题文本中。如果你的下游系统需要按技能标签分类，就必须在What阶段就定义清楚：是否需要提取括号内容？是否需要标准化为“大数据”、“Hadoop”、“Spark”等原子标签？
薪资：这是最典型的“表里不一”字段。网页显示“20K-30K”，但后台API可能返回 {"min_salary": 20000, "max_salary": 30000, "unit": "monthly", "currency": "CNY"} 。前者需要正则提取+单位推断，后者直接JSON解析。更麻烦的是，有些网站用图片展示薪资（防爬手段），或者用Unicode零宽空格混淆数字（如 20K-30K ），这时候What就变成了“能否接受OCR识别的误差率？误差率超过5%是否影响业务判断？”
要求：文本类字段的坑在于非结构化。一条“3年以上Java开发经验，熟悉Spring Boot、MyBatis，有高并发系统设计经验”中，隐含了年限、技术栈、架构能力三个维度。如果你的What定义是“提取所有技术关键词”，那就要处理同义词（如“SpringBoot”和“Spring Boot”）、缩写（如“MQ”和“Message Queue”）、以及上下文依赖（如“熟悉Redis”是技能，“用Redis做缓存”是应用场景）。我们曾为一家猎头公司做简历匹配，他们最初的What是“提取JD里的技术词”，结果爬下来一堆“Java”、“Python”，但漏掉了“JVM调优”、“GC算法”这类高阶能力词——因为原始HTML里这些词被包裹在 <p> 段落中，而非加粗的 <strong> 标签里。后来我们把What重新定义为“提取所有与技术能力相关的名词短语，并保留其出现频次和上下文位置”，才真正满足业务需求。

注意：What必须用“可验证的输出格式”来定义。例如，不要写“获取公司信息”，而要写“输出JSON对象，包含company_name（字符串，长度≤50）、company_size（枚举：small/mid/large）、industry（三级分类，参考GB/T 4754-2017）”。这样，后续的解析逻辑才能被测试用例覆盖，避免“我以为爬到了，其实字段为空”。