异步测试内存清理的关键是显式释放资源而非依赖gc，需在每个测试前手动触发gc、重置全局变量、清除定时器与事件监听器，并为异步资源设计destroy接口；用堆快照对比验证清理效果，避免测试代码自身引入泄漏。
异步测试中内存清理的关键，是确保测试结束后所有动态分配的资源被显式释放，而不是依赖垃圾回收器自动处理。因为测试运行快、生命周期短，GC 往往来不及触发，残留对象会累积，导致后续测试用例内存占用虚高、快照对比失真，甚至误判泄漏。
测试前手动触发 GC 并清空全局状态
在每个测试用例执行前，主动清理环境比等 GC 更可靠：
- 调用
global.gc()（仅 Node.js 启用--expose-gc时可用），或在浏览器测试中通过performance.memory辅助判断是否已回收 - 重置全局变量：如
window.cache = null、document.body.myData = undefined - 清除定时器：遍历保存的
setTimeout/setIntervalID 并clearTimeout/clearInterval - 移除事件监听器：若测试中绑定了
addEventListener，必须配对调用removeEventListener，尤其注意使用匿名函数时需保留引用
为异步资源设计可销毁接口
避免让测试代码直接操作底层资源，而是封装成带 destroy() 或 teardown() 方法的对象：
- 例如自定义一个防抖函数包装器，内部保存
timeoutId，暴露.cancel()方法 - 模拟的 WebSocket 或 EventSource 实例，在
afterEach中调用.close()并置空回调引用 - 使用
WeakMap缓存数据时，仍需在销毁阶段清空其 key 对应的强引用（WeakMap 本身不阻止回收，但 key 若还被其他地方持有，值就无法释放）
用堆快照验证清理效果
不能只靠“没报错”就认为清理完成，要实测验证：
- 在
beforeEach后拍一次快照（Baseline） - 执行异步操作并 await 完成
- 调用所有清理逻辑后，手动 GC，再拍快照（Cleanup）
- 用 Chrome DevTools Memory 面板的 Comparison 视图对比两者，筛选
(closure)、HTMLDivElement、EventListener等关键类型，确认数量未增长 - 重复运行同一测试多次，观察内存曲线是否平稳——阶梯式上升即说明有残留
避免测试代码自身引入泄漏
测试工具链本身也可能成为泄漏源：
- 不用
console.log打印大型对象（DevTools 会强引用它，阻碍回收） - Jest 中慎用
jest.useFakeTimers()后忘记jest.useRealTimers()，会导致 timer 模拟状态堆积 - 使用
vi.mock()（Vitest）或jest.mock()时，避免在 mock 实现中闭包捕获外部大对象 - 测试中创建的 DOM 节点，记得
container.remove()或document.body.innerHTML = ''
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
