根本原因是异常导致close()被跳过；open返回的文件对象绑定系统文件描述符，垃圾回收不可靠，with通过__exit__确保任何退出路径下都执行关闭。
open后没用with，异常一抛就漏
根本原因不是“没写异常处理”，而是close()调用被跳过。Python 的 open() 返回一个文件对象，它背后绑着操作系统级的文件描述符；这个描述符不会因为对象被垃圾回收就立刻释放——尤其在异常打断执行流时，close() 根本没机会运行。
常见错误模式：
-
f = open('log.txt', 'a'); f.write(data); f.close()—— 如果write()抛出IOError（如磁盘满），f.close()永远不执行 - 函数里提前
return或raise，但close()写在最后几行 - 多层嵌套逻辑中，某个分支遗漏了
close()，而该分支又确实会被触发
为什么不能靠垃圾回收兜底
CPython 用引用计数，文件对象一旦失去所有引用，__del__ 会尝试关闭描述符——但这不可靠：
- 循环引用存在时，引用计数不为 0，GC 可能延迟数秒甚至更久才清理
- 其他 Python 实现（如 PyPy、Jython）不保证
__del__被调用，或调用时机完全不同 - 进程打开的文件描述符有系统上限（Linux 默认常为 1024），等 GC 不如等超时
with 语句怎么堵住这个洞
with open(...) 的本质是调用上下文管理器的 __exit__ 方法，它在任何退出路径下（正常结束、return、异常抛出）都会被强制执行。这和手动写 try/finally 效果一致，但更简洁、不易漏。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
立即学习“Python免费学习笔记（深入）”；
对比写法：
# 错误：异常时 close() 失效
f = open('data.bin', 'rb')
data = f.read(1024 * 1024) # 可能 MemoryError
f.close() # 这行被跳过
<h1>正确：无论 read 是否成功，文件都关</h1><p>with open('data.bin', 'rb') as f:
data = f.read(1024 * 1024)
哪些场景下 with 也不够用
不是所有文件操作都能塞进 with 块。比如你需要把文件对象传给另一个函数处理，或需要跨多个不连续作用域读写——这时必须显式管理生命周期：
- 用
contextlib.closing()包装非上下文对象：from contextlib import closing; with closing(os.fdopen(fd, 'w')) as f: - 自定义类实现
__enter__/__exit__，确保资源释放逻辑集中可控 - 避免把裸
file对象存进全局 list/dict/缓存——它们可能长期存活，且难以追踪关闭时机
真正危险的从来不是“一时忘了关”，而是“以为关了”或者“以为 GC 会替你关”。文件描述符泄漏往往在压测或长周期服务中才暴露，排查时已难复现。最稳妥的做法，是让关闭这件事脱离人的记忆和控制流判断。
