引言：跳轉的混亂與優雅的必要性

SwiftUI 給我們帶來了聲明式界面的全新開發體驗，但當涉及到頁面跳轉時，許多開發者仍然面臨一些“舊痛”。最初的?NavigationLink(destination:isActive:)?或?sheet(isPresented:)?等方式雖然能用，卻往往邏輯零散、狀態雜亂、代碼重復，不僅容易出 bug，還極難維護和擴展。

隨著項目變得復雜，比如一個 App 包含多個跳轉入口、嵌套多層頁面、需要根據業務數據跳轉不同路徑時，這些原始跳轉方式就會變得捉襟見肘。跳轉的狀態管理和頁面間傳值混亂不堪，“優雅”幾乎無從談起。

幸運的是，從 iOS 16 開始，SwiftUI 引入了全新的?NavigationStack?和基于值驅動的導航機制，讓我們終于可以像使用路由系統那樣，統一管理跳轉路徑、明確跳轉目標，甚至像“堆棧”一樣控制頁面的推入與彈出。這種方式不僅結構清晰、可維護性高，而且完全符合 SwiftUI 聲明式編程的哲學。

本文將以一個 ?PHJumpDemo 項目?為例，帶你一步步搭建一套現代、優雅、可擴展的 SwiftUI 跳轉系統。

實踐：用小 PHJumpDemo 實現一套優雅的跳轉架構

為了更直觀地演示 SwiftUI中優雅跳轉的實現方式，我們創建了一個簡單的Demo項目——PHJumpDemo。它模擬了一個應用最基礎的跳轉需求：從首頁跳轉到“用戶信息頁”再跳轉到“編輯頁”，并支持返回上一級頁面，直接返回首頁，以及返回指定頁。整個項目結構簡潔明了，非常適合作為小中型APP的導航架構基礎。

1. 枚舉建模：統一管理所有頁面跳轉

在傳統 UIKit 中，我們習慣通過?pushViewController(_:animated:)?或?present(_:animated:)?等方式跳轉頁面，每次跳轉都得明確頁面類型、構造參數，跳轉邏輯常常散落在各個控制器中，既不集中又不安全。

而在 SwiftUI 的?NavigationStack?中，我們推薦使用一個枚舉（如?RoutePage）來統一描述所有頁面跳轉的可能性。每個枚舉 case 都代表一個頁面，同時也可以附帶參數，用于頁面初始化所需的數據。比如：

enum RoutePage: Hashable {/// 用戶信息頁case userInfo/// 編輯頁，附帶一個整型參數case edit(Int)
}

這里我們定義了兩個頁面跳轉目標：

1. userInfo：用戶信息頁面，無需額外參數。
2. edit(Int)：編輯頁面，接收一個整數參數（表示年齡）。

接下來，我們將基于這個枚舉，設計一個路由控制中心 ——?RouterHelper，用于集中管理跳轉邏輯和導航路徑。

2. 路由控制中心：RouterHelper 的職責與實現

有了?RoutePage?枚舉之后，我們還需要一個“跳轉控制中樞”，來管理整個應用的導航狀態。這個角色，就是?RouterHelper。

在 SwiftUI 的?NavigationStack?中，頁面跳轉是通過維護一個“路徑數組”來完成的。每當我們向這個數組中添加一個新元素（也就是某個頁面的枚舉值），就會觸發跳轉；而當我們移除最后一個元素時，就會回退一層頁面。

RouterHelper 的職責：

?

我們希望這個控制器具有以下功能：

• ? 集中管理跳轉狀態，避免跳轉邏輯分散在各個頁面。
• ? 提供統一的 API 接口（push、pop、popTo 等），使跳轉邏輯更語義化。
• ? 使用單例模式，確保整個應用導航狀態的一致性。

下面是完整的?RouterHelper?實現：

class RouterHelper: ObservableObject {/// 單例static let shared = RouterHelper()/// 路徑數組，代表導航棧@Published var path: [RoutePage] = []private init() {}/// 跳轉到某個路由func push(_ route: RoutePage) {path.append(route)}/// 返回上一級頁面func pop() {if !path.isEmpty {path.removeLast()}}/// 返回到指定頁func popTo(index: Int) {guard index >= 0 && index < path.count else { return }path = Array(path.prefix(upTo: index + 1))}/// 返回首頁，清空路徑func popToRoot() {path.removeAll()}
}

我們將?RouterHelper?設計為單例（shared?靜態實例），是為了確保全局導航狀態的一致性。整個 App 中所有頁面跳轉都依賴于這一個路徑棧（path），無論你從哪個頁面調用?push(.userInfo)，都能驅動統一的跳轉邏輯。

當然，在更大型的項目中，也可以通過依賴注入 +?@EnvironmentObject?的方式進一步解耦。但在像本 Demo 這樣的中小型項目中，單例無疑是最簡單直接的方案。

?

3. NavigationStack 的容器搭建

