Python3 readline()疑似Bug：光标位置与实际写入位置不符

问题重现 #

测试环境：Windows 11 + Spyder IDE，Python 3

初始文件内容 #

txt.txt初始内容为两行：

1234567890
abcdefghij

正常写入场景 #

执行以下代码后，文件被正常修改：

g = open("txt.txt","r+")
g.write("xxx")
g.flush()
g.close()

修改后文件内容：

xxx4567890
abcdefghij

异常写入场景 #

执行以下代码时，写入的XXX出现在文件末尾而非预期的第一行之后：

g = open("txt.txt","r+")
g.readline()    # 输出: 'xxx4567890\n'
g.tell()        # 输出: 12
g.write("XXX")
g.flush()
g.close()

最终文件内容：

xxx4567890
abcdefghij
XXX

修复后的正常场景 #

在write前手动调用seek(12)后，写入位置恢复正常：

g = open("txt.txt","r+")
g.readline()    # 输出: 'xxx4567890\n'
g.tell()        # 输出: 12
g.seek(12)
g.write("XXX")
g.flush()
g.close()

最终文件内容：

xxx4567890
XXXdefghij

原因分析 #

这并非readline()的Bug，而是Windows文本模式下文件读写切换的缓冲区特性导致的：

• 默认r+模式为文本模式（未指定b），Windows系统的文本文件处理会维护读写缓冲区。
• 执行读操作（如readline()）后，tell()返回的是逻辑指针位置，但实际操作系统的文件指针会因缓冲区同步问题，在切换到写操作时自动跳转到文件末尾。
• 手动调用seek()会强制同步缓冲区与逻辑指针位置，让后续写入操作使用正确的指针位置。

解决方法 #

1. 读写切换前同步指针：在写操作前调用seek(g.tell())，无需额外参数即可同步当前逻辑指针与实际文件指针位置：

   g = open("txt.txt","r+")
   g.readline()
   g.seek(g.tell())  # 同步指针
   g.write("XXX")
   g.flush()
   g.close()
   

2. 使用二进制模式打开：改用rb+模式打开文件，二进制模式下不存在文本模式的缓冲区同步问题，读写切换时指针位置保持一致（需自行处理换行符\r\n）：

   g = open("txt.txt","rb+")
   line = g.readline().decode('utf-8')
   print(line)  # 输出: 'xxx4567890\r\n'
   g.write("XXX".encode('utf-8'))
   g.flush()
   g.close()
   

3. 避免交替读写：分开读、写操作流程，比如先读取所有内容到内存，关闭文件后再打开写入；或者使用两个独立的文件对象分别处理读和写。

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