Google 會運用 AI 技術將內容翻譯成你偏好的語言，但可能會出錯。

管理函式

您可以使用 Firebase CLI 指令，或在函式原始碼中設定執行階段選項，藉此部署、刪除及修改函式。

部署函式

如要部署函式，請執行下列 Firebase CLI 指令：

firebase deploy --only functions

根據預設，Firebase CLI 會同時部署來源中的所有函式。如果專案包含超過 5 個函式，建議您使用 --only 旗標搭配特定函式名稱，只部署您編輯過的函式。透過這種方式部署特定函式，可以加快部署程序，並避免達到部署配額。例如：

firebase deploy --only functions:addMessage,functions:makeUppercase

部署大量函式時，可能會超過標準配額，並收到 HTTP 429 或 500 錯誤訊息。如要解決這個問題，請以 10 個或更少的群組部署函式。

如需可用指令的完整清單，請參閱 Firebase CLI 參考資料。

根據預設，Firebase CLI 會在 functions/ 資料夾中尋找原始碼。您也可以視需要整理程式碼集或多組檔案中的函式。

清除部署構件

部署函式時，系統會產生容器映像檔，並儲存在 Artifact Registry。部署的函式不需要這些映像檔即可執行；Cloud Functions 會在初始部署時擷取並保留映像檔副本，但儲存的構件並非函式在執行階段運作的必要條件。

雖然這些容器映像檔通常很小，但會隨著時間累積，增加儲存費用。如果您打算檢查建構的構件，或執行容器安全漏洞掃描，建議您保留這些構件一段時間。

為協助管理儲存空間費用，Firebase CLI 14.0.0 以上版本可讓您為存放區設定 Artifact Registry 清理政策，在每次部署函式後，清理存放區中的部署構件。

您可以使用 functions:artifacts:setpolicy 指令，手動設定或編輯清理政策：

firebase functions:artifacts:setpolicy

根據預設，這個指令會設定 Artifact Registry 自動刪除建立超過 1 天的容器映像檔。這樣一來，既能盡量降低儲存成本，又能檢查近期建構作業，達到合理的平衡。

您可以使用 --days 選項自訂保留期限：

firebase functions:artifacts:setpolicy --days 7  # Delete images older than 7 days

如果您將函式部署至多個區域，可以使用 --location 選項，為特定位置設定清理政策：

$ firebase functions:artifacts:setpolicy --location europe-west1

停用構件清理功能

如果您偏好手動管理映像檔清理作業，或不想刪除任何映像檔，可以完全停用清理政策：

$ firebase functions:artifacts:setpolicy --none

這個指令會移除 Firebase CLI 設定的所有現有清理政策，並防止 Firebase 在函式部署後設定清理政策。

刪除函式

您可以透過下列方式，刪除先前部署的函式：

在 Firebase CLI 中使用 functions:delete 明確
明確啟用。Google Cloud 控制台
隱含：在部署前從來源中移除函式。

所有刪除作業都會提示您確認，然後才從正式環境中移除函式。

在 Firebase CLI 中明確刪除函式時，可使用多個引數和函式群組，並指定在特定區域執行的函式。此外，您也可以覆寫確認提示。

刪除所有區域中符合指定名稱的所有函式：
```
firebase functions:delete FUNCTION-1_NAME
```

刪除在非預設區域中執行的指定函式：

firebase functions:delete FUNCTION-1_NAME --region REGION_NAME

刪除多個函式：

firebase functions:delete FUNCTION-1_NAME FUNCTION-2_NAME

刪除指定的函式群組：
```
firebase functions:delete GROUP_NAME
```

略過確認提示：

firebase functions:delete FUNCTION-1_NAME --force

使用隱含函式刪除功能時，firebase deploy 會剖析來源，並從實際工作環境中移除已從檔案中移除的所有函式。

修改函式的名稱、區域或觸發條件

如要重新命名或變更處理正式版流量的函式區域或觸發條件，請按照本節中的步驟操作，以免在修改期間遺失事件。在變更期間，新舊版本的函式會同時執行，因此請先確認函式具備冪等性，再按照下列步驟操作。

