Flutter

Flutter Firebase 后端集成实战

Flutter 与 Firebase 全家桶集成实战：Firebase 项目初始化与多环境配置、Firebase Auth 匿名/邮箱/第三方登录与用户管理、Cloud Firestore 实时数据与安全规则、Firebase Cloud Messaging 推送与消息处理、Firebase Storage 文件上传与安全、以及云函数与离线优先的数据同步策略。

Leeting Yan 6 分钟阅读 2736 字

开篇：为什么 Flutter 与 Firebase 是天作之合

Flutter 只管「渲染」，后端是另一座山。而 Firebase 给了 Flutter 一个「开箱即用」的 BaaS（后端即服务）：认证、数据库、推送、存储、云函数——官方 SDK 一链打通，是原型验证和中小型应用最快的后端方案。

Firebase 的适用边界要看清：

  1. 适合：快速上线、MVP、实时协作类 App（聊天/协作编辑）、事件型数据（埋点、活动流）。
  2. 不适合：强一致金融交易、复杂 SQL 查询、超大流量高定制后端——这些需要自建服务。
  3. 选型：数据读多写少 + 需要实时订阅 → Firestore；高频低成本写入（IoT/日志）→ Realtime Database；既有 SQL 业务 → 考虑 Supabase 或自建。

本文按「一个真实 App 从 0 到 1 接 Firebase」的路径，覆盖认证、数据库、推送、存储四大块，并给出安全规则与成本控制的关键实践。

一、初始化与多环境配置

1.1 接入 Firebase 的正确姿势

无论 Android 还是 iOS，官方推荐先装 CLI 再引导初始化：

# 安装 Firebase CLI 后，在项目根目录
firebase login
flutter pub add firebase_core firebase_auth cloud_firestore \
  firebase_messaging firebase_storage cloud_functions

# Android: google-services.json 放到 android/app/
# iOS:     GoogleService-Info.plist 放到 ios/Runner/

接入陷阱：

  • Android 的 google-services.json 与包名必须匹配，否则运行时报「Default FirebaseApp is not initialized」。
  • iOS 的配置文件放对 target：放 Runner，不是 RunnerTests。
  • 多环境（dev/prod）：一份代码切不同 Firebase 项目，用 --dart-define + 构建阶段替换配置文件，或用 FirebaseOptions 动态初始化。

1.2 动态初始化多环境

// 用 dart-define 区分环境，运行时手动初始化
Firebase.initializeApp(
  options: FirebaseOptions(
    apiKey: const String.fromEnvironment('FB_API_KEY'),
    appId: const String.fromEnvironment('FB_APP_ID'),
    messagingSenderId: const String.fromEnvironment('FB_MSG_ID'),
    projectId: const String.fromEnvironment('FB_PROJECT_ID'),
  ),
);

这样 dev 与 prod 只需换构建参数，不用维护两份配置文件，也不会把密钥堆在仓库里。

二、Firebase Auth 认证

2.1 常用登录方式

final user = await FirebaseAuth.instance.signInAnonymously();       // 匿名体验
final credential = EmailAuthProvider.credential(email, password);
await FirebaseAuth.instance.signInWithCredential(credential);        // 邮箱密码
final googleUser = await GoogleSignIn().signIn();                   // 第三方
final googleAuth = await googleUser.authentication;
final cred = GoogleAuthProvider.credential(accessToken: ..., idToken: ...);
await FirebaseAuth.instance.signInWithCredential(cred);

用户体系设计：匿名登录让用户「先体验后注册」，注册时 linkWithCredential 把匿名账户升级为正式账户——保留匿名期的数据，是增长团队的标准打法。

2.2 用户状态与生命周期

FirebaseAuth.instance.authStateChanges().listen((user) {
  if (user == null) { /* 未登录 */ } else { /* 已登录 */ }
});
  • 登录态用 Stream 订阅，配合状态管理（Riverpod/BLOC）驱动整个 App 的「登录/未登录」切换。
  • 用户信息、自定义 claims 从 user.getIdToken() 解析，别只信客户端的 user 对象。
  • 登出清理：登出时清空本地敏感数据与订阅，避免下一用户读到上一用户数据。

三、Cloud Firestore：实时数据与安全规则

3.1 读写与实时订阅

final db = FirebaseFirestore.instance;
// 实时订阅
db.collection('chat_rooms').doc(roomId)
  .collection('messages').orderBy('createdAt', descending: true).limit(20)
  .snapshots().listen((snap) => setState(() => _messages = snap.docs));

// 一次性读
final doc = await db.collection('users').doc(uid).get();

// 写
await db.collection('users').doc(uid).set({'name': 'Leeting', 'ts': FieldValue.serverTimestamp()});

Firestore 的杀手锏是 .snapshots() 实时监听——前端订阅即自动同步，配合 Flutter 的响应式状态管理，界面「自己会更新」，无需手动拉数据。

3.2 安全规则是防火墙，不是事后需求

客户端写的每一条数据都过安全规则。绝不能只靠客户端代码保护数据：

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // 登录才能读自己的 profile
    match /users/{uid} {
      allow read: if request.auth != null && request.auth.uid == uid;
      allow write: if request.auth != null && request.auth.uid == uid;
    }
    // 聊天室：登录可读，发消息必须带自己的 uid 与合法字段
    match /chat_rooms/{room}/messages/{msg} {
      allow read: if request.auth != null;
      allow create: if request.auth != null
                    && request.resource.data.uid == request.auth.uid
                    && request.resource.data.text is string
                    && request.resource.data.text.size() <= 500;
    }
  }
}

