本文介绍在 recyclerview 中使用 glide 加载网络图片时，如何合理利用内存缓存而非禁用磁盘缓存，从而避免滚动回退时图片重复加载、闪烁或重请求的问题。
在实现类似 Instagram 的动态信息流（Feed）时，开发者常误以为“禁用磁盘缓存”（DiskCacheStrategy.NONE）能提升新鲜度或节省空间，结果却导致 RecyclerView 滚动后图片反复重新加载——这是因为 Glide 的内存缓存（LruResourceCache）默认是启用的，但 DiskCacheStrategy.NONE 会同时绕过内存缓存的写入路径优化，且在 ViewHolder 复用时无法命中有效缓存键，尤其当 URL 相同但请求参数（如尺寸、变换）未显式一致时，缓存匹配失败。
✅ 正确做法是：移除手动禁用策略，让 Glide 使用默认行为：
// ✅ 推荐：简洁、安全、默认启用内存缓存 + 智能磁盘缓存
Glide.with(context)
.load(feed.getImgLink())
.into(holder.myImgView);Glide 默认采用 DiskCacheStrategy.AUTOMATIC，它会根据资源类型（如 JPEG/PNG）自动选择 RESULT（缓存处理后图像）或 DATA（原始数据），并始终配合高效的内存缓存。对于 Feed 场景，这意味着：
- 首次加载：下载 → 解码 → 缓存到内存（LRU）和磁盘（按需）；
- 滚动返回：直接从内存缓存快速读取，毫秒级显示，无闪烁；
- 磁盘缓存仅存储已解码的最终图像（非原始大图），体积可控，且受 Glide 自动清理机制管理（基于大小与时间）。
⚠️ 注意事项：
- 不要手动设置 .diskCacheStrategy(DiskCacheStrategy.NONE) 或 .skipMemoryCache(true)，除非有强理由（如实时性极高且图像极小）；
- 若需强制刷新某张图（如用户手动更新头像），可调用 .signature(ObjectKey) 添加版本标识；
- 对于高密度 Feed，建议搭配 override() 指定目标宽高，减少内存占用：
.override(RecyclerView.LayoutParams.MATCH_PARENT, 600) // 示例：适配预估高度
- 确保 feed.getImgLink() 返回稳定、无动态时间戳的 URL；若含临时 token，需通过 signature() 保证相同逻辑图像缓存复用。
总结：Glide 的默认缓存策略已在内存效率、磁盘开销与用户体验间取得最佳平衡。删掉 diskCacheStrategy(NONE)，回归简洁调用，即可解决滚动重载问题——既不浪费空间，也不牺牲性能。
