Chrome任务管理器不直接显示“图像内存”，但图像资源占用计入Memory列；可通过观察Memory非线性增长、结合类型/任务定位图像密集进程、启用悬停提示筛查、配合DevTools堆快照与Performance面板进一步确认图像内存泄漏源。
Chrome 任务管理器本身不直接显示“图像内存”这一独立指标，它列出的是各进程的总内存（Memory）、JavaScript 堆（JavaScript Memory）、CPU 和网络使用情况。所谓“图像内存”——比如大量 <img> 加载、Canvas 绘图、WebGL 纹理、SVG 渲染等产生的原生图形资源——实际被计入 Memory 列（本机内存），尤其是 DOM 节点、渲染树、GPU 资源缓冲区等底层分配中。
但你可以通过任务管理器配合观察逻辑，间接识别图像相关内存异常波动。关键在于：图像密集型页面（如画廊、设计工具、地图、视频封面流）往往表现出特定的内存行为模式。
H3：看“Memory”列是否持续非线性增长
图像资源一旦加载，尤其未做懒加载或尺寸控制时，会显著拉升本机内存。若某标签页的 Memory 值在以下情况中缓慢爬升、不回落、且与用户操作强相关，就值得怀疑：
- 打开含 50+ 高清缩略图的网页后，Memory 从 200 MB 涨到 900 MB 并卡住；
- 滚动无限加载图集时，Memory 每次滚动增加 80–150 MB，且不随滚动停止而下降；
- 切换 Canvas 绘图模式（如滤镜实时预览）后，Memory 突增 300 MB 以上并维持高位。
⚠️ 注意：单次上涨不等于异常；需观察「操作→上涨→停止→是否回落」的闭环。若强制刷新页面后 Memory 仍远高于初始值，说明资源未释放，可能含未销毁的 ImageBitmap、未 release 的 WebGL 纹理或缓存的
<canvas>数据。
H3：结合“类型”和“任务”定位图像密集型进程
任务管理器中，重点关注以下几类条目：
-
类型为“标签页”且任务名含关键词：如
gallery.html、photos/、map/、editor/、webgl-demo； - 类型为“GPU 进程”或“渲染器”：若其 Memory 或 GPU 占用同步飙升，常意味着图像解码、合成或纹理上传压力大；
- 类型为“扩展”且名称可疑：如 “Image Downloader”、“Screenshot Tool”、“Photo Enhancer”，这类扩展常在后台批量解码图像，悄悄吃内存。
可右键点击任务管理器表头 → 勾选“GPU”列，辅助判断图像负载是否已传导至 GPU 层。
H3：用悬停内存提示快速筛查活跃标签页
Chrome 124+ 已默认启用该功能（旧版需在 chrome://flags 中开启 Memory usage on hover）。将鼠标悬停在任一标签页上，几秒后即显示实时内存值（如 384 MB）。
这对图像监控很实用：
- 打开新图库页 → 悬停看初始值；
- 滚动加载一批图 → 再悬停，对比涨幅；
- 关闭该页 → 观察其他页内存是否回落（验证是否真释放）。
若悬停值在关闭标签页后未明显下降，说明存在跨页引用或全局图像缓存未清理。
H3：配合 DevTools 进一步确认图像内存来源
任务管理器只能告诉你“谁占得多”，不能告诉你“为什么”。需接力使用开发者工具：
- 打开问题标签页 → 按
F12→ 切换到 Memory 面板 → 点击 Take Heap Snapshot； - 在快照中筛选
HTMLImageElement、ImageBitmap、CanvasRenderingContext2D、WebGLTexture等构造函数； - 查看对应对象的 Retained Size（保留大小），若单个
ImageBitmap达 50+ MB，或HTMLImageElement数量达数百且src未置空，基本可锁定图像泄漏； - 切换到 Performance 面板 → 勾选 Memory → 录制一段滚动/切换操作 → 查看 JS Heap 和 Nodes 曲线：若 Nodes 数量激增 + Heap 不降，大概率是
<img>节点未移除或document.createElement('img')后未remove()。
不复杂但容易忽略。图像内存问题很少孤立发生，通常伴随 DOM 节点堆积、事件监听器残留或 Canvas 缓存失控。任务管理器是你发现“不对劲”的第一道哨兵，后续再靠快照和录制深挖根因。
