如何获取Firebase Function当前区域？FUNCTION_REGION为何被移除？

刚好之前处理过类似的跨区域Firebase函数部署场景，来给你梳理一下你的几个疑问：

一、怎么获取函数当前运行的区域？ #

你说的没错，FUNCTION_REGION就是正确的环境变量，而非旧的FIREBASE_REGION。在函数运行时，这个变量会自动被注入到环境中，直接通过process.env.FUNCTION_REGION就能拿到当前实例所在的具体区域（比如你部署的us-central1或europe-west2）。

给你补个实际能用的代码示例，直接集成到你的Express应用里：

export const admin = functions.region("us-central1", "europe-west2").https.onRequest((req, res) => {
  const currentRegion = process.env.FUNCTION_REGION;
  console.log(`当前函数实例运行在：${currentRegion}`);
  // 这里就可以根据currentRegion对接对应区域的Firestore等资源了
  app(req, res);
});

要是你用的是Firebase Functions v2版本，这个变量的支持是完全没问题的；如果是v1旧版本，可能需要确认一下你的依赖版本，不过官方早就推荐切换到FUNCTION_REGION了。

二、大家通常怎么处理跨区域对接本地资源的需求？ #

主流的处理方式大概有这几种：

• 动态适配模式：就是上面说的，拿到FUNCTION_REGION后，动态初始化对应区域的资源实例，比如针对不同区域用不同的Firestore数据库或者自定义的存储路径。
• 部署时绑定配置：有些团队会在部署脚本里做文章，比如部署到us-central1时，通过firebase deploy命令附带注入对应区域的资源配置环境变量，不过这种方式灵活性不如动态获取。
• 利用Firebase原生多区域能力：如果你的Firestore已经开启了多区域复制，其实不用手动处理——Firebase会自动让函数连接到就近的资源副本，省了不少事。

三、为什么这类问题好像不常见？ #

主要是这几个原因：

• 大部分场景不需要单函数多区域部署：很多开发者要么把函数只部署到一个核心区域，要么按业务模块拆分不同区域的函数（比如欧洲用户的业务用欧洲区域的函数，北美用北美区域），很少会把同一个函数部署到多个区域，自然不会遇到这个需求。
• Firebase服务自带就近优化：像Firestore、Storage这些服务本身就有全球CDN和就近访问机制，很多时候开发者根本不用手动指定区域，函数会自动找最近的资源节点。
• 官方文档的引导方向：Firebase官方更推荐按业务拆分函数到对应区域，而非单函数多区域部署，所以很多开发者不会走到这一步。

四、FUNCTION_REGION被移除了？其实是误解 #

准确来说它并没有被移除，而是Firebase做了标准化调整：

• 早期Firebase Functions有自己的FIREBASE_REGION变量，但后来因为Firebase Functions底层基于Google Cloud Functions（GCF），为了和GCF的环境变量保持一致，就统一换成了FUNCTION_REGION，旧的FIREBASE_REGION被废弃了，所以你可能会看到有人说“被移除”，其实是替换成了更标准的变量。
• 要是你在最新版本里拿不到这个变量，大概率是部署配置出了问题，或者你的函数权限有问题——正常部署后，这个变量会自动出现在运行环境里的。

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