python web服务内存持续上涨大概率是对象被意外长期持有，如全局缓存未清理、__del__导致循环引用卡住、c扩展缺陷等；需用psutil和gc.get_stats()区分真泄漏与缓存预占，结合objgraph和memray定位根因。
容器里 Python Web 服务内存持续上涨，大概率不是 GC 失效，而是对象被意外长期持有——比如全局缓存没清、回调没解绑、循环引用配了 __del__，或者用了带内存缺陷的 C 扩展库。K8s 的 OOM Killer 杀进程只是表象，根源在代码逻辑层。
确认是不是真泄漏：别把缓存增长当泄漏
先排除“假阳性”：内存 RSS 上涨 ≠ 泄漏。很多框架（如 Django 的模板缓存、FastAPI 的 lru_cache）或中间件（如 SQLAlchemy 连接池）会主动预占内存。关键看趋势是否单调不可逆。
- 用
psutil.Process().memory_info().rss每 30 秒打点，持续跑 2 小时以上，观察曲线是否有平台期或回落 - 对比相同请求压测下，容器启动后 5 分钟 vs 60 分钟的
gc.get_stats()输出，重点关注collected字段是否归零或骤降 - 如果只在特定请求路径（如上传大文件、导出报表）后内存不回落，优先盯住该路径的临时对象生命周期
查全局变量和模块级缓存：最常见泄漏源
Web 服务里最易被忽略的是模块顶层字典、列表或类属性。它们随模块加载而常驻，引用计数永不归零。
- 搜索所有
_cache、_pool、_registry、GLOBAL_前缀的变量，检查是否有清理逻辑（如定时clear()或 LRU 驱逐） - 用
objgraph.show_growth(limit=20)在请求前后各执行一次，重点关注数量激增的类型（如dict、list、str），再用objgraph.find_backref追到持有者 - 替换方案：把
dict改成weakref.WeakValueDictionary；用functools.lru_cache(maxsize=128)替代手写缓存；连接池必须设max_overflow和pool_timeout
盯死循环引用 + __del__：GC 会绕过它
只要对象定义了 __del__ 方法，哪怕只是打印日志，Python 就会把它放进“不可收集集合”。这类对象在 gc.garbage 里永久滞留，且不会触发 __del__ —— 它们只是卡住了。
- 启动时加
gc.set_debug(gc.DEBUG_UNCOLLECTABLE)，看日志是否频繁输出uncollectable对象 - 搜索项目中所有
def __del__(self):，尤其注意 ORM 模型、异步任务类、自定义上下文管理器 - 替代方案：用
weakref.finalize(obj, callback)替代__del__；用contextlib.closing或__exit__管理资源；双向引用处强制用weakref.ref存 parent
容器环境特有陷阱：C 扩展、日志、健康检查
容器里内存泄漏常和宿主环境耦合：比如某些 C 扩展（pycurl、旧版 numpy）在 musl libc（Alpine 镜像）下不释放内存；日志 handler 被重复注册；健康检查接口本身触发泄漏。
- 镜像优先用
python:3.11-slim-bullseye（glibc）而非alpine，除非你明确验证过所有 C 依赖在 musl 下行为正常 - 检查
logging.getLogger()是否在每次请求里重复addHandler()，导致 handler 链无限增长 - 把健康检查端点（如
/health）单独剥离，用最小依赖的脚本实现，避免引入业务代码的引用链 - 在 Dockerfile 里加
ENV PYTHONMALLOC=malloc，禁用 Python 内存池，让valgrind或memray能准确定位 C 层泄漏
真正难排查的泄漏，往往藏在第三方库的 C 扩展里——比如某个版本的 pillow 在处理 GIF 动画帧时未释放解码缓冲区。这时候得靠 memray 录制火焰图，直接看到哪一行 C 函数分配了内存却没 free。别迷信“库很成熟”，容器里运行时间越长，越容易暴露底层内存管理缺陷。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
