我之前也碰到过这个头疼的问题——Firebase实时数据库的onCreate/onUpdate/onDelete触发器里，确实没有官方原生方式获取触发操作的用户身份。你已经找到的通过模型加uid字段配合数据库规则的方案，在创建和更新场景非常实用，但删除场景因为数据被清空，确实没法直接复用。下面是我在实际项目里用过的几个可靠方案，供你参考：

方案一：软删除（标记式删除） #

这可能是最通用且稳定的方案，虽然你觉得是临时workaround，但很多生产级项目都在长期使用：

• 放弃直接删除记录，改为给数据添加isDeleted（布尔值）、deletedBy（存用户UID）、deletedAt（时间戳）字段
• 配置数据库规则，确保deletedBy只能被设置为当前用户的UID：

  {
    "rules": {
      ".read": true,
      ".write": "auth != null",
      "your-collection": {
        "$docId": {
          "deletedBy": { ".validate": "auth.uid === newData.val()" },
          "isDeleted": { ".validate": "newData.val() === true || newData.val() === false" }
        }
      }
    }
  }
  

• 把原本的onDelete触发器改成onUpdate，监听isDeleted字段的变化：当它从false变为true时，执行原本删除逻辑要做的操作（比如关联数据清理、通知推送等）
• 前端展示数据时，过滤掉isDeleted: true的记录；定期用Cloud Scheduler触发函数，清理超过一定时长的软删除数据

优点：完全兼容现有权限体系，能稳定获取删除操作的用户UID；逻辑清晰易维护
缺点：需要修改前端和后端的删除流程，还要额外处理数据清理

方案二：自定义Claims + 审计日志联动 #

适合对数据安全要求较高，且希望保留真正删除操作的场景：

• 前端执行删除操作前，先调用一个专属Cloud Function，函数内验证用户身份后，给用户添加临时自定义Claim（比如deletingDoc: "要删除的文档ID"），并设置短有效期（比如5分钟）
• 配置数据库规则，确保用户只能删除自己标记的文档：

  {
    "rules": {
      "your-collection": {
        "$docId": {
          ".write": "auth != null && auth.token.deletingDoc === $docId"
        }
      }
    }
  }
  

• 在onDelete触发器中，通过context.auth.token.deletingDoc获取对应文档ID，或者在之前的Cloud Function里，先把用户UID和文档ID的对应关系存入deleteAuditLogs集合，触发器里直接查询该集合获取UID
• 操作完成后，记得清除用户的临时自定义Claim

优点：不需要修改数据模型，保留原生删除操作；权限验证更严谨
缺点：流程相对复杂，要处理Claim的过期和清理，还要维护审计日志集合

方案三：前端预存删除日志 #

适合小型项目，实现成本极低：

• 前端在执行删除操作前，先往专门的deleteLogs集合写入一条记录，包含targetDocId（要删除的文档ID）、uid（当前用户UID）、timestamp
• 数据库规则确保deleteLogs的uid只能是当前用户的UID：

  {
    "rules": {
      "deleteLogs": {
        "$logId": {
          "uid": { ".validate": "auth.uid === newData.val()" }
        }
      }
    }
  }
  

• onDelete触发器触发时，根据被删除文档的ID，查询deleteLogs里最近的一条对应记录，获取用户UID
• 定期清理deleteLogs里的旧记录，避免数据冗余

优点：实现简单，几乎不需要修改现有核心逻辑
缺点：存在时间差风险（比如日志写入成功但删除操作失败），需要额外处理异常情况

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