Firebase多站点部署与函数分组避坑firebase-gcp-examples的Deploy Targets与firestore.rules安全实践【免费下载链接】firebase-gcp-examples Firebase app architectures, languages, tools some GCP things! React w Next.js, Svelte w Sapper, Cloud Functions, Cloud Run.项目地址: https://gitcode.com/gh_mirrors/fi/firebase-gcp-examplesFirebase 多站点部署的核心就在firebase.json的Deploy Targetshosting.site而数据安全则依赖firestore.rules规则文件。开源项目firebase-gcp-examples提供了 10 个可直接运行的架构示例Next.js、Nuxt.js、Cloud Functions、Cloud Run、GraphQL、Cron 定时任务本文带你逐条避开多站点部署与函数分组中最常见的 5 个坑。想先拿到全部示例代码一条命令即可git clone https://gitcode.com/gh_mirrors/fi/firebase-gcp-examples坑 1多站点部署时忘记替换hosting.site占位符 这是本项目示例中最直白的坑——cloudrun-nextjs/firebase.json里写着一个显眼的占位符hosting: { site: TODO_YOUR_WEB_APP_DEPLOY_TARGET_HERE, public: public, ... }多站点Multi-site部署的正确姿势在 Firebase 控制台的 Hosting 中创建新的Web App获得一个部署目标site 名称把它填入firebase.json的hosting.site字段替换掉TODO_YOUR_WEB_APP_DEPLOY_TARGET_HERE升级Blaze 付费计划多站点与 Cloud Run 重写都需要。进阶技巧functions-nextjs/firebase.json展示了另一种写法——hosting用数组包裹为未来扩展多个部署目标预留结构hosting: [ { site: TODO_YOUR_WEB_APP_DEPLOY_TARGET_HERE, public: public/, cleanUrls: true, ... } ]一个firebase.json对应一个站点目标想同时部署到多个站点时复制并修改该结构即可互不干扰。坑 2重写规则选错——静态文件打架示例项目里藏着两套完全不同的重写策略选错就会出现静态资源重复服务的问题方案 ACloud Functions 重写functions-nextjs/firebase.jsonrewrites: [{ source: **, function: nextjs-server }]所有请求转发给名为nextjs-server的函数静态文件由函数自己处理容易与 Hosting 重复响应图片/CSS。方案 BCloud Run 重写cloudrun-nextjs/firebase.jsonrewrites: [{ source: **, run: { serviceId: nextjs-app, region: us-central1 } }]只把请求交给 Cloud Run 服务静态资源由 Firebase Hosting 直接分发——这正是项目 README 中强调的改进点no issues with duplicate static file serving不再有静态文件重复分发问题。经验法则Next.js 混合 SSG/SSR 场景优先用方案 BCloud Run函数分组更简单部署路径更清晰。坑 3Cloud Functions 函数分组不隔离上传了 100MB 垃圾文件 对比两个示例的functions配置差距一目了然cron/firebase.json、functions-express/firebase.json只有极简配置{ functions: { source: . } }functions-nextjs/firebase.json则精心维护了一份ignore 清单functions: { source: ., ignore: [ firebase.json, firebase-debug.log, **/.*, **/node_modules/**, components/**, helpers/**, pages/**, public/**, firestore.rules, readme.md ] }函数分组的三个最佳实践全部来自本项目显式 ignoreNext.js 的pages/、public/与函数运行时无关全部排除加快上传与冷启动独立目录隔离cloudrun-nextjs的 README 展示了推荐结构——把所有后端函数放进独立的functions/子目录含自己的package.json与firebase.json主firebase.json只保留 Hosting 配置两条部署链路互不污染命名防冲突用exports.nextjs { server }见functions-nextjs/server.js这样的命名导出多函数共存时用前缀避免重名。坑 4firestore.rules 写太松等于没有安全防线 项目里正好有反面教材和正面示范一对反面cloudrun-nextjs/firestore.rules对所有文档放行读取match /{document**} { allow read: if true; allow write: if false; }正面functions-nextjs/firestore.rules把权限收敛到最小路径/posts/{postID}match /posts/{postID} { allow read: if true; allow write: if false; }安全实践清单✅ 只对你真正需要的集合路径如posts开放读取未匹配的路径默认拒绝✅ 演示型数据可以read: if true但write永远不要true防止匿名写入✅ 生产环境把allow read: if true升级为身份校验如request.auth ! null✅ 规则文件随仓库版本管理路径cloudrun-nextjs/firestore.rules、functions-nextjs/firestore.rules改动可回溯。坑 5Cron 定时函数时区神出鬼没 ⏰cron/src/functions.js展示了同一定时逻辑的两种写法并显式标注了时区——这是新手最容易忽略的细节// 英文语法 明确时区 functions.pubsub.schedule(every 10 minutes) .timeZone(Australia/NSW) // 经典 cron 表达式 明确时区 functions.pubsub.schedule(5 * * * *) .timeZone(Pacific/Auckland)两个要点schedule 必须搭配.timeZone()否则默认 UTC每天早上 9 点会变成北京时间下午 5 点英文语法every 5 minutes适合固定间隔cron 表达式0 9 * * *适合钟点触发按需求选择。 部署前快速自检清单#检查项对应文件1hosting.site已替换为真实部署目标cloudrun-nextjs/firebase.json2项目已升级 Blaze 计划控制台3next.config.js中项目 ID 已替换cloudrun-nextjs/next.config.js4Firestore 已创建posts测试集合控制台 Firestore5已启用 Cloud Run 与 Cloud Build控制台 API6函数目录含完整 ignore 清单functions-nextjs/firebase.json7rules 只放行最小路径functions-nextjs/firestore.rules全部示例索引见根目录 README 中的 Code samples 表格涵盖 cron 定时函数、Express Cloud Functions、GraphQL Apollo、Babel/Parcel 编译代码 等场景——照着上表的清单逐项核对多站点部署与函数分组基本不会再翻车。【免费下载链接】firebase-gcp-examples Firebase app architectures, languages, tools some GCP things! React w Next.js, Svelte w Sapper, Cloud Functions, Cloud Run.项目地址: https://gitcode.com/gh_mirrors/fi/firebase-gcp-examples创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考