response对象被全局变量或闭包长期持有是最常见且最危险的内存泄漏点：存入模块级list、类属性、闭包变量或未清空缓存字典后，其引用计数永不归零，尤其含body时每个响应占几MB；修复需显式提取字段后丢弃response，而非依赖GC。

response 对象被意外长期持有，是内存暴涨最直接、最普遍的原因——不是“会不会”，而是“已经发生”。

为什么 response 一留就涨几百 MB？

一个含完整 HTML body 的 requests.Response 或 scrapy.http.Response 对象，本身可能占几 MB。如果它被塞进全局列表、闭包变量、或通过未拷贝的 meta 一路传递下去，就等于把整个响应体钉死在内存里。

• self.items.append(response)：典型反模式，所有响应原文堆成列表，内存线性上涨
• meta = response.meta; yield Request(url, meta=meta)：赋值即引用，旧 response 因被新 Request 持有而无法释放
• response.text 或 response.content 被缓存后反复读取：两者都是强引用，且 response.history 可能链式拖住多个响应

为什么 gc.collect() 常常没用？

当对象陷入循环引用 + 定义了 __del__ 方法时，Python 的 GC 会把它放进 gc.garbage 列表，标记为 “uncollectable”。此时调用 gc.collect() 返回值可能为 0，但对象永远卡住不释放。

macOS UI 自动化技能包 —— 用 Python 控制你的 Mac

让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限

下载

• 开启 gc.set_debug(gc.DEBUG_UNCOLLECTABLE) 后，控制台会实时打印这类对象类型和数量
• 常见于自定义中间件类同时持有 request 和 response，又写了 __del__
• 修复关键不是删 __del__，而是改用 weakref.finalize(obj, callback)

为什么用 list 存解析结果必然崩？

爬几百页、每页几十条，results = [] + append() 最终生成数万字典的列表，不仅占用连续大块内存，扩容时还会触发多次拷贝。你根本不需要全量在内存里——只要逐条处理、写库或写文件。

• 把解析函数改成 yield：每次只产出一条结构化数据，soup 对象作用域结束即销毁
• 禁止 pages = list(fetch_pages()) 这类操作，等于主动放弃生成器优势
• 字段提取逻辑必须拆开：避免在循环里攒大字典再 yield data_list，那跟用 list 没区别

为什么断点续爬和去重不用磁盘就撑不住？

内存里用 set() 存百万级 URL，或用 deque 堆积待爬队列，RSS 很快飙到几个 GB。这不是优化问题，是数据规模超过内存承载能力的硬限制。

• Scrapy 用户应启用 JOBDIR 配置，让调度器自动落盘请求队列
• 分布式场景必须用 Redis 的 SET 做去重，而非单机 set() —— 数据不持久 + 无法共享是两大死穴
• URL 过滤必须前置：丢弃外链、静态资源、锚点链接，从源头减少无效请求和内存驻留

真正难处理的从来不是“怎么省内存”，而是“哪些引用你根本没意识到还活着”——比如一个被闭包捕获的 response，或一个被 meta 间接延长生命周期的 Selector。这些地方不打快照、不看 tracemalloc 对比，光靠猜，永远定位不到。

Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！