TEARDOWN
源码剖析
把值得读的开源项目拆开：它解决什么问题、核心抽象是什么、关键路径怎么走、哪些设计值得抄。
raise NotConfigured 带不带消息，决定了它是一条 WARNING 还是零日志——而管道就是这么没的
MiddlewareManager 里那句 if e.args 决定一切：带消息的 NotConfigured 打一条 WARNING，不带的一行日志都没有。实测一个裸 raise NotConfigured 的管道——item 抓到 3 条，落库 0 条，退出码 0，日志零行。
源码剖析Scrapy工程化6 min
自定义下载处理器炸了，Scrapy 只报「Unsupported URL scheme」——而且这辈子都不会再试一次
DownloadHandlers 把加载失败包装成 NotSupported，原始异常被塞进「不支持的协议」这句话里；失败结果还会永久缓存，一次失败之后同一个 scheme 的所有请求都直接返回缓存，构造函数再也不会被调用第二次。
源码剖析Scrapy工程化9 min
FEEDS 里写错一个字母，另一个完全正确的输出也消失了：item 抓到 3 条，文件 0 个
FEEDS 的校验在遍历循环里 raise NotConfigured，而这会让整个导出扩展被停用——不是跳过那个配错的输出，是全部。配两个输出、其中一个格式名拼错，两个都不会生成。
源码剖析Scrapy工程化6 min
settings.set() 可能什么都没做：优先级低于现值时静默丢弃，返回值还是 None
Scrapy 的 Settings 按优先级写入，低于当前优先级的写入会被直接丢掉——不抛异常、不打告警，set() 的返回值和成功时一模一样。spider 的 custom_settings 会挡住后来所有默认优先级的修改。
源码剖析Scrapy工程化6 min
Scrapy 2.17 里 start_requests() 已经没人调用了：0 个请求、0 个告警、退出码 0
升到 2.13 之后，只定义 start_requests() 的爬虫会产出 0 个请求。不报错、不告警、finish_reason 还是 finished。这是我自己在写另一篇文章时踩进去的。
源码剖析Scrapy工程化6 min