本文讲解如何在 recyclerview 中合理使用 glide 加载网络图片，既避免滚动时重复加载闪烁，又不滥用磁盘缓存占用用户存储空间。核心在于理解 glide 默认内存缓存机制，并正确配置缓存策略。
在实现类似 Instagram 的动态信息流（Feed）时，开发者常遇到一个典型问题：图片首次加载正常，但上下滚动后回到原位置时图片“重新加载”、出现闪烁或延迟——这并非真正未缓存，而是因手动禁用了磁盘缓存（DiskCacheStrategy.NONE），同时未意识到 Glide 的内存缓存（Memory Cache）默认是启用的且完全足够应对快速复用场景。
你当前的代码：
Glide.with(context)
.load(feed.getImgLink())
.diskCacheStrategy(DiskCacheStrategy.NONE) // ❌ 不必要地禁用磁盘缓存
.into(holder.myImgView);虽然 DiskCacheStrategy.NONE 可防止图片长期驻留磁盘，但它并不会增强内存缓存效果，反而可能干扰 Glide 的资源复用逻辑（例如跳过部分缓存键校验）。更重要的是：RecyclerView 滚动复用 ViewHolder 时，Glide 本就依赖内存缓存（LruResourceCache）快速提供已解码 Bitmap —— 这一过程毫秒级完成，无需磁盘 I/O。
✅ 正确做法是：移除显式 diskCacheStrategy(NONE)，交由 Glide 默认策略智能管理：
Glide.with(context)
.load(feed.getImgLink())
.into(holder.myImgView); // ✅ 使用默认策略：ALL（含内存+磁盘），但磁盘缓存自动按需清理Glide 默认采用 DiskCacheStrategy.AUTOMATIC（自 Glide 4.0+），它会根据图片来源（如网络 URL）自动选择 DiskCacheStrategy.RESOURCE（缓存处理后的图片），兼顾性能与空间。该策略下：
- 首次加载：下载 → 解码 → 缓存至内存 + 磁盘（压缩格式，体积小）；
- 滚动复用：优先命中内存缓存（无延迟）；
- 后续冷启动/重复访问：命中磁盘缓存（比网络快数倍，且不耗流量）；
- 磁盘缓存有 LRU 清理机制，不会无限增长。
⚠️ 注意事项：
- 若坚持“纯一次浏览不落盘”，DiskCacheStrategy.NONE 并非最优解 —— 它可能导致同一张图在不同 ViewHolder 中被重复解码，增加 GC 压力和 UI 卡顿；
- 如需精细控制，可用 skipMemoryCache(true)（禁用内存缓存，极不推荐）或 diskCacheStrategy(DiskCacheStrategy.DATA)（仅缓存原始字节），但通常无必要；
- 确保 ImageView 尺寸固定或使用 override(width, height)，避免因尺寸变化导致缓存失效；
- 在 Adapter 的 onBindViewHolder 中，建议添加占位图与错误图提升体验：
Glide.with(context)
.load(feed.getImgLink())
.placeholder(R.drawable.ic_image_placeholder)
.error(R.drawable.ic_broken_image)
.into(holder.myImgView);总结：Glide 的默认缓存策略已在内存效率、磁盘空间与加载速度间取得良好平衡。盲目禁用磁盘缓存不仅不能解决“滚动重载”问题，反而削弱了框架优化能力。只需回归简洁调用，配合合理的 ImageView 配置，即可实现丝滑 Feed 流体验。
