遇到 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(
'https://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(
'https://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 https://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 或异步语法。流式响应本身并不禁止后续请求，但服务器架构决定了其是否能够真正响应并发请求。
