Axios流式响应嵌套请求挂起问题解决

遇到 Axios 在 Node.js 环境下处理流式响应（`responseType: 'stream'`）时，若在 `stream.on('data')` 回调内部发起另一个 Axios 请求却始终无响应——先别急着排查代码逻辑，问题大概率出在后端服务器的并发处理能力上。

使用 Axios 订阅服务端的 SSE 或 HTTP 流（例如 `/subscribe` 接口）时，许多开发者容易将流式请求与后续的同步/异步逻辑混为一谈。实际上代码语法本身并无错误，Promise 未被拦截，异常也做了处理——就像下面这段示例：

import axios from 'axios';

const getTasks = async () => {
  const { data: stream } = await axios.get(
    'http://127.0.0.1:8000/agent/runners/1/subscribe',
    { responseType: 'stream' }
  );

  stream.on('data', async (chunk) => {
    console.log('received data'); // ✅ 正常触发
    try {
      const response = await axios.get(
        'http://127.0.0.1:8000/agent/runners/1/tarball-download-url'
      );
      console.log('response', response.data); // ❌ 从未执行
    } catch (err) {
      console.error('Nested request failed:', err.message);
    }
  });
};

getTasks();

表面上看 `await axios.get(...)` 在 `data` 事件的回调中应当正常执行，但实际这个 Promise 永远处于 pending 状态。根本原因在于：后端服务器无法同时处理多个并发请求。

举例来说，Laravel 默认的 PHP 内置开发服务器（`php artisan serve`）是单进程、阻塞式架构，每次只能服务一个请求。当 `/subscribe` 接口返回一个长连接流（HTTP chunked encoding，连接持续保持），这个连接就会永久占用一个 PHP 进程。此时如果客户端紧接着请求 `/tarball-download-url`，该请求就会被排队，甚至直接阻塞——只有等前面的流连接关闭才能轮到它。但流的本意是永不关闭，于是后端压根没有开始处理请求，Axios 的 Promise 自然永远无法 resolve。

✅ 验证方法

• 单独使用 curl -v http://127.0.0.1:8000/agent/runners/1/tarball-download-url 测试该接口——如果能立即返回，说明接口本身正常。
• 开启两个 curl 窗口：一个连接 /subscribe（保持连接），另一个立即请求 /tarball-download-url——如果后者超时或卡住，则表明服务器存在并发瓶颈。

? 解决方案（Laravel 场景）：升级到支持高并发的 Laravel Octane（基于 Swoole 或 RoadRunner）。

# 安装 Octane
composer require laravel/octane

# 启动 Octane 服务（替代 php artisan serve）
php artisan octane:start --server=swoole

Octane 采用常驻内存的异步事件循环，使多个 HTTP 请求真正并行处理——流式连接不会再阻塞其他请求。

⚠️ 其他注意事项

• 尽量避免在 stream.on('data') 中直接 await 大量网络请求。建议引入限流机制（如 p-limit）、错误重试和超时控制。
• Node.js 端务必监听 stream.on('error') 和 stream.on('end')，防止未捕获的异常导致进程崩溃。
• 如果并非 Laravel 环境（例如 Express、Fastify），请确保使用支持并发的 HTTP 服务器——Node 自带的 node:http 原生模块默认即可胜任，无需额外配置。

总结一下：该问题的本质是“前端假死，后端阻塞”。调试此类场景时，应优先排查服务端的并发模型，不要一上来就怀疑 Axios 或异步语法。流式响应本身并不禁止后续请求，但服务器架构决定了其是否能够真正响应并发请求。