重新命名函式

如要重新命名函式，請在來源中建立重新命名的新版函式，然後執行兩項獨立的部署指令。第一個指令會部署新命名的函式，第二個指令則會移除先前部署的版本。舉例來說，如要重新命名由 HTTP 觸發的 Webhook，請按照下列方式修改程式碼：

Node.js

// before
const {onRequest}  = require('firebase-functions/v2/https');

exports.webhook = onRequest((req, res) => {
    res.send("Hello");
});

// after
const {onRequest}  = require('firebase-functions/v2/https');

exports.webhookNew = onRequest((req, res) => {
    res.send("Hello");
});

Python

# before
from firebase_functions import https_fn

@https_fn.on_request()
def webhook(req: https_fn.Request) -> https_fn.Response:
    return https_fn.Response("Hello world!")

# after
from firebase_functions import https_fn

@https_fn.on_request()
def webhook_new(req: https_fn.Request) -> https_fn.Response:
    return https_fn.Response("Hello world!")

接著執行下列指令，部署新函式：

# Deploy new function
firebase deploy --only functions:webhookNew

# Wait until deployment is done; now both functions are running

# Delete webhook
firebase functions:delete webhook

變更函式的一或多個區域

如要變更處理正式環境流量的函式所指定的區域，請依序執行下列步驟，以免事件遺失：

重新命名函式，並視需要變更區域。
部署重新命名的函式，這會導致兩組區域暫時執行相同的程式碼。
刪除先前的函式。

舉例來說，如果您目前在 us-central1 部署了 Cloud Firestore 觸發的函式，並想將其遷移至 asia-northeast1，則必須先修改原始碼，重新命名函式並修改區域。

Node.js

// before
exports.firestoreTrigger = onDocumentCreated(
  "my-collection/{docId}",
  (event) => {},
);

// after
exports.firestoreTriggerAsia = onDocumentCreated(
  {
    document: "my-collection/{docId}",
    region: "asia-northeast1",
  },
  (event) => {},
);

更新後的程式碼應指定正確的事件篩選器 (在本例中為 document) 和區域。詳情請參閱Cloud Functions位置。

Python

# Before
@firestore_fn.on_document_created("my-collection/{docId}")
def firestore_trigger(event):
    pass

# After
@firestore_fn.on_document_created("my-collection/{docId}",
                                  region="asia-northeast1")
def firestore_trigger_asia(event):
    pass

接著執行下列指令進行部署：

firebase deploy --only functions:firestoreTriggerAsia

現在有兩個相同的函式正在執行：firestoreTrigger 在 us-central1 中執行，firestoreTriggerAsia 在 asia-northeast1 中執行。

接著刪除 firestoreTrigger：

firebase functions:delete firestoreTrigger

現在只有一個函式 firestoreTriggerAsia，在 asia-northeast1 中執行。

變更函式的觸發條件類型

隨著 Cloud Functions for Firebase 部署作業的發展，您可能會基於各種原因需要變更函式的觸發條件類型。舉例來說，您可能想將某種類型的 Firebase Realtime Database 或 Cloud Firestore 事件變更為另一種類型。

您無法只變更原始碼並執行 firebase deploy，就變更函式的事件類型。為避免發生錯誤，請按照下列程序變更函式的觸發條件類型：

修改原始碼，加入具有所需觸發條件類型的新函式。
部署函式，這會導致新舊函式暫時同時執行。
使用 Firebase CLI 從實際工作環境中明確刪除舊函式。

舉例來說，如果您有一個在刪除物件時觸發的函式，但您啟用了物件版本管理功能，並想改為訂閱封存事件，請先重新命名函式，並編輯函式以使用新的觸發條件類型。

Node.js

// before
const {onObjectDeleted} = require("firebase-functions/v2/storage");

exports.objectDeleted = onObjectDeleted((event) => {
    // ...
});

// after
const {onObjectArchived} = require("firebase-functions/v2/storage");

exports.objectArchived = onObjectArchived((event) => {
    // ...
});

Python

# before
from firebase_functions import storage_fn

