原来一直误会了，蘑菇视频ios的缓存管理问题我终于定位到原因了

原来一直误会了，蘑菇视频 iOS 的缓存管理问题我终于定位到原因了

前言 很多用户向我们反馈：视频明明下载/播放过，缓存了但重启 app 后又需要重新加载；或者缓存突然变少、被系统清理掉，导致体验不稳定。排查了半个月，今天把问题找到了——不是 iOS 的“故意捣乱”，也不是第三方库的神秘 Bug，而是我们对缓存位置与 URLSession 临时文件机制的误解。下面把整个定位过程、根因、修复思路和实际落地方案整理成一篇，供自己和同样踩过坑的同事参考。

1）症状回顾（用户/日志表现）

• 用户端：已播放或“下载”的视频，下次打开依然需要重新加载、重新下载。
• 日志：下载任务完成后没有明显的写盘错误；但是在文件系统里找不到期望的缓存文件，或者文件存在但很快被删除。
• 设备状态：发生在磁盘空间紧张或正常时都有，且多集中在短期内（应用重启/系统回收后问题显现）。

2）定位思路与排查步骤

• 检查下载流程：是用 URLSessionDownloadTask 还是 dataTask？
• 在下载完成回调里打印临时文件路径、目标路径，确认文件是否被移动或复制。
• 监控文件创建目录：看看缓存文件实际写入的是 Library/Caches、tmp 还是 Application Support。
• 检查是否设置了文件属性（比如 NSURLIsExcludedFromBackupKey）。
• 看看是否有定时清理（自己实现的缓存清理、第三方库的自动清理）会在不恰当时机触发。
• 仔细查看后台/下载队列的实现：有没有把文件写到了 tmp 或直接依赖 downloadTask 返回的临时 URL。

3）找到的根本原因（结论） 主要原因是：我们把来自 URLSessionDownloadTask 的“临时文件”误当成了持久缓存，或者直接把缓存写入了 tmp（NSTemporaryDirectory），而没有把文件移动到 Library/Caches（或其他持久目录）。URLSession 的 downloadTask 会在完成后把数据写到一个临时目录，系统或 URLSession 有时会清理这些临时文件；同样，tmp 目录是随时可被系统回收的，不适合长期缓存。有部分逻辑在失败分支忽略了移动文件的操作，导致文件只存在于临时位置，进程结束后自然丢失。

简而言之：误把临时存储当成了持久缓存，结果“被系统清理”看似是 iOS 的问题，实则是我们的实现不对。

4）修复方案（立即可落地）

• 一律把需要长期保留的缓存文件移动到 Library/Caches（FileManager.urls(for: .cachesDirectory, in: .userDomainMask)）。
• 在 move 后设置合适的文件属性（例如不需要备份到 iCloud，则设置 NSURLIsExcludedFromBackupKey 为 true）。
• 对下载回调中的临时 URL 做显式移动或复制操作；别依赖临时文件在下一次启动时还存在。
• 为缓存设定上限并实现 LRU/时间戳清理机制；在磁盘空间紧张时优先清理旧数据。
• 让后端返回合理的缓存控制头（Cache-Control, ETag），配合 URLCache 做 HTTP 层缓存（用于缩短加载、节省流量）。

5）关键代码示例（Swift，核心片段） 在 URLSession downloadTask 完成时，把临时文件移动到 Caches：

let fm = FileManager.default let cachesDir = fm.urls(for: .cachesDirectory, in: .userDomainMask)[0] let destination = cachesDir.appendingPathComponent("video_cache/(fileName)")

do { try fm.createDirectory(at: destination.deletingLastPathComponent(), withIntermediateDirectories: true, attributes: nil) // 如果目标已存在，可选择覆盖或跳过 if fm.fileExists(atPath: destination.path) { try fm.removeItem(at: destination) } try fm.moveItem(at: tempLocalUrl, to: destination)

// 设置不备份到 iCloud
var resourceValues = URLResourceValues()
resourceValues.isExcludedFromBackup = true
try destination.setResourceValues(resourceValues)

} catch { // 记录错误，必要时尝试复制而非移动 print("缓存写入失败：(error)") }

注意点：

• 使用 move 而不是复制可以避免多余磁盘占用；但如果需要保留临时文件，使用 copy。
• 确保在多线程/并发下载时对同一路径做并发控制，避免竞态。

6）进一步完善（防止未来再出问题）

• 为缓存实现大小统计和自动回收：在写入时更新 metadata（最后访问时间、大小），定期（或在启动时和磁盘告警时）按 LRU 策略清理到阈值以内。
• 优先利用系统提供的 URLCache 做 HTTP 缓存（对图片、静态资源有帮助）；但对大文件（视频）推荐自己管理文件存储，避免 URLCache 带来的不确定性。
• 对于需要离线播放的视频，可以采用 AVAssetDownloadURLSession 或专门的离线下载模块，保证下载完整性与后续播放兼容性。
• 加入完整的可观察日志：下载临时路径、移动结果、最终缓存路径、缓存大小变更，这些在后续定位非常有帮助。
• 在文档/代码注释中明确：tmp 可随时被系统回收，Caches 会被系统在磁盘紧张时清理，但更适合作为长期缓存；Application Support 适合不可或缺但不需要备份的数据（视具体场景）。

7）对用户体验的补救（线上方案）

• 修订新版本的缓存逻辑并在更新日志中说明修复（简短描述体验改善即可）。
• 对已受影响的用户：可以在 app 内提供一次“缓存修复/重建”功能，避免用户手动操作。
• 监控更新后缓存命中率、带宽使用、用户反馈，确认修复效果。

结语 这次追查让我意识到一个简单但常见的真相：很多缓存问题并不是系统“莫名其妙地”删东西，而是我们把短期存储当成长期存储。理解各个目录的语义、URLSession 的临时文件生命周期以及文件属性的设置，能大幅降低这类问题。现在把缓存逻辑改好后，蘑菇视频的离线与重复加载问题已经有明显改善，接下来会把 LRU 管理和更完善的监控补上，避免类似回归。