为何Python流方法在底层文件被删除时不抛出异常？

当使用Python文件流时，发现底层文件被os.remove()删除后，write、close、writable等方法并未抛出异常。这种不符合直觉的行为可能导致应用误以为关键日志写入成功，实际文件已不存在。以下是Python 3.10.7下的示例代码：

import os
from os.path import exists

p = "./myfile.txt"
f = open(p, "w")
f.write("Here is my content\n")
f.flush()
os.remove(p)
print(exists(p))  # False (as expected)
print(f.writable())  # True - but 'myfile.txt' has been deleted!
f.write("Some more content")  # Does not raise an exception!
f.flush()  # Does not raise an exception
exists(p)  # Still False - which is expected (and I confirmed there is no file at path "p")
f.close()  # Does not raise an exception!
# Line below fails with "ValueError: I/O operation on closed file."  That is consistent with the documentation for
# "close()" in the io module.
f.write("This better fail!")

行为合理性分析 #

这种行为并非Python的设计问题，而是基于操作系统文件系统的核心特性：

• 路径与文件数据分离：os.remove()仅删除了文件系统中指向文件数据的目录条目（路径），但进程持有的内核文件描述符依然有效。只有当所有打开该文件的进程都关闭句柄后，操作系统才会真正回收文件占用的磁盘空间。
• 系统调用直接映射：Python的文件操作直接封装了操作系统的系统调用，write、flush本质是调用OS的write()、fsync()接口——只要文件描述符有效，这些调用就会成功，不会额外检查文件路径是否存在。
• writable()的检查逻辑：该方法仅验证文件对象自身的状态（是否以可写模式打开、是否已关闭），不会去确认底层文件路径的存在性，因此文件被删除后仍返回True。

是否为Python特有行为？ #

这不是Python特有，而是类Unix操作系统（Linux、macOS等）下文件I/O的普遍行为。Windows系统表现略有差异：若文件在打开状态被删除，后续write操作可能抛出异常，但这是Windows文件系统的特性区别，而非Python的差异。

规避建议 #

如果需要确保文件路径存在才能写入，可在关键操作前主动调用os.path.exists()检查，但需注意检查与写入之间存在竞态条件。更可靠的方式是使用文件系统通知机制（如Linux的inotify）监听文件状态变化，或采用文件锁、原子写入等方案保障数据完整性。

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