Firebase Functions Emulator能否搭配GCP Cloud Functions使用

没法直接零改动就用，但只要做极少量的轻量适配，完全可以用这套模拟器做日常本地开发调试，整体成本比搭原生GCP本地测试环境低很多。

• Firebase Functions本身就是GCP Cloud Functions的上层封装，Node.js运行时、Pub/Sub触发的核心逻辑和线上GCP环境完全同源，模拟器的行为和生产环境对齐度足够支撑开发阶段的调试需求，对你这种用纯Node.js JS写的Pub/Sub触发型函数来说，测试结果参考价值很高。

• 做一层极薄的事件格式转换：原生GCP Pub/Sub函数接收的事件参数结构，和Firebase模拟器吐出的参数结构有细微字段差异，你不用改核心业务代码，只要在本地测试的入口层加个不到10行的转换逻辑，把模拟器传的消息对象转成你线上函数预期的格式就行。比如线上GCP函数拿到的消息Buffer在event.data字段，模拟器传的消息在对应Pub/Sub事件的消息字段里，字段映射关系非常固定，写一次之后所有同类型函数都能复用。
• 补一个最小化的本地Firebase配置：你完全不用把现有GCP项目整体迁到Firebase，只要在函数本地工作目录初始化一个最简Firebase配置，只勾选Functions、Pub/Sub两个模拟器组件，在本地入口文件里把你要测的现有GCP函数绑定到对应名称的Pub/Sub主题上就行。这部分配置文件只在本地调试用，线上部署GCP函数的时候完全不用提交，不会影响你原有的CI/CD和部署流程。
• 手动对齐本地环境变量和权限：模拟器不会自动拉取你GCP项目线上的环境变量、服务账号权限，调试前把你线上函数用到的环境变量、测试用服务账号密钥配置到本地终端环境就行，这步和你搭原生GCP本地测试环境要做的事完全一样。

• 这套方案只适合开发阶段的快速本地调试，正式上线前的版本验证还是要走GCP官方的测试环境流程，不要完全依赖模拟器的结果。
• 如果你的函数调用了Pub/Sub、函数运行时之外的其他GCP服务（比如BigQuery、Cloud Storage、Cloud SQL），模拟器不会模拟这些服务的行为，本地调试时还是要连对应服务的测试实例，这部分和原生测试方案没有区别。
• 启动模拟器的时候直接执行firebase emulators:start --only functions,pubsub就行，不用启动其他Firebase组件，内存占用非常低。

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