本頁面由 Cloud Translation API 翻譯而成。

自訂您的身份驗證依賴項

Firebase JS SDK 的模組化設計可讓您更好地控制應用程式的建置方式。這種靈活性使您可以根據平台自訂依賴項，並透過剝離不需要的功能來優化捆綁包大小。

有兩種方法可以初始化Auth函式庫： getAuth()函數和initializeAuth()函數。第一個getAuth()提供了您的應用程式所需的一切，以便利用 Auth 庫提供的所有功能。缺點是它會引入大量您的應用程式可能未使用的程式碼。它還可能會引入您所定位的平台根本不支援的程式碼，從而導致錯誤。為了避免這些問題，您可以使用initializeAuth() ，它會取得依賴關係圖。 getAuth()函數只需呼叫initializeAuth()並指定所有依賴項。為了說明這一點，這裡與瀏覽器環境中的getAuth()等效：

import {initializeAuth, browserLocalPersistence, browserPopupRedirectResolver, browserSessionPersistence, indexedDBLocalPersistence} from "firebase/auth";
import {initializeApp} from "firebase/app";

const app = initializeApp({/** Your app config */});
const auth = initializeAuth(app, {
  persistence: [indexedDBLocalPersistence, browserLocalPersistence, browserSessionPersistence],
  popupRedirectResolver: browserPopupRedirectResolver,
});

定制您的依賴項

並非所有應用程式都使用signInWithPopup或signInWithRedirect系列函數。許多應用程式不需要indexedDB提供的靈活性，或不需要同時支援indexedDB和localStorage （如果兩者不可用）的能力。在這些情況下，預設的getAuth()包含大量未使用的程式碼，這些程式碼無緣無故地增加了套件的大小。相反，這些應用程式可以自訂它們的依賴項。例如，如果您的應用程式僅使用電子郵件連結驗證且 localStorage 就足夠了（因為您沒有使用 Web 或 Service Worker 腳本），則可以透過像這樣初始化 Auth 來消除大量程式碼膨脹：

import {initializeAuth, browserLocalPersistence} from "firebase/auth";
import {initializeApp} from "firebase/app";

const app = initializeApp({/** Your app config */});
const auth = initializeAuth(app, {
  persistence: browserLocalPersistence,
  // No popupRedirectResolver defined
});

使用此程式碼，您已經刪除了應用程式不需要的三個大型依賴項，從而顯著減少了使用者每次造訪您的網站時所使用的頻寬量。

特定於平台的注意事項

在許多情況下，您需要手動定義 Auth 依賴項以避免初始化錯誤。 getAuth()函數假定特定平台。對於預設入口點，這是一個瀏覽器環境；對於 Cordova 入口點，這是一個 Cordova 環境。但有時您的特定應用程式的需求與這些假設發生衝突。例如，對於 Web 和 Service Worker 腳本，預設的getAuth()實作會引入從window物件讀取的程式碼，這將導致錯誤。在這些情況下，有必要自訂您的依賴項。以下程式碼適合在服務工作執行緒上下文中初始化 Auth 庫：

import {initializeAuth, indexedDBLocalPersistence} from "firebase/auth";
import {initializeApp} from "firebase/app";

const app = initializeApp({/** Your app config */});
const auth = initializeAuth(app, {
  persistence: indexedDBLocalPersistence,
  // No popupRedirectResolver defined
});

此程式碼指示 Auth 使用indexedDB持久性（在工作上下文中可用）進行初始化，並省略popupRedirectResolver依賴項，該依賴項假定 DOM 上下文可用。

您可能還會出於其他原因手動定義某些平台上的依賴項。透過在 Auth 初始化中定義popupRedirectResolver字段，在某些情況下，程式庫將在初始化時執行額外的工作。在行動瀏覽器上，該程式庫將自動搶先開啟一個指向您的 Auth 網域的 iframe。這樣做是為了讓大多數用戶獲得無縫體驗，但它可能會在應用程式啟動時加載額外的程式碼，從而影響效能。可以透過利用initializeAuth()並手動將browserPopupRedirectResolver依賴項傳遞給需要它的函數來避免此行為：

import {initializeAuth, browserLocalPersistence, browserPopupRedirectResolver, indexedDBLocalPersistence, signInWithRedirect, GoogleAuthProvider} from "firebase/auth";
import {initializeApp} from "firebase/app";

const app = initializeApp({/** Your app config */});
const auth = initializeAuth(app, {
  persistence: [indexedDBLocalPersistence, browserLocalPersistence],
});

// Later
signInWithRedirect(auth, new GoogleAuthProvider(), browserPopupRedirectResolver);

如果我們在initializeAuth()的依賴項中提供了browserPopupRedirectResolver ，則不需要signInWithRedirect()呼叫中的第三個參數。但是，透過直接將該依賴項移至對signInWithRedirect()的調用，可以消除初始化期間的初始效能影響。移動依賴項會帶來一些權衡，但重要的是您可以透過手動初始化庫來做出有關這些權衡的決定。

何時使用自訂初始化

回顧一下，自訂初始化可讓您更好地控制應用程式對 Auth SDK 的使用。標準getAuth()函數非常適合入門並適用於大多數用例。對於大多數應用程序， getAuth()可能是您所需要的。但您可能希望（或需要）切換到手動依賴項管理的原因有很多：

對於捆綁包大小和載入時間極為重要的應用程序，自訂身份驗證初始化可能會減少數千位元組的資料。它還可以透過將依賴項移至使用時間而不是初始化時間來減少初始載入時間。
對於在非 DOM 上下文中執行的程式碼（例如 Web 和服務工作人員），必須使用initializeAuth()以避免錯誤。