无引用的已打开文件会自动关闭吗？非上下文管理器用法是否安全？

核心结论 #

两种写法在CPython常规场景下行为看似一致，但写法二依赖垃圾回收的隐式清理，存在不确定性风险，写法一（上下文管理器）是官方推荐的安全标准写法。

行为差异拆解 #

1. 写法一（with上下文管理器）

   with open("x.pickle", "rb") as fh:
       foo = pickle.load(fh)
   more_code()
   

   文件句柄fh会在with代码块结束时立即、确定性地被关闭——无论pickle.load是否抛出异常，Python都会自动执行文件对象的__exit__方法完成资源清理，这是Python设计中用于资源管理的标准范式。

2. 写法二（直接传递open对象）

   foo = pickle.load(open("x.pickle", "rb"))
   more_code()
   

   open返回的文件对象没有被变量持有，pickle.load执行完成后，该对象的引用计数归0。在CPython中，这会触发即时垃圾回收，进而调用文件对象的__del__方法关闭文件。但这是CPython的实现细节，而非Python语言规范的强制要求。

写法二的潜在风险 #

• 跨解释器兼容性问题：如果切换到PyPy、Jython等其他Python解释器，垃圾回收的时机是不确定的（比如PyPy采用分代回收，可能延迟清理），文件可能长时间处于打开状态，在高并发或文件操作频繁的场景下，容易触发Too many open files错误。
• 意外引用泄漏：如果pickle（或其他工具）内部不小心保留了文件句柄的引用（哪怕是间接引用），会导致文件对象无法被垃圾回收，进而造成资源泄漏，文件始终无法关闭。
• 异常场景的微小窗口：虽然pickle.load抛出异常时，文件对象的引用计数也会归0，但相比with语句的即时清理，仍存在极短的时间窗口可能导致文件未及时关闭，在某些严格的资源敏感场景下可能引发问题。

关于你的测试结果 #

你通过sleep+lsof测试发现文件已关闭，这是因为CPython的引用计数机制在对象无引用时会立即回收。但这只是特定解释器下的表现，不能代表所有场景的安全性。

最终建议 #

即使在看似无需操作文件句柄的场景，仍然优先使用with上下文管理器写法。它不仅符合Python“显式优于隐式”的设计原则，还能提供跨解释器一致的确定性资源清理，避免潜在的资源泄漏风险。

内容的提问来源于stack exchange，提问作者Zilk