SwiftUI新手咨询：按钮点击时Task的正确使用位置

作为SwiftUI新手，纠结按钮点击时Task的放置位置很正常，下面直接分析两种写法的差异和推荐方案：

方案1：Task放在Button闭包内 #

这种写法直接在按钮的点击回调里创建Task，适合逻辑极简的场景，比如示例里只是模拟延迟后更新加载状态：

struct DetailView: View {
    @State var loading = false
    
    var body: some View {
        Button("login") {
            Task {
                try! await Task.sleep(nanoseconds: 10_000_000_000)
                 loading = true
            }
        }
    }
}

优缺点：

• 优点：写法简单，上手快，不需要额外创建ViewModel。
• 缺点：业务逻辑和视图混在一起，后续如果登录逻辑变复杂（比如加真实网络请求、错误处理、用户信息存储），视图代码会变得臃肿不堪，而且逻辑没法复用，其他视图要做登录就得重复写一遍。

方案2：Task放在ViewModel的login方法里 #

这种写法遵循MVVM架构，把登录的业务逻辑放到ViewModel中，视图只负责触发操作和展示状态：

@MainActor
class LoginViewModel:ObservableObject{
    @Published var loading = false
    
    func login(){
        Task {
            try! await Task.sleep(nanoseconds: 10_000_000_000)
                 loading = true
        }
    }
}

对应的视图调用方式示例：

struct DetailView: View {
    @StateObject var viewModel = LoginViewModel()
    
    var body: some View {
        Button("login") {
            viewModel.login()
        }
        .disabled(viewModel.loading)
    }
}

优缺点：

• 优点：
  1. 逻辑和视图分离，视图只专注UI渲染，代码结构清晰，后期维护起来更方便；
  2. 登录逻辑可以复用，其他需要登录的视图直接调用viewModel.login()就行；
  3. @MainActor修饰ViewModel，确保更新@Published属性时在主线程，避免线程安全问题，比在视图里手动管理更规范；
  4. 后续扩展逻辑（比如错误处理、登录成功后的跳转逻辑）都可以在ViewModel里完成，不用动视图代码。
• 缺点：需要额外创建ViewModel类，对新手来说多了一层概念，但这是SwiftUI开发的标准模式，掌握后收益很大。

结论 #

如果只是写个小demo或者逻辑极其简单的场景，两种写法都能跑，但优先推荐ViewModel的方案——这是SwiftUI开发的最佳实践，能帮你养成良好的代码结构习惯，应对后续业务复杂度的提升。

另外补充个小提醒：不管用哪种方式，Button回调里创建的Task默认是在主线程执行的，ViewModel加了@MainActor也确保了主线程，所以更新UI状态（比如loading）不需要额外调用DispatchQueue.main.async。

内容的提问来源于stack exchange，提问作者余艳辉