在开发自己的图片处理项目图片猫（PicCat，www.piccat.cn）时，我需要同时维护 AI 任务状态、图片对比交互和页面演示动画。这些功能都可能创建浏览器资源，但它们的生命周期并不相同。排查"离开页面后怎么还有请求"，我会先确认谁拥有轮询，再看清理是否覆盖了正在等待的异步请求。
本文结合当前 Vue 3 前端源码，梳理已经实现的资源回收，再给出一个适合组件局部资源的统一登记方案。统一清理器和串行轮询示例是建议方案，尚未接入项目业务代码。 读者可以把方法迁移到自己的页面，不需要依赖本文的演示项目。
1 先确认页面离开意味着什么
路由变了，不代表所有相关组件都卸载了。导航栏可能继续存在，模块顶层变量也不会随着某个页面消失。仅凭 Network 面板中还有请求，不能直接判定页面资源泄漏。反过来，页面已经不可见，也不意味着 window 上的监听器和计时器会自动移除。
我在当前仓库中核对到的几类资源如下。表中的"已实现"只描述源码行为，不代表已经完成浏览器回归测试。下文源码路径均相对 webClientVue。
|----------------------------------------------------------|----------------------|----------------|
| 资源与位置 | 当前已实现 | 需要区分的归属 |
| src/composables/useActiveAiEditTasks.ts | 模块共享计时器；暂停时使旧响应失效 | 共享任务列表，不属于单个页面 |
| src/components/Navbar.vue 与 src/views/AiEditChatView.vue | 导航栏启停共享轮询；聊天页暂停与恢复它 | 页面局部进度与共享状态协调 |
| src/components/common/BeforeAfterSlider.vue | 卸载时停止动画、移除拖拽监听并断开观察器 | 图片对比组件局部资源 |
| src/components/common/AiTextEditProcessDemo.vue | 清理演示延时、可见性监听和观察器 | 演示组件局部资源 |
图 1 依据源码关系整理的资源归属示意，非实际运行截图
AI 改图聊天页会在局部进度轮询启动时调用 suspendActiveAiEditTaskPolling；局部轮询停止时，按 wasActive 条件调用 resumeActiveAiEditTaskPolling。卸载钩子也会停止局部轮询。因此，离开聊天页后重新出现共享任务查询，可能正是这段交接逻辑的结果，需要先核对调用来源。
2 一个 interval 不等于只有一个请求
共享轮询把 pollTimer、requestId 和任务列表放在组合函数外部，因此多个调用方使用的是同一组状态。startPolling 在创建 interval 前检查句柄，避免重复建立周期调度；但它会先执行一次 refresh，再检查句柄。重复启动仍可能各自触发一次立即刷新。
项目代码摘录 · src/composables/useActiveAiEditTasks.ts · 省略鉴权、任务等待窗口和返回值等逻辑
const stopPolling = () => {
clearPollTimer();
waitForTaskUntil = 0;
};
const suspendPolling = () => {
if (scheduledPollingSuspended) return;
scheduledPollingSuspended = true;
requestId += 1;
clearPollTimer();
};
这里两个方法的语义不同。stopPolling 清除后续 interval，但没有递增 requestId，也没有中止已发出的请求；suspendPolling 还会递增请求版本，使暂停之前的响应无法通过版本校验。refresh 中也检查了登录状态与请求时的令牌是否一致，防止身份变化后的响应更新任务列表。
还要区分"丢弃旧响应"和"避免并发"。共享轮询用 requestId 保护结果提交，但 setInterval 不会等待异步 refresh 完成；这段组合函数本身没有 inFlight 互斥。聊天页的局部进度轮询则另有 inFlight 检查。不能把两段实现概括成同一种并发策略。
图 2 停止调度与阻止结果回写的异步时序示意，非抓包结果
对组件局部请求，我通常把停止分成三个动作：移除后续调度，尝试取消当前请求，在异步返回后检查是否仍允许提交结果。clearInterval 只覆盖第一个动作；AbortController 能帮助取消支持 signal 的请求，但不能代替结果有效性校验，也不等于取消服务端已经接受的 AI 任务。
3 用统一入口登记组件局部资源
项目已经在各组件中手动清理资源，但相关代码分散在不同函数和卸载钩子中。一个小型登记器可以让资源创建与释放逻辑放在一起，减少漏项。它只管理传入的清理函数，不决定共享轮询的业务归属。下面是本文建议的独立 TypeScript 实现，按登记与销毁两部分展示。
建议改进代码 · createCleanupScope 完整实现 上半段 · 两段按顺序拼接
type Cleanup = () => void;
export function createCleanupScope() {
let disposed = false;
const pending = new Set<Cleanup>();
const add = (cleanup: Cleanup): Cleanup => {
let active = true;
const release = () => {
if (!active) return;
active = false;
pending.delete(release);
try { cleanup(); }
catch (error) { console.error('资源清理失败', error); }
};
if (disposed) release();
else pending.add(release);
return release;
};
建议改进代码 · 接上半段 整体销毁与返回接口
const dispose = () => {
if (disposed) return;
disposed = true;
for (const release of ...pending.reverse()) release();
};
return { add, dispose };
}
add 返回一个可提前释放的函数。提前释放后，该记录会从集合移除；之后再次释放或整体 dispose 都不会重复执行。dispose 先设置终止标记，再倒序清理，方便先释放后建立的依赖。单个清理函数抛错时会记录错误，并继续处理其他资源；销毁后新登记的资源则立即释放。
这个实现只接收同步清理函数，不等待 Promise。异步关闭、失败重试和业务补偿应由调用方另行设计；清理失败后也不会自动重试。它也不会自动清空仍被外部变量引用的对象，资源引用是否释放仍需由具体回调负责。
把清理入口绑定到 Vue 作用域
建议改进代码 · Vue 包装函数 · 需与上面的工厂函数放在同一模块或补充导入
import { onScopeDispose } from 'vue';
export function useCleanupScope() {
const scope = createCleanupScope();
onScopeDispose(scope.dispose);
return scope;
}
在 setup 或组合函数的同步执行阶段调用这个包装函数，才能把回调登记到当前活跃作用域。组件卸载会停止对应作用域，进而执行清理；手动创建的 effectScope 则需要由创建者调用 stop。不要把包装函数放在 await 之后随意调用，也不要通过静默忽略警告来掩盖没有作用域的问题。
在创建资源的附近登记释放动作
教学简化片段 · 位于 script setup · 省略导入与 measure 实现，不能单独运行
const root = ref<HTMLElement | null>(null);
const cleanup = useCleanupScope();
onMounted(() => {
const handleResize = () => measure();
window.addEventListener('resize', handleResize);
cleanup.add(() => {
window.removeEventListener('resize', handleResize);
});
教学简化片段 · 接上段 登记尺寸观察器并结束 onMounted
if (root.value && typeof ResizeObserver !== 'undefined') {
const observer = new ResizeObserver(handleResize);
cleanup.add(() => observer.disconnect());
observer.observe(root.value);
}
});
浏览器资源放在 onMounted 中创建，可以避开服务端渲染阶段访问 window 的问题。移除事件监听时，事件类型、函数引用和 capture 必须匹配；重新写一个内容相同的箭头函数，仍然是另一个函数。options 对象本身不要求是同一个对象，passive 也不是移除匹配条件。
定时器可以用 cleanup.add(() => clearInterval(timer)) 登记，动画帧可以登记 cancelAnimationFrame。循环动画仍需额外的停止标记，避免已经进入的回调继续安排下一帧。拖拽监听结束时就应该提前释放，不必一直等到组件卸载。
4 让局部轮询在结束后再安排下一次
如果请求耗时可能超过轮询间隔，我更倾向于在请求完成后使用 setTimeout 安排下一次。这样同一个轮询实例不会因为固定节拍而堆叠请求；代价是两次请求的启动间隔包含请求耗时，并非严格每两秒发起一次。MDN 的 setInterval 文档也讨论了这种取舍。
下面的工厂每调用一次就立即启动一个局部轮询，并返回永久停止该实例的函数。load 必须返回完整异步读取过程的 Promise，包含响应体解析；调用方在 commit 中同步更新状态。代码分两段展示，按顺序拼接为一个完整函数。
建议改进代码 · startSerialPolling 完整实现 上半段 状态与请求入口
export function startSerialPolling<T>(
load: (signal: AbortSignal) => Promise<T>,
commit: (value: T) => void,
delay = 2000,
) {
let stopped = false;
let timer: ReturnType<typeof setTimeout> | undefined;
let controller: AbortController | undefined;
const tick = async () => {
if (stopped) return;
const current = new AbortController();
controller = current;
建议改进代码 · 接上半段 异步读取与停止逻辑
try {
const value = await load(current.signal);
if (!stopped && !current.signal.aborted) commit(value);
} catch (error) {
if (!stopped && !current.signal.aborted) {
console.error('轮询失败', error);
}
} finally {
if (controller === current) controller = undefined;
if (!stopped) timer = setTimeout(tick, delay);
}
};
const stop = () => {
if (stopped) return;
stopped = true;
clearTimeout(timer);
controller?.abort();
};
void tick();
return stop;
}
这里 stopped 是该实例不可逆的失效标记。即使 load 忽略 abort 信号，迟到结果也不能通过提交检查；finally 同样检查 stopped，防止停止之后又安排一个计时器。新一轮启用需要新建实例，不能把已经停止的实例当作可恢复对象。
教学简化片段 · 省略 loadTask 与 updateTask 的业务实现 · loadTask 必须把 signal 传入项目既有请求层，并确认底层支持取消
onMounted(() => {
const stop = startSerialPolling(loadTask, updateTask, 2000);
cleanup.add(stop);
});
示例没有加入任务终态判断、超时上限、退避重试和离线策略；接入任务接口时必须补齐。若 load 永不结束，串行轮询会停留在这次等待中，不能靠下一轮"自愈"。接入时应使用项目既有请求封装，并确认它能够把 signal 传递到底层。
这段代码只保证单个实例的串行执行。旧实例停止后，如果底层忽略取消，马上新建实例仍可能与旧请求在网络上短暂并存；旧实例的结果不会提交，但并发网络请求并没有凭空消失。需要全局互斥时，应在共享服务或请求层另外协调。
5 观察器的释放要覆盖兼容分支
项目中的 src/utils/elementResize.ts 提供了 createElementResizeObserver：支持 ResizeObserver 时使用原生实现；否则用窗口 resize、orientationchange 和 requestAnimationFrame 做回退。这个兼容分支的 disconnect 不仅清空被观察元素，也负责移除监听器和取消尚未执行的动画帧。
项目代码摘录 · src/utils/elementResize.ts · 回退对象的 disconnect 方法，其余方法省略
disconnect() {
observedElements.clear();
window.removeEventListener('resize', schedule);
window.removeEventListener('orientationchange', schedule);
if (animationFrame) window.cancelAnimationFrame(animationFrame);
animationFrame = 0;
}
因此，使用这个封装时，应登记 () => observer.disconnect()，保留方法调用的 this 上下文；仅 unobserve 某个元素不等于释放整个封装的监听资源。回退方案也有能力边界：它响应窗口尺寸与方向变化，无法完整感知原生 ResizeObserver 能捕获的所有元素尺寸变化，例如仅由内部内容变化引起的布局更新。
另一个实际案例是 AiTextEditProcessDemo.vue。它用 watch 管理演示延时，在播放状态、进入视口状态或页面可见性变化时先清除旧延时，再决定是否继续；卸载时清除延时、断开 IntersectionObserver，并移除 visibilitychange 和媒体查询 change 监听。这里的视口观察器和演示动画属于组件局部资源，适合按同一作用域集中回收。组件展示的是流程示意，不能把它当成模型实时执行效果。
要注意，Vue 会停止在 setup 中同步创建、绑定于组件的侦听器，但侦听器回调另外创建的浏览器资源仍需要清理。自动停止 watch，并不等于自动 clearTimeout 或 disconnect。
6 哪些情况不能只依赖卸载钩子
|---------------------|-----------------------------------------------------------------------------------|
| 场景 | 处理边界 |
| KeepAlive 缓存页面 | 失活不等于卸载。需要离页暂停的局部资源在 onDeactivated 释放，onActivated 重建；首次激活也会触发，避免与 onMounted 重复启动。 |
| 路由参数变化或 v-show 隐藏 | 实例可能复用或继续存在。按任务标识、可见状态切换资源；不要假定每次变化都会触发卸载。 |
| 多个组件共用模块资源 | 先约定唯一拥有者，或设计 acquire/release 与引用计数。任意消费者卸载就 stopAll，可能影响仍在使用的组件。 |
| 作用域已经 dispose 后再次激活 | 本文登记器是一次性的。新会话应新建登记器；直接复用会让新登记的资源立即被清理。 |
当前核对的 App.vue 路由视图没有使用 KeepAlive。上表中的缓存处理是迁移到其他项目或未来增加缓存时的建议，不是对本项目现状的描述。共享任务轮询目前有导航栏和聊天页的协调逻辑，本文也没有将它改造成引用计数服务。
7 已验证的范围与建议验收步骤
为核对本文示例，我对两个独立 TypeScript 工厂进行了 strict 类型检查，并用模拟计时器、可控 Promise 和 AbortController 执行隔离验证。已通过的行为包括：提前释放和重复销毁不重复执行、倒序清理、异常不中断后续清理、销毁后登记立即释放，以及轮询等待时不排程、停止时发送取消信号、忽略不响应取消的迟到结果、失败后继续安排下一次。
另对项目原始 useActiveAiEditTasks.ts 替换 Vue、鉴权和请求依赖后进行隔离验证，确认重复启动只保留一个 interval，但会发起两次立即刷新；暂停后，之前的响应不再更新任务列表。合计 10 项断言通过。这些验证未连接真实服务，未覆盖浏览器页面切换、缓存激活、布局行为或请求层对 signal 的真实传递，也没有据此声称性能提升。
接入实际页面后，我建议按下面的顺序验收。以下是建议清单，尚未完成浏览器实测。
-
打开页面，记录请求发起来源与资源拥有者；区分共享任务查询和页面局部进度查询。
-
在请求未返回时离开页面，再让响应返回，确认没有旧状态回写，也没有从 finally 重新启动局部轮询。
-
连续进入和离开页面，检查监听器、观察器、计时器及动画帧是否持续累积；仅比较请求总数不足以判断泄漏。
-
单独验证共享任务的后台观察仍符合业务预期，并验证退出登录、切换任务、网络失败和慢请求场景。
-
若引入 KeepAlive，再检查首次激活、反复激活和最终卸载，确保每次最多存在一个有效局部实例。
对我来说，这次源码梳理最有价值的结论，是把资源生命周期写成可核对的约定：谁创建，谁负责释放；谁允许跨页存在，谁负责解释继续运行的原因。先把这些边界确认清楚，再统一清理入口，才能同时避免资源残留和误停共享任务。
参考资料
Vue 官方文档 · onScopeDispose 与作用域清理
Vue 官方文档 · KeepAlive 缓存实例的生命周期
MDN · removeEventListener 的匹配规则