@storage_fn.on_object_deleted()
def object_deleted(event):
  # ...

# after 
from firebase_functions import storage_fn

@storage_fn.on_object_archived()
def object_archived(event):
  # ...

接著執行下列指令，先建立新函式，再刪除舊函式：

# Create new function objectArchived
firebase deploy --only functions:objectArchived

# Wait until deployment is done; now both objectDeleted and objectArchived are running

# Delete objectDeleted
firebase functions:delete objectDeleted

設定執行階段選項

Cloud Functions for Firebase 可讓您選取執行階段選項，例如 Node.js 執行階段版本、個別函式逾時、記憶體配置，以及函式執行個體數量上下限。

最佳做法是在函式程式碼的設定物件中，設定這些選項 (Node.js 版本除外)。這個 RuntimeOptions 物件是函式執行階段選項的可靠資料來源，會覆寫使用任何其他方法 (例如 Google Cloud 控制台或 gcloud CLI) 設定的選項。

如果開發工作流程涉及使用 Google Cloud 控制台或 gcloud CLI 手動設定執行階段選項，且您「不」希望每次部署時覆寫這些值，請將 preserveExternalChanges 選項設為 true。如果將這個選項設為 true，Firebase 會將程式碼中設定的執行階段選項，與目前部署的函式版本設定合併，優先順序如下：

選項是在函式程式碼中設定：覆寫外部變更。
函式程式碼中的選項設為 RESET_VALUE：以外部變更覆寫預設值。
函式程式碼中未設定選項，但目前部署的函式中已設定：使用部署函式中指定的選項。

在多數情況下，不建議使用 preserveExternalChanges: true 選項，因為程式碼將不再是函式執行階段選項的完整可靠資料來源。如果使用，請查看 Google Cloud 控制台或使用 gcloud CLI，查看函式的完整設定。

設定 Node.js 版本

Cloud Functions 的 Firebase SDK 可讓您選取 Node.js 執行階段。您可以選擇在專案中，只在對應下列其中一個支援 Node.js 版本的執行階段環境中執行所有函式：

Node.js 22
Node.js 20
Node.js 18 (已淘汰)

Node.js 14 和 16 版已於 2025 年初停用。無法使用這些版本進行部署。請參閱支援時程，瞭解這些 Node.js 版本持續支援的重要資訊。

如要設定 Node.js 版本，請按照下列步驟操作：

您可以在初始化期間，於 functions/ 目錄中建立的 package.json 檔案 engines 欄位設定版本。舉例來說，如要僅使用第 20 版，請在 package.json 中編輯這一行：

  "engines": {"node": "20"}

如果您使用 Yarn 套件管理工具，或對 engines 欄位有其他特定需求，可以改為在 firebase.json 中設定 Cloud Functions 的 Firebase SDK 執行階段：

  {
    "functions": {
      "runtime": "nodejs20" // or nodejs22
    }
  }

CLI 會優先使用 firebase.json 中設定的值，而非您在 package.json 中另外設定的任何值或範圍。

升級 Node.js 執行階段

如要升級 Node.js 執行階段，請按照下列步驟操作：

確認專案採用 Blaze 定價方案。
請確認您使用的是 Firebase CLI 11.18.0 以上版本。
在初始化期間，系統會在 functions/ 目錄中建立 package.json 檔案，請變更該檔案中的 engines 值。舉例來說，如果您要從第 18 版升級至第 20 版，項目應如下所示："engines": {"node": "20"}
您也可以使用 Firebase Local Emulator Suite 測試變更。
重新部署所有函式。

選擇 Node.js 模組系統

Node.js 的預設模組系統是 CommonJS (CJS)，但目前的 Node.js 版本也支援 ECMAScript 模組 (ESM)。Cloud Functions 兩者都支援。

根據預設，函式會使用 CommonJS。也就是說，匯入和匯出作業會像這樣：

const {onRequest} = require("firebase-functions/https");

exports.helloWorld = onRequest(async (req, res) => res.send("Hello from Firebase!"));

如要改用 ESM，請在 package.json 檔案中設定 "type": "module" 欄位：

  {
   ...
   "type": "module",
   ...
  }

