基于GCP、Go、Firebase与Flutter的视频上传系统流程设计咨询

• 后端完全掌控上传权限与流程
  签名URL由Go后端生成，你可以在后端加入自定义的权限校验逻辑——比如验证用户身份、限制单用户上传配额、提前校验视频格式和大小，不用完全依赖Firebase的存储规则。只有通过后端校验的用户才能拿到上传URL，能有效避免前端直接上传时可能出现的权限绕过问题。

• 灵活衔接转码等后续处理
  用签名URL流程时，前端上传完成后会主动通知后端，后端可以立刻触发转码操作（比如生成适配不同设备的分辨率、制作视频缩略图），整个流程衔接更顺畅。如果用前端直接上传Firebase Storage，虽然能通过Cloud Functions触发后续处理，但对于已有Go后端的架构来说，把转码等逻辑整合到现有后端里，能让业务逻辑更统一，不用额外维护云函数代码。

• 降低敏感配置泄露风险
  直接用Firebase Storage上传时，前端需要配置Firebase存储相关的密钥和规则（哪怕有SDK封装，仍存在配置泄露的可能）。而签名URL方式下，前端不需要对接Firebase Storage SDK，只需要使用后端生成的临时URL上传，所有敏感的存储配置都留在后端，安全性更高。

• 统一业务逻辑入口
  所有视频相关操作（权限校验、上传触发、转码、存储链接到Firestore）都通过Go后端处理，业务逻辑更集中，后续维护和扩展更方便。比如后续要加视频审核、用户上传统计功能，直接在后端加逻辑就行，不用同时修改前端和云函数。

• 存储位置更灵活可控
  签名URL基于GCP Storage生成，你可以把视频存在GCP Storage的任意桶（包括和Firebase Storage关联的桶），甚至后续如果要切换存储服务，只需要调整后端生成签名URL的逻辑，前端完全不用改动。而直接用Firebase Storage上传的话，前端绑定的是特定的Firebase存储桶，灵活性相对差一些。

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