Xcode 14 Beta1 SwiftUI中如何声明返回View的函数类型

近期在使用最新版SwiftUI与Xcode 14探索NavigationStack的程序化导航能力时，基于值类型的NavigationLink配合.navigationDestination修饰符实现了基础导航逻辑，初始实现代码如下：

enum Destination: String, CaseIterable, Hashable {
    case view1, view2 
}

struct Navigation: View {
    @State private var path: [Destination] = []
    var body: some View {
        NavigationStack(path: $path) {
            NavigationLink(value: Destination.view1, label: {
                Text("Go to View1")
            })
            .navigationDestination(for: Destination.self, destination: { path in
                switch path {
                    case .view1: View1()
                    case .view2: View2()
                }
            })
            .navigationTitle("Root View")
        }
    }
}

尝试用函数式思路重构，用回调数组替换switch分支时遇到编译错误。首先定义了回调数组的类型别名与实例：

typealias Paths = [((Destination) -> Bool, () -> any View)]
private lazy var navigation: Paths = [
    ({ $0 == .view1 }, { View1() }),
    ({ $0 == .view2 }, { View2() })
]

将原switch逻辑替换为数组匹配调用：

navigation.first { $0.0(path) }?.1()

此时编译器抛出错误：Type 'any View' cannot conform to 'View'。尝试过让回调返回some View、直接返回View协议类型均无法通过编译，目前仅能通过AnyView擦除类型临时解决，但该方案会丢失具体View类型信息，不是理想实现。

出现该错误的核心原因是Swift的类型系统限制：

• some View是不透明返回类型，要求单个分支/回调必须返回固定的具体View类型，数组中不同元素的回调如果返回不同View（比如View1、View2），类型不统一无法存入同个数组
• any View是存在类型，仅代表“实现了View协议的某个类型”的包装盒，本身并不实现View协议，SwiftUI的navigationDestination修饰符要求闭包返回的类型必须静态遵循View协议，因此直接返回any View会触发编译错误
• AnyView虽然能解决编译问题，但会带来额外的性能开销，还会破坏SwiftUI的视图差分更新逻辑，确实不是最优解

方案1：给Destination枚举直接添加视图构建逻辑（推荐） #

这是类型最安全、性能开销最低的实现方式，完全不需要引入回调数组，直接把视图映射逻辑绑定到枚举本身，和switch逻辑本质一致但更易维护：

enum Destination: String, CaseIterable, Hashable {
    case view1, view2

    @ViewBuilder
    @MainActor
    func buildView() -> some View {
        switch self {
        case .view1: View1()
        case .view2: View2()
        }
    }
}

// 调用时直接写
.navigationDestination(for: Destination.self) { path in
    path.buildView()
}

该实现完全保留了所有View的具体类型信息，没有类型擦除开销，新增路由时只需要在枚举中加case和对应构建逻辑即可，维护成本极低。

方案2：结合Result Builder构建路由表 #

如果确实想抽离统一的路由匹配逻辑，可以自定义轻量的Result Builder来管理路由映射，路由数量较多时也可以配合代码生成工具自动生成视图匹配逻辑，全程无类型擦除：

@resultBuilder
enum NavigationRouteBuilder {
    static func buildBlock(_ components: (Destination, any View)...) -> [Destination: any View] {
        Dictionary(uniqueKeysWithValues: components)
    }
}

// 统一管理路由表
struct RouteTable {
    @NavigationRouteBuilder
    static func mappings() -> [Destination: any View] {
        Destination.view1 : View1()
        Destination.view2 : View2()
    }

    @ViewBuilder
    static func resolve(_ destination: Destination) -> some View {
        switch destination {
        case .view1: View1()
        case .view2: View2()
        }
    }
}

// 调用方式
.navigationDestination(for: Destination.self) { path in
    RouteTable.resolve(path)
}

方案3：局部匹配分支返回具体类型 #

如果一定要贴近函数式数组匹配的写法，不要把回调返回值统一声明为any View，而是在匹配到对应路由项后直接返回固定的具体View类型，本质和分支判断逻辑一致，没有额外的类型擦除开销：

.navigationDestination(for: Destination.self) { path in
    for (matcher, viewBuilder) in navigation where matcher(path) {
        viewBuilder()
        // 注意此处viewBuilder需要按具体路由分别声明返回类型，不可统一抹成any View
    }
}

• 不要为了追求函数式写法强行破坏SwiftUI的类型系统，SwiftUI本身就是基于静态类型的视图框架，保留具体View类型才能获得最优的渲染性能
• 全局使用AnyView擦除类型会导致SwiftUI无法判断视图的具体类型变化，可能引发不必要的视图重绘、动画异常等问题，非必要不要使用

内容的提问来源于stack exchange，提问作者Angelo Sannino