大图加载导致内存上涨，应该先观察哪些指标？

相册或商品列表一滚动，内存明显上涨。第一反应往往是“图片泄漏了”，接着开始清缓存，最后曲线还是看不懂。

核心结论：先同时观察原图像素、目标解码尺寸、ImageCache、Dart Heap 和进程总内存，再判断是正常峰值、缓存没有边界，还是对象真的无法释放。只看一条内存曲线，不能证明泄漏。

文件不大，不代表解码后不大

JPEG、WebP 文件看到的是压缩体积，显示前通常需要解码成像素数据。以常见的每像素 4 Byte 粗略估算，一张 4000 × 3000 的图片需要：

4000 × 3000 × 4 bytes ≈ 45.8 MiB

解码期间还可能同时存在压缩字节、中间缓冲和绘制资源，实际大小也受像素格式与平台实现影响。

所以先看原图像素、显示尺寸、设备像素比和同时解码数量，不要只看文件多少 KB。

先固定一个可以重复的场景

在目标真机的 Profile 或 Release 模式下，固定图片数据和操作步骤，记录四个时间点：

进入页面前的基线；
首批大图解码时的峰值；
滚动停止后的稳定值；
退出页面并等待一次 GC 后的新基线。

重复操作数轮。第一次上涨后进入平台不等于泄漏；每轮结束基线仍继续抬高，才需要查缓存和引用链。最终结论不要来自 Debug 模式或模拟器。

第一批指标：图片是否解码过头

先记录这些数据：

图片原始像素尺寸，而不是网络文件大小；
Widget 的逻辑尺寸和设备 devicePixelRatio；
实际请求的解码宽高；
可见、预加载和并发解码的图片数量；
是否包含多帧动图，或同一图片的多个解码尺寸。

宽 120 逻辑像素的缩略图，在 DPR 为 3 的设备上，目标宽度通常接近 360 物理像素，而不是 4000 像素的原图宽度。

final devicePixelRatio = MediaQuery.devicePixelRatioOf(context);
final decodeWidth = (120 * devicePixelRatio).ceil();
 
Image.network(
  product.thumbnailUrl,
  width: 120,
  height: 90,
  fit: BoxFit.cover,
  cacheWidth: decodeWidth,
)

这里只限制宽度以保留原始比例。BoxFit.cover 与裁剪场景仍要保证解码像素足够覆盖显示区域。服务端能提供缩略图时，也能减少网络与解码成本。

cacheWidth、cacheHeight 会提示引擎按指定尺寸解码；Flutter Web 会忽略这两个参数，因为解码交给浏览器处理。

第二批指标：缓存和 Dart Heap 在涨什么

排查期间可以临时记录 Flutter 图片缓存状态：

void logImageCacheState() {
  final cache = PaintingBinding.instance.imageCache;
  debugPrint(
    'images=${cache.currentSize}, '
    'live=${cache.liveImageCount}, '
    'pending=${cache.pendingImageCount}, '
    'bytes=${cache.currentSizeBytes}',
  );
}