结论：只有二进制模式（如'rb'、'wb'）下显式设置buffering才真正生效；文本模式下该参数被io.textiowrapper接管，外部指定值仅作参考或被忽略。
Python中open()的buffering参数到底怎么设才有效
直接说结论：只有在以二进制模式（'rb'、'wb'等）打开文件时，显式设置buffering参数才有实际意义；文本模式下Python会强制使用io.TextIOWrapper，缓冲行为由其内部逻辑控制，外部指定的buffering值会被忽略或仅作参考。
常见错误是给open('file.txt', 'r', buffering=8192)加了参数却没观察到性能变化——因为这是文本模式，底层实际用的是默认4096字节的io.BufferedReader包装器，且换行符处理会频繁触发缓冲区刷新。
- 想真正控制底层缓冲区大小，必须用
open(..., 'rb')或'wb' -
buffering=1在文本模式下启用行缓冲，但不等于“缓冲区大小为1字节”，而是指遇到\n就刷；在二进制模式下buffering=1无效，会被视为buffering=0（无缓冲） -
buffering=0只允许用于二进制模式，此时所有read()/write()调用直通系统调用，无Python层缓冲——适合小量随机访问，但对顺序大文件读写反而更慢
大文件顺序读取时，缓冲区设多大才合适
不是越大越好。Linux/Unix系统中，内核页大小通常为4KB，磁盘I/O调度器也倾向处理4KB–128KB范围的块；Python默认的8192字节（8KB）已能较好匹配硬件特性。盲目设成buffering=1024*1024（1MB）可能引发内存浪费，尤其在多线程/多进程并发打开大量文件时。
实测建议：
- 普通SSD/机械盘顺序读：保持默认
buffering=-1（自动选择）或显式设为8192～65536 - 网络文件系统（如NFS、S3 via fsspec）：可尝试增大到
262144（256KB），减少RPC往返次数 - 内存受限环境（如嵌入式）：设为
4096或2048，避免单次read()阻塞过久
注意：buffering只影响Python解释器层的缓冲策略，不影响操作系统page cache行为——后者由内核自动管理，无需也不应通过Python干预。
用io.BufferedWriter手动包装时如何避免双重缓冲
当需要精细控制（比如带进度回调的写入），有人会这样写：
f = open('out.bin', 'wb', buffering=0)
writer = io.BufferedWriter(f, buffer_size=65536)这会导致两层缓冲：底层open()已禁用缓冲（buffering=0），但BufferedWriter又建了一层——不仅没提速，还因多余拷贝降低性能。
正确做法是让其中一层接管全部缓冲职责：
- 若用
io.BufferedWriter，则open()必须用buffering=0，把原始文件对象交给它管理 - 若依赖
open()内置缓冲，就别再套BufferedWriter，直接用返回的文件对象 - 需要回调时，可用
iter(lambda: f.read(65536), b'')分块读取，配合sys.stdout.write()等实时输出，不引入额外缓冲层
Windows上buffering的特殊表现
Windows的CRT（C运行时）对文件I/O有额外缓冲层。即使Python层设了buffering=0，某些情况下仍可能观察到延迟写入——特别是重定向到控制台或管道时。此时需配合os.fsync()或file.flush()确保落盘。
另一个坑：buffering值若小于系统最小缓冲区（Windows通常为512字节），会被静默上调至该值，不会报错。所以设buffering=100和buffering=512在Windows上效果完全一样。
跨平台脚本若需强一致性，建议统一用buffering=8192或buffering=-1，避免在不同系统上因底层差异导致行为漂移。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
