本文介绍在 recyclerview 中使用 glide 加载网络图片时，如何在不启用磁盘缓存的前提下，利用 glide 默认的内存缓存机制防止滚动回退时图片重复加载，提升列表流畅性与用户体验。
在实现类似 Instagram 的动态信息流（Feed）时，开发者常希望图片仅作一次性展示，避免长期占用设备磁盘空间，因此倾向于禁用 Glide 的磁盘缓存（如设置 DiskCacheStrategy.NONE）。但此举会带来一个典型问题：当用户向下滚动后又快速回滚时，图片无法从磁盘重建，而若内存缓存也未被合理利用，Glide 就会重复发起网络请求，导致闪烁、延迟甚至重复下载——这正是你遇到的“上滑回来时图片重新加载”现象。
根本原因在于误用了缓存策略：DiskCacheStrategy.NONE 确实禁用了磁盘缓存，但它同时禁用了源资源（SOURCE）和结果（RESULT）的磁盘缓存逻辑，却并未干扰内存缓存；而 Glide 默认始终启用内存缓存（LruResourceCache），只要图片尺寸、变换、目标 View 等关键参数一致，同一 URL 的图片在内存中仍可被命中复用。问题往往出在：你主动关闭了磁盘缓存，却未意识到——移除 .diskCacheStrategy(...) 调用本身，反而是最佳实践。
✅ 正确做法是：完全删除 diskCacheStrategy(DiskCacheStrategy.NONE)，直接使用 Glide 默认配置：
// ✅ 推荐：依赖 Glide 默认行为（内存缓存开启 + 智能磁盘缓存策略）
Glide.with(context)
.load(feed.getImgLink())
.into(holder.myImgView);Glide 默认采用 DiskCacheStrategy.AUTOMATIC（自 4.0+ 版本起），它会根据图像来源（网络、本地文件等）自动选择最优缓存策略：对网络图片，默认仅缓存处理后的最终结果（RESULT），且带智能过期与大小限制，既保障快速复用，又避免无节制占用磁盘。对于 Feed 场景，这种策略已足够轻量——它不会永久保存图片，也不会在每次滑动时重复解码，更不会因手动禁用而“连带削弱”内存缓存效果。
⚠️ 注意事项：
- 不要为“节省磁盘”而盲目禁用磁盘缓存：现代 Glide 的磁盘缓存是带 LRU 清理、大小上限（默认 250MB）和时效管理的，实际开销可控；
- 若坚持禁用磁盘缓存，请改用 DiskCacheStrategy.DATA（仅缓存原始字节）或 DiskCacheStrategy.RESOURCE（仅缓存解码后 Bitmap），而非 NONE；
- 确保 holder.myImgView 在复用前已被正确重置（例如在 onBindViewHolder() 开头调用 imageView.setImageResource(0) 或 setImageDrawable(null)），避免旧图残留干扰内存缓存匹配；
- 对于高密度 Feed，建议配合 override() 指定目标尺寸，减少内存 Bitmap 占用，并启用 centerCrop() 等变换提升一致性。
总结：Glide 的默认缓存策略已为 RecyclerView 场景深度优化。删掉 diskCacheStrategy(DiskCacheStrategy.NONE)，回归简洁调用，即可在零额外配置下享受内存缓存带来的无缝复用体验——这才是 Instagram 式 Feed 流畅滚动的关键所在。
