为何两段高度相似的Python代码执行结果差异巨大？

下面两段Python代码逻辑高度相似，但执行结果截然不同，我们结合Windows平台的文件操作特性来分析原因：

代码示例与输出 #

代码1 #

with open("new.txt", 'w+') as f:
    f.write("this is a line")

with open("new.txt", 'r+') as f:
    f.write("***")
    f.read()  # 读取到文件末尾
    f.seek(0)
    print(f.read())

输出：

***s is a line

代码2 #

with open("new.txt", 'w+') as f:
    f.write("this is a line")

with open("new.txt", 'r+') as f:
    f.write("***")
    f.read(1)  # 仅读取1个字符
    f.seek(0)
    print(f.read())

输出：

this is a line***

Python版本：Python 3.10.6 (tags/v3.10.6:9c7b4bd, Aug 1 2022, 21:53:49) [MSC v.1932 64 bit (AMD64)] on win32

原因分析 #

核心问题出在Windows平台文本模式下，文件读写交替时的未定义行为：

1. Python官方文档明确说明：在文本模式下（默认打开方式，无b参数），如果在写操作后没有调用flush()或seek()就直接执行读操作，其行为是未定义的，具体表现取决于操作系统的文件API实现。

2. 针对两段代码的差异：

   • 代码1：f.write("***") 后执行 f.read()，该操作会读取从当前指针位置到文件末尾的所有内容，最终将指针移到EOF（文件末尾）。在Windows平台的Python实现中，这种读取到EOF的操作会隐式触发缓冲区同步或指针校准，使得之前的写操作（覆盖文件前3个字符）生效，因此后续seek(0)读取到的是覆盖后的完整内容。
   • 代码2：f.write("***") 后执行 f.read(1)，仅读取1个字符就停止，指针未到达EOF。这种情况下，Windows的文件API没有触发缓冲区的同步校准，导致之前的写操作内容被暂存在缓冲区中；当文件被with块自动关闭时，缓冲区的内容被写入到当前指针所在的文件末尾位置（而非最初的开头位置），最终文件内容变为原字符串追加***。

总结 #

如果要避免这种未定义行为，在文本模式下进行读写交替操作时，必须在写操作后显式调用f.flush()或f.seek()来同步缓冲区和指针位置，再执行读操作。

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