安全规则要点：用「数据形状校验」限制写入字段（request.resource.data 校验类型/长度/归属），不要只写 allow read, write: if true（等于裸奔）。规则改动用模拟器先测，再发布。

3.3 数据建模与成本

Firestore 按「读/写/存储量」计费，建模直接影响账单：

  • 避免深度嵌套：文档 1MB 上限、字段扁平化，一对多用子集合而非嵌套。
  • 索引：复合排序/过滤必须建索引（控制台提示一键建）。
  • 批量写：batch/WriteBatch 合并多次写为一次往返，省钱又省时。
  • 分页：limit + startAfter（游标），别一次拉全量。
  • 监听要小心：客户端开的 snapshots 没 limit 会持续拉取全集合——实时监听的成本陷阱。

四、Firebase Cloud Messaging（FCM）推送

4.1 前端订阅与接收

final messaging = FirebaseMessaging.instance;
// 请求权限
final settings = await messaging.requestPermission(alert: true, badge: true, sound: true);
// 拿设备 token 存 Firestore，供服务端定向推送
final token = await messaging.getToken();
await db.collection('user_tokens').doc(uid).set({'token': token});

// 前台消息处理
FirebaseMessaging.onMessage.listen((message) {
  // 前台: 通常自己弹通知栏 or 只做 UI 内提示
});
// 后台点击跳转
FirebaseMessaging.onMessageOpenedApp.listen((message) {
  _handleNotificationTap(message.data);
});
// 冷启动消息
final initial = await messaging.getInitialMessage();

4.2 推送工程要点

  • Token 会轮换：应用更新、重新安装、卸载重装都变，必须「写 token + 删除旧 token」配套。
  • 发送方：官方推荐服务端 Admin SDK 或云函数发，别用客户端直发（暴露凭证且被滥用）。
  • 通知 vs 数据消息：通知消息（系统弹窗）+ 数据消息（静默字段）组合使用，跳转靠 data 里的路由信息。
  • 点击行为：前台/后台/冷启动三种路径的跳转都要写（见上文三个 listen），漏一条消息就「点了没反应」。
  • Android 后台 kill 后推送：依赖厂商通道（小米/华为）或保持 firebase_messaging 后台处理，别忘了厂商 SDK 配置。

五、Firebase Storage 文件上传

5.1 上传与引用

final ref = FirebaseStorage.instance
    .ref('avatars/$uid/${DateTime.now().millisecondsSinceEpoch}.jpg');
await ref.putFile(file);                       // 上传
final url = await ref.getDownloadURL();        // 拿可访问 URL
// 安全: 上传走规则，下载 URL 可带 token

5.2 Storage 安全与优化

  • 规则：按路径校验登录与类型，match /avatars/{uid}/{file} 只允许本人写自己的目录。
  • 压缩：图片先 flutter_image_compress 压缩再传，省流量省账单。
  • 命名：用 uid/时间戳生成唯一名，防覆盖与枚举。
  • 清理：上传成功才写入 Firestore 引用，删除用户时连 storage 一起删（云函数联动）。

六、云函数与离线优先

6.1 云函数：客户端不该做的事

客户端不能碰的活儿丢给 Cloud Functions：

  • 发 FCM 推送（校验归属后定向推）。
  • 服务端时间/事件（onCreate 触发，更新聚合计数、发欢迎信）。
  • 敏感计算（积分、风控、扣费）。
  • 数据清洗与联动（删用户 → 清 Firestore + Storage）。
// 示例: 新用户注册后自动初始化个人文档
exports.onUserCreated = functions.auth.user().onCreate((user) => {
  return admin.firestore().collection('users').doc(user.uid).set({
    nickname: '新用户', createdAt: admin.firestore.FieldValue.serverTimestamp(),
  });
});

6.2 离线优先与冲突处理

Firestore 自带离线缓存——客户端断网仍可读写，联网后自动同步。工程上要利用这个特性：

  • 写前本地乐观更新：UI 立刻反映，不等待服务端回执。
  • 冲突解决：FieldValue.serverTimestamp()、arrayUnion/increment 是「无冲突原子操作」，优先用它们而不是「读-改-写」。
  • 监听状态：metadata.hasPendingWrites 判断是否本地待同步，UI 显示「离线待同步」状态。
  • 真离线数据：Firestore 缓存默认有限，需要大离线包时考虑本地 SQLite 作主存 + Firestore 作同步层。

FAQ

Q：Firestore 和 Realtime Database 选哪个？
A：读写均衡 + 实时订阅 + 需要子集合/索引 → Firestore；超高吞吐低成本写入（IoT/日志/活动流）→ Realtime Database。

Q：安全规则到底多重要？
A：它是最后一道防线，客户端代码完全不可信。只写 allow read, write: if true 等于数据库裸奔，公开抓包即可读走全表。

Q：推送收不到？
A：先分路径排查——权限没请求？token 没存？后台被 kill 后厂商通道没配？冷启动跳转没接？逐层验证。

Q：Firebase 会不会太贵？
A：免费额度对 MVP 足够。账单大头通常是「无界面的实时监听 + 无索引查询 + 大图片存储」。按 3.3 的建模原则能省 80%。

相关阅读

继续阅读

探索更多技术文章

浏览归档，发现更多关于系统设计、工具链和工程实践的内容。

全部文章 返回首页

「Flutter」更多文章

  1. Flutter Design Tokens 与自适应主题工程
  2. Flutter 错误处理与可靠性工程
  3. Flutter 高级绘制与绘制动画