Python中`txt = open('file.txt').read()`是否劣于`with`写法？文件何时关闭？

txt = open('file.txt').read()的写法确实比with open(...)的写法更差，哪怕它在绝大多数日常场景下碰巧能完成文件关闭，也不代表这种写法是合理的、with是多余的。

你猜测的“没有引用就立刻关闭文件句柄”，本质是依赖CPython（日常用的官方Python解释器）引用计数机制的巧合，从来不是Python语法层面强制保证的行为：

• 在CPython环境下，这行代码执行时，open()返回的文件对象没有被任何变量持有持久引用，当.read()执行完成、读取到的字符串被赋值给txt后，这个临时文件对象的引用计数会降到0，触发对象析构流程，顺带执行文件关闭操作。注意：这不是“读取完成就立刻关句柄”，是临时对象被垃圾回收时的附带动作，只是这个回收动作恰好紧跟在read()后面而已。
• 这种逻辑根本不具备通用性：换到PyPy、Jython、IronPython等采用追踪式垃圾回收的解释器中，文件对象的回收时机完全由GC的扫描周期决定，可能隔几秒甚至更久才会触发回收，文件句柄会一直被占用。哪怕在CPython中，不同版本的栈帧临时引用存储逻辑，也可能让文件对象的销毁时机延后到整个函数执行结束，根本不是你以为的“读完就马上关”。

很多人觉得“反正最后GC会帮我关”，本质是把这种极端理想化的单行测试场景，套到了所有实际生产代码上——一旦逻辑稍微复杂一点，这种“靠GC兜底”的逻辑根本不可靠：
文件句柄是操作系统层面的有限资源，单个进程能打开的文件数有明确硬上限。靠GC随机时机回收句柄的节奏，根本赶不上你大量开启文件的速度，很容易在高并发、循环批量处理文件的场景下触发Too many open files的系统错误，这类问题本地单线程测试根本复现不出来，到生产环境才会暴露。

• 关闭时机完全不可控：跨解释器、跨Python版本时，文件什么时候被关闭没有任何确定规则。在Windows系统上，未及时关闭的文件句柄会把文件锁定，其他进程无法修改、删除，报出毫无头绪的权限错误。
• 存在数据丢失风险：如果是写文件场景，采用open('a.txt').write('内容')这类不带with的写法，写入的数据一开始是存在内存缓冲区中的，只有执行close操作时才会把缓冲区内容真正刷入磁盘。如果中途触发异常、文件对象没有被及时回收，缓冲区的数据根本不会落盘，最终留下空文件。
• 无强制资源保障：with语句是Python语法层面实现的上下文管理逻辑，无论块内代码执行成功、抛出异常、还是中途触发return，只要离开with块，一定会执行文件关闭操作，确保资源被释放。这种确定性的保障，是靠GC碰巧回收的写法永远无法提供的。
• 增加代码协作成本：任何协作者看到不带with的open操作，第一反应都是“是不是漏了文件关闭逻辑”，不需要去逐行分析你是不是临时使用句柄，这类写法在正式项目的编码规范中本来就是明确禁止的。

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