为何Python生态系统中的文件IO存在不一致性？

先看CSV、JSON这类文本格式的标准读取逻辑：
读取CSV时，我们会先创建文件对象，再传给CSV读取器：

file = open(path)
reader = csv.reader(file)

读取JSON的思路也完全一致：

file = open(path)
data = json.load(file)

这种设计非常贴合面向对象和模块化的思路——CSV、JSON本质是带格式规则的文本文件，基于通用的file对象构建逻辑，能完整保留文件对象的功能与灵活性。如果为了少写一行代码改成直接传路径（比如csv.reader(path)），反而会丢失自定义编码、手动管控文件生命周期等关键能力，显然得不偿失。

但处理二进制图像文件的库（比如OpenCV、PIL）却采用了不同的逻辑：它们通常直接接收文件路径作为参数，而非先打开的文件对象。比如OpenCV读取图像：

image = cv2.imread(path)

而非：

file = open(path, 'rb')
image = cv2.imread(file)

PIL/Pillow的使用逻辑也类似，虽然它支持传入文件对象，但多数场景下开发者还是直接传路径。

那图像库为什么不遵循标准IO的抽象模式？难道它们没法利用标准库字节IO的优势吗？

核心原因其实是多维度的权衡：

• 底层实现兼容性：多数图像库的底层是C/C++实现（比如OpenCV依赖libjpeg、libpng等原生库），这些底层库本身就支持直接从文件路径读取数据，封装成Python接口时直接沿用该逻辑，既能降低开发成本，也能保证性能。
• 二进制文件的特殊性：图像文件需要解析文件头、压缩格式、色彩空间等复杂信息，直接操作路径能让库内部更高效地管理文件指针、分配内存，避免Python层文件对象带来的额外开销。
• 灵活性并未缺失：大部分图像库其实也支持传入文件对象（比如PIL的Image.open()可以接受BytesIO或二进制文件对象），只是直接传路径是更易用的简化写法，若需要从内存流（比如网络下载的字节数据）读取图像，依然可以利用字节IO的能力。
• 易用性优先：对普通开发者来说，直接传路径比先打开文件再传对象更直观，减少了代码量，降低了使用门槛。

所以这种设计并非图像库无法利用标准字节IO的优势，而是在性能、兼容性、易用性之间做出的合理平衡——既保留了简便的路径调用方式，也没有完全放弃对文件对象的支持。

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