設定完成後，請使用 ESM import 和 export 語法：

import {onRequest} from "firebase-functions/https";

export const helloWorld = onRequest(async (req, res) => res.send("Hello from Firebase!"));

這兩種模組系統都受到完整支援。您可以選擇最適合專案的方法。詳情請參閱 Node.js 模組說明文件。

設定 Python 版本

Cloud Functions 12.0.0 以上版本的 Firebase SDK 允許選取 Python 執行階段。在 firebase.json 中設定執行階段版本，如下所示：

  {
    "functions": {
      "runtime": "python310" // or python311
    }
  }

控管資源調度行為

根據預設，Cloud Functions for Firebase 會依據傳入要求數量，調整執行中的執行個體數量，在流量減少時，甚至可能縮減至零個執行個體。不過，如果應用程式需要縮短延遲時間，而您希望限制冷啟動次數，則可變更這項預設行為。僅須指定要保持暖機狀態、準備好處理要求的最低容器執行個體數量即可。

同樣地，您也可以設定上限，限制因應傳入要求而調度的執行個體數量。您可以使用這項設定控管費用，或限制與資料庫等後端服務的連線數量。

搭配使用這些設定和每個執行個體的並行設定 (第 2 代新增)，即可控管及調整函式的資源調度行為。應用程式和函式的性質會決定哪些設定最符合成本效益，並能帶來最佳效能。

對於流量較低的部分應用程式，不支援多重並行功能的較低 CPU 選項是最佳選擇。如果冷啟動是重大問題，設定高並行和執行個體數量下限，可確保一組執行個體隨時保持暖機狀態，以便處理大量流量。

如果是流量極少的小型應用程式，設定較低的執行個體數量上限和較高的並行數量，可讓應用程式處理突發流量，而不會產生過多費用。不過請注意，如果執行個體數量上限設得太低，達到上限時可能會捨棄要求。

允許並行要求

在 Cloud Functions for Firebase (第 1 代) 中，每個執行個體一次只能處理一項要求，因此只能透過執行個體數量下限和上限設定，來調整資源調度行為。除了控管執行個體數量外，在 Cloud Functions for Firebase (第 2 代) 中，您也可以使用 concurrency 選項，控管每個執行個體可同時處理的要求數量。並行預設值為 80，但您可以設為 1 到 1000 之間的任何整數。

並行設定較高的函式可以吸收流量高峰，而不會冷啟動，因為每個執行個體可能都有一些空間。如果執行個體設定為最多處理 50 個並行要求，但目前只處理 25 個，則可以處理 25 個額外要求的尖峰，而不需要冷啟動新的執行個體。相較之下，如果並行設定僅為 1，要求量激增可能會導致 25 次冷啟動。

這個簡化的情境說明瞭並行處理可能帶來的效率提升。實際上，為了提高效率並減少冷啟動，並行處理的資源調度行為會更複雜。Cloud Functions for Firebase 第 2 代的並行功能由 Cloud Run 提供，並遵循 Cloud Run 的容器執行個體自動調度資源規則。

在 Cloud Functions for Firebase (第 2 代) 中測試較高的並行設定時，請注意下列事項：

並行設定越高，可能需要越高的 CPU 和 RAM 才能達到最佳效能，直到達到實際限制為止。舉例來說，如果函式會執行大量圖片或影片處理作業，即使 CPU 和 RAM 設定已達上限，也可能沒有足夠的資源處理 1,000 項並行要求。
由於 Cloud Functions for Firebase (第 2 代) 是由 Cloud Run 提供技術支援，您也可以參閱 Google Cloud 指南，瞭解如何最佳化並行。
在正式環境中切換至多重並行模式之前，請務必在測試環境中徹底測試多重並行模式。

將特定數量的執行個體維持在暖機狀態

您可以在原始碼中設定函式的執行個體數量下限。舉例來說，這個函式會設定至少 5 個執行個體保持暖機狀態：

Node.js

const { onCall } = require("firebase-functions/v2/https");

