现代javascript引擎通过标记清除算法可正确回收循环引用，因其基于可达性分析而非引用计数；仅当循环结构嵌入全局缓存、未解绑事件监听器等持久化上下文中才可能漏收。
循环引用在 JavaScript 中曾是内存泄漏的常见原因，但现代主流垃圾回收器（如 V8 的 Orinoco、SpiderMonkey 的 Generational GC、JavaScriptCore 的 Mark-Sweep-Compact）早已能正确识别并回收绝大多数循环引用结构。所谓“击碎”，其实是自动识别不可达对象图后安全释放——不是靠暴力打断，而是靠精确的可达性分析。
一、构造一个典型的循环引用结构
用对象和闭包创建强引用环，避免被引擎静态优化掉：
- 两个对象互相持有对方的引用（
a.ref = b; b.ref = a） - 或函数闭包捕获外部对象，外部对象又引用该函数（
function makeCycle() { const obj = {}; const fn = () => obj; obj.fn = fn; return { obj, fn }; }） - 关键：确保整个结构脱离全局作用域（不赋值给
window或globalThis），且无其他外部引用
二、编写轻量验证小工具
不依赖 DevTools 手动操作，用代码触发 + 检测回收迹象：
- 用
WeakRef（ES2021）配合FinalizationRegistry注册回调，当目标被回收时触发日志 - 主动弃用引用（
obj = null; cycle = null），再调用gc()（仅 Node.js 启用--expose-gc时可用）或等待几次微任务 + 宏任务后检查registry - 示例核心片段：
const registry = new FinalizationRegistry((heldValue) => {
console.log(`✅ 已回收：${heldValue}`);
});
function createCycle() {
const a = { name: 'a' };
const b = { name: 'b' };
a.ref = b;
b.ref = a;
registry.register(a, 'object-a');
return { a, b };
}
const { a, b } = createCycle();
// 此时 a 和 b 构成循环引用，但仅被局部变量持有
a = b = null; // 切断外部引用
// 等待 GC（Node.js 中可 global.gc(); 浏览器需靠内存压力或定时轮询）
三、对比不同引擎的行为差异
主流引擎均基于标记-清除或标记-整理，但策略细节影响回收时机：
-
V8（Chrome/Node.js）：采用分代式 + 并发标记（Orinoco），小对象常驻新生代，循环引用在下一次 Scavenge 或老生代标记周期中被识别并回收；
FinalizationRegistry回调通常在 1–3 次 GC 后触发 -
SpiderMonkey（Firefox）：增量标记 + 周期性压缩，对闭包循环更敏感，回收延迟略低；支持
Components.utils.forceGC()（仅限 Firefox 内部调试） - JavaScriptCore（Safari）：多阶段标记 + 保守扫描，对某些 C++ 绑定对象的循环可能延迟回收，但纯 JS 循环引用与 V8 表现接近
四、哪些情况仍可能“漏网”？
真正难回收的不是循环引用本身，而是它嵌套在持久化上下文中：
- 全局 Map/Set 中存储了循环结构（
cache.set(key, { self: ... })），且 key 未被清理 - 事件监听器中闭包捕获 DOM 元素，DOM 元素又被该监听器函数反向引用（经典 IE6 问题，现代已修复，但自定义事件总线若未解绑仍会持续持有）
- Web Worker 中创建的循环结构未 postMessage 传递完即关闭 worker —— 主线程无法干预其内部 GC，需 worker 自行清理
