我们正在编写一个大量使用 NSURLConnection 的 SDK。为了管理所有这些连接（例如，批量取消它们），最好它们都运行在单个线程（最好是主线程）上。由于 NSURLConnection 的异步特性，这并不是一个糟糕的想法——在我们的独立应用程序中，我们所有的连接都运行在主线程上，而连接后的繁重工作则在辅助线程（实际上是使用 GCD 或操作队列）上执行取得了结果，没有任何停顿。
所以问题是——在哪些情况下，用户希望在多个线程上运行连接，并且在不是主线程的线程上运行？
编辑：我想我没有正确解释自己。我们以异步而不是同步的方式使用 NSURLConnection。这允许我们在主线程上运行所有连接而不会阻塞 UI。问题是：我们的 SDK 用户何时希望在不同线程上异步运行这些连接？
当您有一个加载大量数据的请求并且您确定它会很慢并且您有一个需要经常呈现的 GUI 时。
这种情况下，如果 GUI（如在 Cocoa 中，GUI 在主线程中更新）在主线程中更新，请求太慢可能会导致所有视图停止显示，因为它们没有更新。
Apple 文档也这样说 sendSynchronousRequest:returningResponse:error ：
重要提示：由于此调用可能需要几分钟才能失败（尤其是在 iOS 中使用蜂窝网络时），因此您永远不应从 GUI 应用程序的主线程调用此函数。
我可以想象在另一个线程上运行异步 NSURLConnection 的唯一充分理由是，如果您的委托方法本身非常耗时。即便如此，我可能仍会在主线程上运行它，并将处理移至后台队列。
编辑：请注意，今天“将处理移至后台线程”非常容易。在 GCD 之前，这有点困难，因此在辅助线程上运行 NSURLConnection 本身在这种情况下可能更有用。当您将 NSURLConnection 嵌入到不在主线程上处理 runloop 的 C++ 应用程序中时，它仍然有些有用（这基本上仅适用于 Mac 应用程序）。
正如我相信你所理解的， NSURLConnection 已经管理了自己的后台线程供其内部使用。
简而言之，我相信您对此的直觉是正确的。答案是“几乎没有”。NSURLConnection 在主线程上最容易管理。