exports.getAutocompleteResponse = onCall(
  {
    // Keep 5 instances warm for this latency-critical function
    minInstances: 5,
  },
  (event) => {
    // Autocomplete user’s search term
  }
);

Python

@https_fn.on_call(min_instances=5)
def get_autocomplete_response(event: https_fn.CallableRequest) -> https_fn.Response:

設定執行個體數量下限時，請考量以下幾點：

如果 Cloud Functions for Firebase 將應用程式擴充至超過設定值，則超過該門檻的每個執行個體都會發生冷啟動。
冷啟動對流量不穩定的應用程式影響最大。如果應用程式的流量不穩定，且您設定的值夠高，每次流量增加時冷啟動次數都會減少，延遲時間也會大幅縮短。如果應用程式流量穩定，冷啟動不太可能嚴重影響效能。

設定最少的執行個體可能適用於正式環境，但通常應避免在測試環境中使用。如要在測試專案中將資源調度率降至零，但仍減少正式版專案的冷啟動次數，可以在參數化設定中設定執行個體數量下限值：

Node.js

const { onRequest } = require('firebase-functions/https');
const { defineInt, defineString } = require('firebase-functions/params');

// Define some parameters
const minInstancesConfig = defineInt('HELLO_WORLD_MININSTANCES');
const welcomeMessage = defineString('WELCOME_MESSAGE');

// To use configured parameters inside the config for a function, provide them 
// directly. To use them at runtime, call .value() on them.
export const helloWorld = onRequest(
  { minInstances: minInstancesConfig },
(req, res) => {
    res.send(`${welcomeMessage.value()}! I am a function.`);
  }
);

Python

MIN_INSTANCES = params.IntParam("HELLO_WORLD_MININSTANCES")
WELCOME_MESSAGE = params.StringParam("WELCOME_MESSAGE")

@https_fn.on_request(min_instances=MIN_INSTANCES.value())
def get_autocomplete_response(event: https_fn.Request) -> https_fn.Response:
    return https_fn.Response(f"{WELCOME_MESSAGE.value()} I'm a function.")

限制函式的執行個體數量上限

您可以在函式原始碼中設定執行個體數量上限。舉例來說，這個函式設定了 100 個執行個體的上限，以免假設的舊版資料庫不堪負荷：

Node.js

const { onMessagePublished } = require("firebase-functions/v2/pubsub");

exports.mirrorevents = onMessagePublished(
  { topic: "topic-name", maxInstances: 100 },
  (event) => {
    // Connect to legacy database
  }
);

Python

@pubsub_fn.on_message_published(topic="topic-name", max_instances=100)
def mirrorevents(event: pubsub_fn.CloudEvent):
#  Connect to legacy database

如果 HTTP 函式已擴充至執行個體數量上限，新要求會排入佇列 30 秒，如果屆時沒有可用的執行個體，則會遭到拒絕，並傳回 429 Too Many Requests 回應代碼。

如要進一步瞭解使用執行個體數量上限設定的最佳做法，請參閱設定執行個體數量上限的最佳做法。

設定服務帳戶

函式的預設服務帳戶具備廣泛權限，可讓您與其他 Firebase 和 Google Cloud 服務互動：

第 2 代函式： PROJECT_NUMBER-compute@developer.gserviceaccount.com (名為「Compute Engine 預設服務帳戶」)
第 1 代函式： PROJECT_ID@appspot.gserviceaccount.com (名為「App Engine 預設服務帳戶」)

您可能需要覆寫預設服務帳戶，並將函式限制為僅能存取所需資源。方法是建立自訂服務帳戶，並使用 serviceAccount 設定值將其指派給適當的函式：

const { onRequest } = require("firebase-functions/https");

exports.helloWorld = onRequest(
    {
        // This function doesn't access other Firebase project resources, so it uses a limited service account.
        serviceAccount:
            "my-limited-access-sa@", // or prefer the full form: "my-limited-access-sa@my-project.iam.gserviceaccount.com"
    },
    (request, response) => {
        response.send("Hello from Firebase!");
    },
);

如要為所有函式設定相同的服務帳戶，可以使用 setGlobalOptions 函式。

