第二篇 开发实战心得:四大件用起来什么感觉
如果说第一篇是带你看 Firebase 的整体地图,那这一篇就是真正下厨做饭了。我们把 Firebase 里最常用的四个组件比作厨房四大件,你会发现它们的关系跟开一家小餐馆惊人地相似。
厨房四大件,各自管什么
登录是门禁系统。 谁能进店、进店的人是谁、会员还是散客,全靠它在门口刷脸认证。Authentication 管的就是这件事:把陌生人变成系统认识的用户,后续一切授权都建立在它给出的身份之上。
Firestore 是食材仓库。 你的数据——用户档案、订单记录、文章内容——都存在这个仓库里。它不是普通的仓库,而是一个会自动盘点、能在你断电(离线)时继续记账、还能实时播报库存变化的高级仓库。
安全规则是每扇门上的门锁。 门禁只管认人,门锁才管谁能碰哪个货架。别小看它:客户端 SDK 是直连数据库的,没有门锁,等于仓库大门洞开。
云函数是后厨。 前厅(客户端)不该干的活——敏感计算、聚合统计、定时任务——都交给后厨。事件来了自动开火,客人走了自动熄灶。
四节预告
接下来四节,每节盯住一件:
- 2.1 聊 Authentication:登录方式怎么选,各家的坑长什么样;
- 2.2 聊 Firestore:为什么说数据建模决定一切,SQL 思维怎么迁移;
- 2.3 聊安全规则:默认拒绝的哲学,以及那些最容易配错的姿势;
- 2.4 聊云函数与托管:冷启动、区域选择、部署节奏这些工程细节。
四大件心得速览
| 四大件 | 对应服务 | 一句话心得 | 最常见的坑 |
|---|---|---|---|
| 门禁 | Authentication | 登录方式按业务阶段加,别一次上全 | Admin SDK 误放前端 |
| 食材仓 | Cloud Firestore | 按查询建模,不是按实体建模 | SQL 思维硬套导致全表扫 |
| 门锁 | 安全规则 | 默认拒绝,逐步放开 | 把已登录当成已授权 |
| 后厨 | Cloud Functions | 低频函数记得考虑冷启动 | 数据库和函数隔了半个地球 |
这四件事单独看都不难,难的是它们咬合起来的细节——身份怎么传给规则、文档结构怎么配合查询、函数区域怎么靠近数据库。本篇不写 API 手册,只聊一线踩坑换来的手感,代码片段以官方文档为准。
