模拟器可能只是将请求直接传递到macOS上的NSURLSession，因此模拟器的行为与macOS版本一致是有道理的。
这听起来像是macOS 12和iOS 15中的性能倒退。如果您还没有提交错误，请向反馈助手提交错误，并附上最低可重复的样本。
在我的脑海中，我想不出任何原因，你会看到一个短暂的和后台会话之间的可测量的性能差异，除非进程外的助手运行在一个太低的优先级。
后台任务和后台下载在某种程度上是正交的。前者在您的应用程序中运行，因此如果您的应用程序崩溃，它们将失败。后者在单独的进程中运行，因此它们独立于您的应用是否正在运行。后台下载更适合大型下载，特别是如果您的应用规模较大，因为这意味着iOS可以在不终止下载的情况下驱逐您的应用。
另一个明显的问题是，你是否曾经在后台启动过一项任务（例如：例如，响应于另一任务的完成）。后者很可能会受到限制，特别是如果您在后台上传或下载完成后开始新的传输。你可以通过合并资源并将它们上传到一个blob中来避免这种损失。例如zip文件）。从你的问题我假设你不是，但我只是想确定一下。：—）
我还假设这是通过Wi-Fi或网络不可知的，因为你也可以在macOS上看到它。
最后，我假设这不是HTTP/3（QUIC）问题。当然，这是iOS 15和macOS 12中NSURLSession最大的变化，所以如果我指责的话，这将是我的第一个嫌疑人。
我不知道这种或那种方式，但我可以很容易地看到苹果决定禁用该功能的短暂会话，因为它可能是或可能不是微不足道的，以避免存储cookie等。当您重用连接并并行发出多个请求时。
如果这就是问题所在，您可以看看是否有某种方法可以在服务器端或客户端禁用该功能。我不知道一个方法来做到这一点从我的头顶上，虽然。

我自己也曾与这个问题作过斗争，我想分享解决方案-为其他人，也为未来的我，当我再次遇到这个问题并不可避免地忘记时：要修复使用后台会话配置的上传的缓慢下载速度，请确保配置请求的网络服务类型-此设置适用于我：

var request = URLRequest(...)
// configure request
request.networkServiceType = .responsiveData

.responsiveAV也为我工作。请确保您只在上传及时发生很重要的情况下才设置此选项-如果不重要，只需将其交给后台会话并适当配置超时，然后让它继续进行。
注意：只有在应用程序处于前台时启动上传任务时，这才会产生影响。如果上传任务在应用程序已经在后台时开始（例如，您需要先执行一些其他工作，并延长后台执行时间，然后恢复上传任务），则它将忽略此情况，并表现为好像您已将其设置为.background，这将与之前一样慢，因为在后台启动的请求会受到严重限制。