基于GCP的可复用API中间层选型咨询：轻量可扩展性价比优先

1. Cloud Functions（优先推荐，适配C#/Node.js） #

• 轻量无服务器架构，完全托管无需运维，按调用次数和执行时长计费，性价比拉满，适合轻量API中间层场景
• 原生支持C#（基于.NET 6+，可通过GCP CLI或控制台直接部署）和Node.js，完美匹配你的技术栈偏好
• 集成Firebase Auth验证：借助Firebase Admin SDK，在函数入口处验证前端/原生APP传来的ID Token，确保只有已登录用户能触发API
• 适配未来扩展：原生移动APP可直接通过HTTP请求触发函数，或借助Firebase SDK调用，衔接顺畅

2. Cloud Run（适合复杂API中间层需求） #

• 无服务器容器化部署，支持自定义镜像，可运行完整的C# ASP.NET Core API或Node.js Express服务，适合需要多端点、复杂业务逻辑的场景
• 自动扩缩容：流量低时缩至0实例，几乎无成本；高流量时快速扩容，满足扩展性要求
• 认证逻辑统一处理：在API中间层的全局拦截器中集成Firebase Admin SDK，验证请求头中的ID Token，通过后再转发至后端
• 比Cloud Functions更灵活，适合后续中间层功能迭代升级

3. Firebase Cloud Functions（贴近Firebase生态，优先Node.js） #

• 和你的Firebase Hosting、Auth深度集成，配置成本极低，无需额外跨服务配置
• 原生支持Node.js，可快速搭建API中间层，直接用Firebase SDK处理认证逻辑
• 原生APP扩展友好：移动端通过Firebase SDK获取ID Token后，可直接调用函数，无需额外适配

通用认证实现逻辑 #

• 前端/原生APP完成Firebase邮箱密码登录后，获取ID Token
• 调用中间层API时，将ID Token放在Authorization: Bearer <token>请求头中
• 中间层通过Firebase Admin SDK的verifyIdToken()方法验证token的有效性，验证通过后再转发请求到后端服务

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