JavaScript无法真正触发死锁,因其单线程事件循环机制;所谓“Mock异步任务死锁超时异常”实为模拟异步长期不完成导致超时抛错,常用永不resolve/reject的Promise配合Promise.race或AbortSignal.timeout实现。

JavaScript 中无法真正触发“死锁”,因为单线程事件循环机制决定了它没有多线程意义上的资源抢占和互相等待。所谓“Mock 异步任务死锁超时异常”,实际是模拟一种异步操作长期不完成、导致调用方超时抛错的行为,常见于测试中验证超时逻辑(如 AbortSignal.timeout()、Promise.race([promise, timeout]) 等场景)。
用 Promise 永不 resolve/reject 来模拟“卡住”的异步任务
最直接的方式是返回一个既不兑现也不拒绝的 Promise。它不会报错,但会一直挂起,配合超时逻辑就能触发超时异常:
function mockStuckAsyncTask() {
return new Promise(() => {
// 不调用 resolve 或 reject → 永远 pending
});
}
// 使用示例:配合 Promise.race 实现超时
async function runWithTimeout() {
const task = mockStuckAsyncTask();
const timeout = new Promise((_, reject) =>
setTimeout(() => reject(new Error('Task timed out')), 1000)
);
return Promise.race([task, timeout]);
}
runWithTimeout().catch(err => console.error(err.message)); // 输出:Task timed out
用 setTimeout + 无 resolve 的 Promise 模拟延迟超时
如果需要更贴近真实“响应慢但最终可能成功”的场景(比如网络请求卡在 5 秒后才失败),可以控制 Promise 在超时之后才 reject,但不 resolve:
- 不调用
resolve→ 保证不会“意外完成” - 只在超时后调用
reject→ 触发你期望的超时错误 - 注意:不能同时 resolve 和 reject,否则 Promise 状态不可逆
function mockDelayedTimeout(ms = 2000) {
return new Promise((_, reject) => {
setTimeout(() => reject(new Error(`Operation timed out after ${ms}ms`)), ms);
});
}
在测试中结合 Jest 或 Vitest 模拟超时行为
使用测试框架时,推荐用 jest.fn() 或 vi.fn() 返回一个手动控制的 Promise,便于断言和清理:
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记(深入)”;
- Jest 示例:
const mockApiCall = jest.fn(() => mockDelayedTimeout(1500));
test('should throw timeout error when API is too slow', async () => {
await expect(mockApiCall()).rejects.toThrow('timed out');
});
- Vitest 示例(推荐用
vi.hoisted+vi.mock隔离依赖):
import { vi, it, expect } from 'vitest';
vi.mock('./api', () => ({
fetchUser: () => new Promise(() => {}) // 永不结束
}));
it('handles timeout gracefully', async () => {
const controller = new AbortController();
setTimeout(() => controller.abort(), 800);
await expect(fetchUser({ signal: controller.signal }))
.rejects.toThrow('AbortError');
});
避免误用:不要用 while(true) 或 long-running sync code
JavaScript 中写 while(true) 或超长同步计算(如百万次空循环)会阻塞整个事件循环,导致页面卡死、定时器不触发、无法响应任何异步逻辑——这不是“异步超时”,而是同步阻塞。它无法被 AbortController 中断,也无法被 Promise.race 捕获,属于反模式,测试中应严格避免。
不推荐:
// ❌ 危险!彻底冻结主线程
function badMock() {
while (true) {} // 页面直接无响应
}
不复杂但容易忽略:真正的“可测试超时异常”,核心在于让异步任务可控地不完成,而不是让它变慢或卡死。用永不 resolve 的 Promise 是最轻量、最可靠的方式。

