設定逾時和記憶體配置

在某些情況下，函式可能需要較長的逾時值或較大的記憶體分配量。您可以在 Google Cloud 控制台或函式原始碼 (僅限 Firebase) 中設定這些值，並使用下列最長持續時間限制內的逾時值：

HTTP 和可呼叫函式：3600 秒 (60 分鐘)
排定/工作佇列函式：1800 秒 (30 分鐘)
其他事件導向函式：540 秒 (9 分鐘)

如要在函式原始碼中設定記憶體配置和逾時，請使用記憶體和逾時秒數的全域選項，自訂執行函式的虛擬機器。舉例來說，這個 Cloud Storage 函式使用 1 GiB 的記憶體，並在 300 秒後逾時：

Node.js

exports.convertLargeFile = onObjectFinalized({
  timeoutSeconds: 300,
  memory: "1GiB",
}, (event) => {
  // Do some complicated things that take a lot of memory and time
});

Python

@storage_fn.on_object_finalized(timeout_sec=300, memory=options.MemoryOption.GB_1)
def convert_large_file(event: storage_fn.CloudEvent):
# Do some complicated things that take a lot of memory and time.

如要在 Google Cloud 控制台設定記憶體配置和逾時，請按照下列步驟操作：

在 Google Cloud 控制台中，選取左選單中的「Cloud Functions for Firebase」。
在函式清單中點選函式名稱，即可選取函式。
按一下頂端選單中的「編輯」圖示。
從「Memory allocated」(已分配記憶體) 下拉式選單中選取記憶體配置。
按一下「More」(更多) 顯示進階選項，然後在「Timeout」(逾時) 文字方塊中輸入秒數。
按一下「儲存」來更新函式。

覆寫 CPU 預設值

Cloud Functions for Firebase (第 2 代) 中的每個函式最多可分配 2 GB 記憶體，預設為一個 CPU，然後增加到 2 個 CPU，用於 4 和 8 GB。請注意，這與第 1 代預設行為有顯著差異，可能會導致低記憶體函式的費用略高，如下表所示：

分配的 RAM	第 1 版預設 CPU (小數)	第 2 版預設 CPU	每毫秒價格增幅
128MB	1/12	1	10.5 倍
256MB	1/6	1	5.3 倍
512MB	1/3	1	2.7 倍
1GB	7/12	1	1.6 倍
2GB	1	1	1x
4GB	2	2	1x
8GB	2	2	1x
16 GB	不適用	4	不適用

如果您希望第 2 代函式採用第 1 代行為，請將第 1 代預設值設為全域選項：

Node.js

// Turn off Firebase defaults
setGlobalOptions({ cpu: 'gcf_gen1' });

Python

# Use 1st gen behavior
set_global_options(cpu="gcf_gen1")

如果是 CPU 密集型函式，第 2 代可讓您彈性設定額外的 CPU。您可以逐一提高函式的 CPU，如下所示：

Node.js

// Boost CPU in a function:
export const analyzeImage = onObjectFinalized({ cpu: 2 }, (event) => {
  // computer vision goes here
});

Python

# Boost CPU in a function:
@storage_fn.on_object_finalized(cpu=2)
def analyze_image(event: storage_fn.CloudEvent):
# computer vision goes here

管理函式 透過集合功能整理內容 你可以依據偏好儲存及分類內容。

部署函式

清除部署構件

停用構件清理功能

刪除函式

修改函式的名稱、區域或觸發條件

重新命名函式

Node.js

Python

變更函式的一或多個區域

Node.js

Python

變更函式的觸發條件類型

Node.js

Python

設定執行階段選項

設定 Node.js 版本

升級 Node.js 執行階段

選擇 Node.js 模組系統

設定 Python 版本

控管資源調度行為

允許並行要求

將特定數量的執行個體維持在暖機狀態

Node.js

Python

Node.js

Python

限制函式的執行個體數量上限

Node.js

Python

設定服務帳戶

設定逾時和記憶體配置

Node.js

Python

覆寫 CPU 預設值

Node.js

Python

Node.js

Python

管理函式