在前面兩節中，我們已經定義好了頁面路由?RoutePage?和跳轉控制器?RouterHelper，接下來就要將這些“跳轉能力”真正連接到 SwiftUI 的導航體系中。

SwiftUI 提供的?NavigationStack?是官方推薦的現代導航容器，它不僅能清晰地描述“頁面棧”的概念，還可以結合路徑值（如我們的?[RoutePage]）進行聲明式跳轉。

我們在?ContentView?中使用?NavigationStack，將?RouterHelper.shared.path?綁定為導航路徑：

struct ContentView: View {/// 路由@StateObject var router = RouterHelper.sharedvar body: some View {NavigationStack(path: $router.path) {HomeView().navigationDestination(for: RoutePage.self) { route inswitch route {case .userInfo:UserInfoView()case .edit(let age):EditView(age: age)}}}}
}

• @StateObject var router = RouterHelper.shared：將全局路由控制器注入到視圖中，保證綁定不會失效。
• NavigationStack(path:)：指定一個綁定的路徑數組（[RoutePage]），用于自動推入/推出頁面。
• navigationDestination(for:)：聲明所有可能出現的跳轉目標，并為每個枚舉值提供對應的頁面視圖。

這種寫法的核心優勢是：

• 聲明式跳轉：不用在 View 層維護?isActive?狀態，完全由路徑控制頁面棧。
• 統一跳轉入口：頁面 push/pop 只需要調用?RouterHelper.shared?的方法，頁面跳轉邏輯徹底脫離視圖層。
• 結構清晰可讀：每個跳轉頁面在?switch?中明確列出，不怕遺漏。

?

4. 跳轉調用：頁面中如何跳轉或返回

完成了?RoutePage?枚舉、RouterHelper?路由控制器和?NavigationStack?容器之后，頁面之間的跳轉就變得非常簡單、清晰。我們只需要在合適的位置調用?RouterHelper.shared.push(...)?或相關方法，就可以實現推入、返回、清棧等操作。

4.1 從首頁跳轉到用戶信息頁

首頁是我們導航的起點，點擊按鈕即可跳轉到用戶信息頁：

struct HomeView: View {var body: some View {VStack(spacing: 20) {Button("跳轉到用戶信息頁") {RouterHelper.shared.push(.userInfo)}}.navigationTitle("首頁")}
}

4.2 在用戶信息頁中跳轉并傳值到編輯頁

用戶信息頁可以繼續向下跳轉，同時通過枚舉的關聯值傳遞所需數據：

struct UserInfoView: View {var body: some View {VStack {Text("這是用戶信息頁")// 跳轉編輯頁，傳入年齡參數Button("跳轉到編輯頁") {RouterHelper.shared.push(.edit(10))}// 返回上一頁（即首頁）Button("返回上一頁") {RouterHelper.shared.pop()}}.navigationTitle("用戶信息")}
}

?

4.3 在編輯頁中顯示傳入參數，并返回首頁

我們在編輯頁中通過?EditView(age:)?接收參數，并提供“返回首頁”的按鈕：

struct EditView: View {/// 年齡參數var age: Intvar body: some View {VStack {Text("這是編輯頁")Text("年齡: \(age)")// 返回首頁Button("返回首頁") {RouterHelper.shared.popToRoot()}}.navigationTitle("編輯")}
}

?

結語：優雅跳轉的價值與實踐意義

通過本篇文章和一個精簡的 Demo 項目，我們完整演示了如何在 SwiftUI 中構建一套結構清晰、跳轉解耦、傳參靈活的頁面導航機制。整個方案基于 Apple 官方推薦的?NavigationStack?與?navigationDestination(for:)，并輔以枚舉建模與單例路由管理器，最終實現了如下幾個關鍵目標：

? 架構優勢回顧

1. 跳轉邏輯集中統一：所有頁面路徑集中定義在?RoutePage?枚舉中，避免“到處寫跳轉”的混亂局面。
2. 狀態管理高度抽象：通過?RouterHelper.shared?管理導航狀態，視圖層只負責“調用”，不關心“跳到哪”。
3. 聲明式導航，自動聯動視圖：路徑變化即代表頁面變化，完全符合 SwiftUI 的響應式設計理念。
4. 強類型傳參，避免出錯：枚舉的關聯值讓傳值變得安全可靠，不再依賴外部狀態。
5. 支持多層嵌套導航、靈活返回控制：無論是返回上一頁、返回指定頁面，還是返回首頁，方法清晰易用。

🚀 實踐落地與適用場景

這套架構適用于中小型 App 的多頁面跳轉場景，特別適合以下項目類型：

1. 頁面跳轉較多、傳參頻繁的工具類 App
2. 希望統一跳轉邏輯、減少視圖層邏輯耦合的項目
3. 漸進式演進：可在現有項目中逐步替換原有?NavigationLink?跳轉方式

當然，對于大型項目，你還可以在此基礎上引入路由表、依賴注入容器或更細粒度的導航模塊劃分，讓整體架構更具可擴展性和測試性。

?

?