Firebase读写量无诱因暴增致配额耗尽，求排查方案

问题背景 #

应用因触发Firebase配额上限停止运行，控制台显示近两日数据库读写量无明显诱因暴增，但用户量、内容量未出现增长。正常与过载状态的单日数据对比：

• 正常状态：
• 过载状态：

排查代码未发现数据库相关改动，但FeedViewModel中的fetchPosts和fetchStories方法被执行了约40次，疑似是读写量暴增的根源。

1. 排查FeedViewModel的实例化次数 #

• 打印init方法日志，统计ViewModel实际被创建的次数，确认是否与40次请求对应。
• 检查SwiftUI视图中ViewModel的初始化方式：如果在body内直接初始化FeedViewModel()，会导致视图每次重绘都创建新实例，重复触发数据请求；应改用@StateObject在父视图初始化，确保全局唯一实例。

2. 追踪@Published属性的更新触发逻辑 #

• posts和stories作为@Published属性，每次赋值或内部元素修改都会触发视图更新，可能间接导致ViewModel重复初始化或请求重复执行。
• 在posts和stories的赋值处添加日志，查看是否存在意外的重复赋值行为。

3. 修复N+1查询与重复请求问题 #

• 当前代码存在N+1查询漏洞：每获取一篇post/story就发起一次单独的用户查询，若有20篇post则触发20次用户请求，叠加stories的请求会快速消耗配额。
• 添加用户数据缓存：用字典缓存已获取的用户信息，避免同一UID被重复查询，示例代码：

  class FeedViewModel: ObservableObject {
      // 添加缓存
      private var userCache = [String: User]()
      
      func fetchPosts() {
          service.fetchPosts { posts in
              self.posts = posts
              
              for i in 0 ..< posts.count {
                  let uid = posts[i].uid
                  // 先检查缓存，无缓存再请求
                  if let cachedUser = self.userCache[uid] {
                      self.posts[i].user = cachedUser
                  } else {
                      self.userService.fetchUser(withUid: uid) { user in
                          self.userCache[uid] = user
                          self.posts[i].user = user
                      }
                  }
              }
          }
      }
  }
  

4. 分析Firebase控制台的请求详情 #

• 进入Firebase控制台数据库>监控>使用情况，查看具体请求的路径、频次和来源：
  • 确认是列表请求（posts/stories）还是用户数据请求暴增；
  • 检查请求来源IP/设备，排查是否存在爬虫、恶意请求，若有则更新安全规则限制访问。

5. 检查视图生命周期与重复触发场景 #

• 排查是否存在快速连续触发请求的场景：比如下拉刷新、快速切换标签页，导致fetchPosts/fetchStories被重复调用；
• 添加防抖逻辑，设置时间窗口（如1秒），同一时间段内只允许发起一次数据请求。

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