异步迭代器不会死锁，但网络中断未响应会导致next()永久pending；需数据源传播中断信号、消费端加超时与abortcontroller防护，并做好异常清理与重试。
异步迭代器（for await...of）本身不会“死锁”，但网络中断若未被正确响应，会导致迭代器卡在 next() 的 Promise 永远 pending，协程挂起、资源不释放、后续逻辑停滞——这种表象常被误称为“永久死锁”。真正的问题是：**流式数据源未传播中断信号，消费者也未设置兜底机制**。
确保数据源正确传播取消与错误
高效异步迭代器依赖底层可迭代对象的 [Symbol.asyncIterator] 实现能主动响应中断。关键检查点：
-
ReadableStream（如 fetch.response.body）：需显式监听
controller.signal或使用AbortController关联请求。未传 signal 时，连接断开可能只触发error事件，而迭代器不自动终止 -
Node.js Readable（v16+）：调用
stream.destroy(err)后，next()应尽快 reject；若仅stream.push(null)而未出错，迭代会正常结束，但不适用于中断场景 -
自定义 async generator（
async function*）：必须在内部try/catch中捕获底层 I/O 异常，并throw退出生成器（不能只return）
在消费端加超时与可中断等待
不能依赖数据源单方面保障，必须在 for await 外围设防：
- 用
Promise.race([iterator.next(), new Promise(...)]))包裹每次next()调用，设定合理超时（如 30 秒），超时后主动throw new Error('Stream timeout') - 配合
AbortController构建可取消的迭代器包装器：监听signal.aborted，一旦触发即调用iterator.return()（如果支持）或抛出中断错误 - 避免裸写
for await (const chunk of stream) { ... }；改用带状态管理的循环，例如：
let done = false;
while (!done) {
const { value, done: isDone } = await Promise.race([
iterator.next(),
timeout(15_000).then(() => { throw new Error('Chunk fetch timeout'); })
]);
done = isDone;
if (!done) process(value);
}
异常后清理与重试策略要明确
一次中断不应导致整个流程不可恢复：
- 在
catch块中，先调用iterator.return?.()（部分实现支持），再关闭关联资源（如response.body.cancel()、stream.destroy()） - 区分错误类型：网络超时/重置可指数退避重试；认证失败或 4xx 错误应立即终止并提示用户
- 若需断点续传（如大文件分块下载），在每次成功处理 chunk 后记录 offset 或 etag，在重试时通过 HTTP
Range或服务端游标参数恢复
验证是否真正“卡住”而非正常暂停
某些流行为易被误判为死锁：
-
ReadableStream.pause() 是合法背压机制，不是错误；检查是否有上游主动调用
pause()且未配对resume() -
空 chunk 或 null byte 不代表结束，需依据协议判断（如 SSE 的
event:、NDJSON 的换行符） - 用浏览器 DevTools 的 Network → Response Headers 查看
Content-Length和Transfer-Encoding: chunked，确认服务端确实在持续推送，而非已静默关闭连接
