python文件句柄泄漏本质是未正确关闭文件致文件描述符持续占用，引发“too many open files”错误；排查需定位未关闭对象、验证是否真泄漏、静态扫描常见模式、运行时追踪及借助objgraph等工具分析。
Python文件句柄泄漏本质是未正确关闭打开的文件，导致系统级文件描述符（file descriptor）持续占用，最终可能触发 OSError: Too many open files。排查核心在于：**定位未关闭的文件对象 + 确认其生命周期是否超出预期**。
确认是否真存在句柄泄漏
不要仅凭报错就断定泄漏。先验证当前进程打开的文件数量：
- Linux/macOS：运行
lsof -p <pid> | wc -l</pid>或cat /proc/<pid>/fd | wc -l</pid>，对比业务正常时的基线值 - Python 内部检查：
import psutil; p = psutil.Process(); print(p.num_fds())（需安装psutil） - 观察趋势：在稳定请求下，句柄数是否随时间或请求数线性增长？这是泄漏的关键信号
静态代码扫描常见泄漏模式
重点检查以下易忽略的写法：
-
没有用
with语句的open()：如f = open('x.txt')；...；f.close()—— 中间异常时close()不会执行 -
函数提前返回但忘了关文件：在
if分支或return前遗漏f.close() -
循环中反复
open()却只在循环外close()：例如把f = open()放在 for 外，但每次循环都应处理新文件 -
日志、配置、临时文件等“不起眼”位置：比如
logging.FileHandler、configparser.read()、tempfile.mktemp()（已弃用）等也可能打开文件
运行时动态追踪文件对象
当静态检查无果，需在运行中捕获打开行为：
立即学习“Python免费学习笔记（深入）”；
- 重载内置
open函数，记录调用栈：import builtins, traceback<br> original_open = builtins.open<br> def tracked_open(*args, **kwargs):<br> print("OPEN:", args, kwargs)<br> traceback.print_stack(limit=3)<br> return original_open(*args, **kwargs)<br> builtins.open = tracked_open
放在程序启动最早处（如__main__.py开头），配合日志筛选高频/未配对的 open - 用
tracemalloc+ 自定义文件类辅助定位：为关键模块封装一个带 ID 和创建堆栈的TrackedFile类，替代裸open
利用工具辅助分析
借助成熟工具降低排查成本：
-
objgraph：跟踪io.TextIOWrapper或io.BufferedRandom等文件对象实例数量变化，结合objgraph.show_growth()查看增长源头 -
fil（File Descriptor Leak Detector）：专用于检测 Python 进程 fd 泄漏的轻量工具，支持自动采样与差异比对 -
IDE 静态检查：PyCharm 的 “File handle not closed” 检查项、VS Code + Pylint（
consider-using-with规则）可覆盖大部分明显问题
