Swift中URLSessionTask.resume()是否阻塞及服务端多轮交互方案

task.resume() 是否为阻塞调用 #

• 答案是完全不阻塞。URLSessionTask的所有任务默认都是异步执行的，调用resume()之后系统会把网络任务放到后台调度队列里执行，当前调用resume()的线程会立刻继续执行后续代码，不会卡在这里等请求返回。你传入的completion回调（即代码中的PostCompletion）会在请求结束（成功拿到响应/报错/超时）后，由URLSession调度到对应队列执行，默认回调队列是后台子线程，不会阻塞发起请求的线程。
• 顺便提两个容易踩的问题：
  • 不要在URLSession初始化完成后修改session.configuration的属性，包括httpAdditionalHeaders，初始化后的configuration是只读拷贝，修改不会生效。要加自定义请求头直接给URLRequest的allHTTPHeaderFields属性赋值即可。
  • 你写的DoPost() -> Bool返回值没有实际意义：resume()调用时请求才刚被提交调度，根本还没拿到执行结果，不可能在这个方法里直接返回请求成功/失败的状态，结果处理必须放到回调里，或者用后面提到的异步方案接收返回值。

多轮会话式交互的标准实现方案 #

需要按顺序执行多轮请求、上一轮结果作为下一轮输入的场景，不要手动在工作线程加锁/忙等卡线程等回调，苹果生态有成熟的标准实现，按你支持的系统版本选即可：

• 如果你支持iOS 13+/macOS 10.15及以上系统，优先用原生Swift async/await语法，这是目前官方推荐的异步实现方案，写顺序交互逻辑和写同步代码逻辑一致，完全没有回调嵌套的问题。示例封装如下：

// 把POST请求封装为async方法
func doPost() async throws -> Data {
    guard let url = m_TargetUrl else { throw URLError(.badURL) }
    var request = URLRequest(url: url)
    request.httpMethod = "POST"
    request.httpBody = m_Params?.data(using: .utf8)
    request.allHTTPHeaderFields = m_Headers // 直接给request赋值头，不要改session配置
    
    let (data, response) = try await m_Session.data(for: request)
    // 校验响应合法性
    guard let httpResp = response as? HTTPURLResponse,
          (200...299).contains(httpResp.statusCode) else {
        throw URLError(.badServerResponse)
    }
    return data
}

// 多轮交互逻辑直接按顺序写即可
func runMultiRoundConversation() async {
    do {
        // 第一轮请求
        let firstRoundData = try await doPost()
        // 基于第一轮返回构造第二轮参数
        m_Params = generateNextParams(from: firstRoundData)
        // 第二轮请求
        let secondRoundData = try await doPost()
        // 后续轮次按相同逻辑顺序写即可，无需嵌套回调
    } catch {
        // 统一处理所有轮次的请求错误
        print("交互出错: \(error.localizedDescription)")
    }
}

• 如果需要兼容更低版本的系统，可以用DispatchSemaphore在你自己的工作线程里控制请求顺序，注意绝对不能在主线程调用semaphore.wait()，否则会直接卡死UI。
• 如果需要跨请求维持会话状态（比如Cookie、鉴权token），全程复用同一个URLSession实例即可：默认配置的URLSession会自动持久化管理Cookie，你也可以实现URLSessionDelegate统一处理所有请求的签名、token自动刷新等逻辑，不用在每轮请求里重复写鉴权代码。
• 如果不想自己处理调度逻辑，也可以用Promise类库链式组织请求，但原生async/await已经能覆盖绝大多数场景，优先选原生方案即可。

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