SwiftUI两种NavigationLink实现方式的可读性与扩展性差异

你和讲师的代码核心差异在于导航模式的选择：讲师用的是SwiftUI 3+引入的基于值的导航，而你用的是传统的直接绑定目标视图的导航方式，两者在可读性和扩展性上各有侧重：

一、可读性对比 #

讲师的写法 #

• 逻辑拆分清晰：列表部分只负责展示用户数据并传递User值，导航目标的映射（即点击User要跳转到哪个视图）统一放在navigationDestination修饰器中管理。这种写法把“数据传递”和“目标视图关联”拆成两个独立部分，适合复杂项目中统一把控导航规则。
• 学习门槛稍高：对刚接触SwiftUI的开发者来说，需要理解NavigationLink(value:)和navigationDestination(for:)的绑定关系，不像直接写目标视图那么直观。

你的写法 #

• 直观易懂：NavigationLink内部直接定义了跳转的目标视图DetailView，看到代码就能立刻明白点击这个列表项会跳转到哪里，逻辑闭环感强，新手友好度更高。
• 代码关联性强：导航行为和目标视图紧耦合在一起，阅读时不需要跳转到其他位置找导航规则。

另外提个小细节：讲师用的List(users) { user in }是SwiftUI对List { ForEach(users) { user in } }的简化写法，两者功能完全一致，前者更简洁，后者显式使用ForEach在需要自定义列表项分组、添加额外视图时更灵活。

二、扩展性对比 #

讲师的写法（基于值的导航） #

• 可复用性高：如果项目中有多个地方需要跳转到User的详情页，只需要在对应NavigationStack下添加navigationDestination，所有传递User值的NavigationLink都会自动关联到目标视图，不用重复写DetailView(user: user)。
• 支持复杂导航场景：后续如果需要给User类型新增不同的导航目标（比如管理员端跳转到UserManageView，普通用户跳转到DetailView），只需要新增一个navigationDestination(for: User.self)分支即可；同时支持程序化导航，通过navigationPath数组可以直接控制导航栈的推送/弹出，适合多页面层级的复杂应用。
• 维护成本低：要修改User对应的目标视图时，只需要修改navigationDestination里的代码，不用逐个修改所有NavigationLink。

你的写法（直接目标式导航） #

• 扩展性弱：如果后续需要修改User的跳转目标，或者新增不同场景的跳转逻辑，必须找到所有用到这个NavigationLink的地方逐个修改，代码冗余且容易漏改。
• 不支持程序化导航：无法通过navigationPath直接控制导航栈，只能通过点击NavigationLink触发跳转，应对复杂导航需求时会受限。

内容的提问来源于stack exchange，提问作者Milan Labus