Firebase Storage存储文件数小时后无日志自动删除问题求助

以下是同类问题开发者实际踩过的根因和对应排查路径，按出现概率从高到低排列：

• 排查临时存储桶规则覆盖问题
  不要只检查Firebase控制台展示的默认存储桶生命周期配置：Firebase项目关联的GCP存储体系里，会自动生成带staging.、tmp.前缀的临时存储桶，这类桶默认配置了数小时到7天的自动删除规则。如果你的上传代码里填错了bucket参数，把文件传到了临时桶，哪怕你把默认桶的生命周期规则全关了，文件还是会按临时桶规则被清掉。直接去GCP存储控制台，把当前项目下所有存储桶的生命周期规则逐一核对，同时检查上传代码里的bucket引用是否指向了目标正式桶。
• 排查Cloud Functions的误删除逻辑
  大部分无日志删除都是Storage触发器的函数逻辑bug导致的：很多人写过监听文件上传的onFinalize触发器做转码、缩略图生成、垃圾文件清理，逻辑里如果写了路径通配符匹配错误、临时文件和原文件路径判断逻辑写错，会直接把原上传文件当成临时文件执行删除。这类函数内触发的删除如果没主动加日志，Storage默认日志不会记录关联的函数信息。你需要把所有绑定Storage触发器的函数全部过一遍，找到所有调用file.delete()的代码块，临时加日志打印所有待删除文件的完整路径，跑几小时对照日志看是否匹配到被删的原文件。
• 排查未完成的分片上传自动清理
  如果你用的是客户端/服务端SDK的分片续传功能，上传流程最后一步的合并请求没发成功（比如客户端断网、服务端超时），那些已经上传的分片块会被Firebase在上传会话过期后（默认1天内，最短几小时）自动清理，这类系统级的分片清理不会出现在普通操作日志里。排查时可以在文件上传完成后立刻调用getMetadata()接口，核对返回的文件大小、md5值和本地原文件是否一致，确认文件真的完成了完整上传，不是残留的分片块。
• 排查已安装的Firebase Extension默认配置
  如果你装过图片自动优化、旧文件清理、用户上传内容审核这类官方/第三方Extension，大部分这类扩展默认带自动清理规则，比如“删除上传超过X小时未通过审核的文件”“清理处理完成的临时原文件”，很多人安装时直接点下一步没改配置，后续忘了这个规则的存在。去Firebase扩展管理页，逐个看已装扩展的参数配置，关掉不需要的自动删除逻辑。
• 排查客户端误删逻辑
  如果以上都没查到问题，临时开Storage的管理员审计日志，等下一次文件被删除时看操作主体：如果是普通用户账号发起的删除请求，去查客户端代码里的Storage引用逻辑，很多人写本地缓存清理时误把云端文件引用当成了本地缓存文件，调用了delete方法触发云端删除，这类操作没开审计日志的话完全查不到来源。

快速定位小技巧：上传测试文件时给文件加唯一自定义元数据标记，比如track-id: 你的自定义唯一值，后续所有日志里搜这个标记，能快速定位到是哪个环节触发了删除操作。

内容的提问来源于stack exchange，提问作者Karol Wojtulewicz