Python后端爬虫专题16代码只有两个回调数据却走了十站——从Engine到Pipeline理解Scrapy上一篇练习完整答案授权链路是① GET/login服务器在 HTML 中给出表单 CSRF token并通过 Set-Cookie 产生targetlab_csrf② 同一个 Session POST 用户名、密码和 token请求自动携带 CSRF Cookie③ 校验成功的响应通过 Set-Cookie 产生targetlab_session④ Session GET/internal/jobs自动携带会话 Cookie。CSRF Cookie 证明 token 与发起表单的浏览器会话相符session Cookie 才代表登录身份。运行pytest tests/test_auth_session.py -q时正确账号应获得内部页面错误密码触发AuthenticationFailed底层状态为 401伪造 CSRF 得到 403。二者都不适合盲目重试凭据错误重复提交可能触发锁定CSRF 错误说明流程或页面合同已变化。可直接采用的授权清单为系统与数据负责人姓名书面授权编号和有效期允许的 scheme、host 与路径禁止字段专用只读账号权限每秒与每日限额维护窗口凭据存储和轮换责任人发现 401/403/429、数据异常或负责人撤销授权时的自动停止开关日志与快照保留期。没有这些信息技术上能登录也不代表应该采集。为什么已有 HTTPX 还要学 ScrapyJobRadar 的顺序与 asyncio 流水线适合后端开发者理解每一层Scrapy 则把请求调度、去重、下载中间件、robots、重试、节流、统计和 Feed 导出组织成成熟运行时。当来源更多、链接图更复杂、需要持续调度时它能少写大量基础设施。但迁移不意味着重写数据规则。parse_listing、parse_detail与JobItem已经经过测试Scrapy 只负责何时发请求、把响应交给哪个回调。框架适配器越薄两个采集入口越不容易产生两套字段口径。跟踪一个列表请求的完整旅程Spider 产生 Request 后Scheduler 去重并入队Engine 取出请求依次经过 downloader middlewareDownloader 发出网络请求Response 逆向经过中间件回到 EngineEngine 根据 Request.callback 调用parse回调可以 yield 新 Request 或 itemRequest 再回 Scheduleritem 则经过 Item Pipeline最后 Stats Collector 汇总计数和耗时。这里的 “Pipeline” 是 Scrapy item pipeline不等于 JobRadar 的pipeline.py应用服务。前者通常做 item 清洗、持久化或丢弃后者组织 HTTPX、快照、解析与 Repository。命名相似但调用者不同面试时应能说清。JobSpider 的两个回调构造函数接收绝对seed_url验证 scheme 与 hostname从中生成start_urls和allowed_domains。列表回调parse把response.text、response.url交给共享parse_listing为每个详情 yield 一个 Request并为 next_url yield 回到parse的分页请求。详情回调parse_job调共享解析器得到 Pydantic 模型然后model_dump(modejson)。modejson会把 date 转为字符串使 Scrapy Feed exporter 能直接序列化。若 yieldJobItem对象或 Selector下游合同就不稳定。运行本篇检查点cd project.\.venv\Scripts\python.exe-m pytest tests\test_framework_adapters.py::test_scrapy_spider_emits_detail_and_pagination_requests-q测试创建真实HtmlResponse并调用 Spider 回调断言产生两个详情 Request 和一个分页 Request还检查 callback 分别指向parse_job与parse。它不启动公网下载所以运行稳定验证的是我们的路由合同不是重测 Scrapy 的 Downloader。yield 为什么不是 return list生成器每获得一个结果就交还 Engine不必等整页所有链接装进列表后再返回。更重要的是Scrapy 会识别 yield 对象类型Request 进入调度dict 进入 item 流。若return [requests]简单场景也可能工作但失去流式表达异常位置与扩展中间件都更难理解。回调不是我们主动调用的普通业务函数而是 Engine 在响应回来后调用。因此 callback 只传函数对象self.parse_job不能写成self.parse_job()后者会在创建 Request 时立刻执行而且没有 response 参数。去重、allowed_domains和业务规范化各做什么Scheduler 的请求指纹避免相同请求重复调度allowed_domains防止链接意外爬离站点JobRadarnormalize_url清掉 fragment 和跟踪参数数据库唯一约束保证跨运行幂等。四者保护不同阶段不能说“Scrapy 自带去重所以数据库不需要唯一键”。重启、参数差异和不同 Spider 运行都可能绕开内存/磁盘调度去重。哪里会失败构造时种子不是绝对 HTTP URL应尽早 ValueError列表结构改变parse_listing返回空或明确报错详情缺字段Pydantic/PageParseError 让 item 不进入数据库网络失败由 RetryMiddleware 按配置处理。生产项目还需监听 spider_error、item_dropped 等信号把错误与业务 task_id 关联。本篇完整 Scrapy 适配模块先只理解“请求如何流动”不要急着加数据库 Pipeline。本模块刻意保持薄解析规则只有一份。下一篇会真正执行 Spider 并检查 JSON 输出。让 Scrapy 的调度能力复用 JobRadar 已验证的解析合同。fromcollections.abcimportIterablefromurllib.parseimporturlsplitimportscrapyfromscrapy.httpimportResponsefromjobradar.parsingimportparse_detail,parse_listingclassJobSpider(scrapy.Spider):采集 TargetLab 列表与详情item 字段与 JobItem 完全一致。namejobradar_jobscustom_settings{ROBOTSTXT_OBEY:True,AUTOTHROTTLE_ENABLED:True,CONCURRENT_REQUESTS_PER_DOMAIN:2,DOWNLOAD_TIMEOUT:10,RETRY_HTTP_CODES:[429,500,502,503,504],FEED_EXPORT_ENCODING:utf-8,}def__init__(self,seed_url:str,*args:object,**kwargs:object)-None:super().__init__(*args,**kwargs)partsurlsplit(seed_url)ifparts.schemenotin{http,https}ornotparts.hostname:raiseValueError(seed_url must be an absolute HTTP(S) URL)self.start_urls[seed_url]self.allowed_domains[parts.hostname]defparse(self,response:Response,**kwargs:object)-Iterable[scrapy.Request]:listingparse_listing(response.text,response.url)fordetail_urlinlisting.detail_urls:yieldscrapy.Request(detail_url,callbackself.parse_job)iflisting.next_url:yieldscrapy.Request(listing.next_url,callbackself.parse)defparse_job(self,response:Response)-Iterable[dict[str,object]]:itemparse_detail(response.text,response.url)yielditem.model_dump(modejson)本篇课后练习从start_urls开始按顺序写出 Engine、Scheduler、Downloader、Spider、Item Pipeline 之间一次详情采集的数据流。解释callbackself.parse_job与callbackself.parse_job()的区别并说明错误写法会在什么时候执行。修改 Fixture 增加一个重复详情链接观察共享解析结果与 Scrapy Scheduler 去重分别处于哪个阶段。下一篇将把 Spider 输出成真实 JSONL。