Firebase 适合什么项目？Hosting、Authentication 和数据库怎么搭配

Firebase 更像一盒能拼起来的积木，不是单一数据库

很多人第一次接触 Firebase 是因为 Firestore，其实项目里常常会同时用 Hosting、Authentication、Cloud Firestore、Storage 等不同服务。好处是集成顺，代价是要理解每块服务自己的计费、权限和限制。

Hosting 适合静态和单页应用，完整框架要分情况

Firebase Hosting 自带 CDN 和 SSL，静态站、SPA 部署很顺手，也能配合 Cloud Functions 或 Cloud Run 提供动态能力。官方当前也会在识别到部分全栈框架时提示 App Hosting，所以别把所有 Web 项目都默认塞进传统 Hosting。

Authentication 能少写很多登录流程，但授权仍是你自己的事

Firebase Authentication 可以处理邮箱密码、手机和常见第三方身份提供商等登录方式。用户“是谁”解决以后，用户“能看什么、能改什么”仍然要靠数据库 Security Rules 或后端权限逻辑控制。

Firestore 最容易踩的坑，是开发时规则太宽

开发阶段为了方便写成开放规则很常见，真正上线前一定要按用户、文档路径和操作类型收紧。前端能拿到配置并不等于数据库应该公开；真正关键的是认证、Security Rules 和 App Check 等保护是否设计正确。

适合快速做产品，但别忽略迁移和成本模型

原型、移动应用和需要快速接入认证/实时数据的项目很适合 Firebase。数据量、查询模式、团队技术栈和长期云平台策略一旦变复杂，就要提前评估成本、数据模型和未来迁移难度。