第1章 · 出发之前:搭好请求工厂 本章要回答的三个问题:Scrapy 到底比一个请求脚本多了什么,这些"多出来的东西"分别放在工程的哪个位置?一张 Request 车票在框架里按什么路线走,哪些环节由框架托管、哪些环节归你写?怎么从零把一个可运行的采集工程搭起来,并用手头的命令行工具验证它活着? 为什么会有这一章 车票还没印出来之前,先得有车站。很多人在"会用 requests 写脚本"和"想上框架"之间犹豫很久,理由通常是"我的需求不复杂"。这个理由其实站不住:复杂度从来不从天而降,它是在目标网站加验证、数据源加到第三个、同事接手你的脚本的那一天到来的。Scrapy 用一套固定岗位的组件把这些复杂度提前安放好——但代价是,你必须先弄懂这张"施工图",否则连报错信息都读不懂。
本章要回答的三个问题:Scrapy 到底比一个请求脚本多了什么,这些"多出来的东西"分别放在工程的哪个位置?一张 Request 车票在框架里按什么路线走,哪些环节由框架托管、哪些环节归你写?怎么从零把一个可运行的采集工程搭起来,并用手头的命令行工具验证它活着?
车票还没印出来之前,先得有车站。很多人在"会用 requests 写脚本"和"想上框架"之间犹豫很久,理由通常是"我的需求不复杂"。这个理由其实站不住:复杂度从来不从天而降,它是在目标网站加验证、数据源加到第三个、同事接手你的脚本的那一天到来的。Scrapy 用一套固定岗位的组件把这些复杂度提前安放好——但代价是,你必须先弄懂这张"施工图",否则连报错信息都读不懂。
本章是双程旅程的起点站。这里还没有真正的请求出发,你要做的是三件事:认清 Scrapy 相对手写脚本的本质差异(引擎统一调度、组件职责分离、异步驱动);把开发环境装好、把工程骨架立起来;熟悉你在整个旅程中最常用的一组操作入口——命令行工具。这三件事做完,第 2 章 Spider 车间里写的每一行代码,你才知道它落在哪个位置、被谁调用。
一个容易被跳过的认知点:Scrapy 的项目结构不是"约定俗成的文件夹习惯",而是框架装载组件的依据。引擎启动时按固定路径去找 Spider、管道、中间件的定义,放错位置就等于没写。这也是为什么本章花整节篇幅讲结构。
对照开头的三个问题,读完本章你应当能:
| 节 | 回答哪个问题 | 关键产出 |
|---|---|---|
| 1.1 Scrapy 简介 | 框架到底多出了什么,一张请求按什么路线走 | 双程动线的整体认知,判断自己的场景该不该上框架 |
| 1.2 安装与环境配置 | 环境怎么立起来,装不上怎么办 | 可运行的 Scrapy 环境 + 故障排查清单 |
| 1.3 项目结构与命令行工具 | 组件放在哪、日常怎么操作 | 一个标准工程 + 常用命令速查 |
三节是递进关系:先建立架构认知,再落到环境,最后落到工程与操作。1.1 的架构图会在后面五章反复出现,建议把它当"旅程总地图"记牢。
知识点按可自测的标准列出,读完本章逐条核对:
本章结束时,你手上会有一个空转的工厂:结构齐了、设备通电了、车间里还没有工人。第 2 章 Spider 车间就是给工厂雇工人的地方——你在那里写下整张旅程的第一段代码,印出第一张 Request 车票。读完 1.3 的命令行一节就往前走,不必在本章恋战。