为何同一循环中PIL图像读取+裁剪耗时远高于分步耗时之和？

核心原因是PIL的Image.open()采用懒加载机制：调用该方法时，并不会立刻从磁盘读取并解码图像的像素数据，仅仅是创建一个指向图像文件的对象。只有当你执行裁剪、获取像素值、调整尺寸等需要访问实际像素的操作时，才会真正触发文件读取与解码流程。

逐个循环分析： #

• 第一个循环：仅重复创建100个Image对象，没有触发任何实际的图像数据读取/解码操作，因此耗时极短（仅9ms）。
• 第二个循环：复用了第一个循环最后一次创建的hr对象——在该循环第一次执行hr.size或hr.crop时，已经完成了图像文件的读取和解码，像素数据被加载到内存中。后续99次裁剪操作都是直接对内存中的数据进行处理，因此总耗时仅88ms。
• 第三个循环：每次循环都先调用Image.open()创建新对象，紧接着执行crop操作。每次crop都会触发一次完整的「磁盘读取文件→解码图像→裁剪」流程，相当于重复执行了100次完整的图像加载+裁剪操作，因此耗时（7093ms）远高于前两个循环的耗时之和。

验证方法（可选） #

如果在第一个循环中添加hr.load()强制加载图像数据，第一个循环的耗时会骤增，接近第三个循环的单轮耗时：

a = time.time()
for _ in range(100):
    hr = Image.open('tests/0801.png')
    hr.load()  # 强制加载像素数据到内存

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