本頁面提供設定 Firebase 專案的一般高階最佳做法，以及將應用程式註冊至專案的最佳做法，協助您建立開發工作流程，並使用不同的環境。熟悉本頁的最佳做法後，請參閱一般安全性指南。
瞭解 Firebase 專案的階層結構
這張圖顯示 Firebase 專案的基本階層。以下是主要關係：
Firebase 專案就像是容器，可容納所有應用程式，以及為專案佈建的任何資源和服務。
一個 Firebase 專案可以註冊一或多個 Firebase 應用程式 (例如應用程式的 iOS 和 Android 版本，或是應用程式的免費和付費版本)。
註冊至同一個 Firebase 專案的所有 Firebase 應用程式共用並存取為專案佈建的所有相同資源和服務。例如：
註冊至相同 Firebase 專案的所有 Firebase 應用程式，都會共用相同的後端，例如 Firebase Hosting、Authentication、Realtime Database、Cloud Firestore、Cloud Storage 和 Cloud Functions。
註冊至相同 Firebase 專案的所有 Firebase 應用程式，都會與同一個 Google Analytics 資源建立關聯，而每個 Firebase 應用程式都是該資源中的個別資料串流。
Google Cloud 專案在這個階層中位於哪個位置？
上圖未顯示 Firebase 專案階層架構的其中一個層面，就是與 Google Cloud 專案的關係。Firebase 專案實際上只是Google Cloud專案，但已啟用額外的Firebase 專屬設定和服務。 請注意，註冊至相同 Firebase 專案的所有應用程式，也會共用並存取所有相同的 Google Cloud 資源和服務。
如要進一步瞭解 Firebase 和 Google Cloud 之間的關係，請參閱「瞭解 Firebase 專案」一文。
向 Firebase 專案註冊應用程式變體
向 Firebase 專案註冊應用程式變體時，請參考以下重要提示：
請確保註冊至 Firebase 專案的所有應用程式，從使用者角度來看，都是相同應用程式的平台變體。使用相同的 Firebase 專案，註冊同一款應用程式或遊戲的 iOS、Android 和網頁版本。
如果您有多個可共用相同 Firebase 資源的建構變數，請使用相同的 Firebase 專案註冊這些變數。舉例來說，同一專案中的網誌和網頁應用程式，或是同一專案中應用程式的免費版和付費版。
如果您有多個以發布狀態為依據的建構變體 (而非以常見的消費者活動或存取權為依據，如上所述)，請為每個變體註冊個別的 Firebase 專案。舉例來說，您可分別在各自的 Firebase 專案中註冊偵錯和發布子版本。
根據發布狀態建構的版本不應共用相同的 Firebase 資源，否則可能會導致偵錯資料汙染或甚至覆寫正式版資料。
每個建構變數的平台變數應位於相同的 Firebase 專案中。舉例來說，在「開發」Firebase 專案中同時註冊 iOS 和 Android 的偵錯建構版本，因為這兩個版本都可以與相同的非正式版資料和資源互動。
避免多用戶群
多租戶可能會導致嚴重的設定和資料隱私權疑慮，包括分析匯總、共用驗證、過於複雜的資料庫結構，以及安全性規則方面的問題。
一般來說，如果一組應用程式未共用相同的資料和設定，強烈建議您為每個應用程式註冊不同的 Firebase 專案。
舉例來說，如果您開發的是白標應用程式，每個獨立標記的應用程式都應有自己的 Firebase 專案，而該標籤的 iOS 和 Android 版本應位於同一個 Firebase 專案中。基於隱私權考量，每個獨立標記的應用程式不應與其他應用程式共用資料。
後續步驟
請參閱不同環境的一般安全守則。確保每個環境及其資料安全無虞。
詳閱 Firebase 發布檢查清單。