尧图网页设计 
Twenty 内存泄漏排查完整指南用 Chrome DevTools 分配采样 10 分钟定位元凶【免费下载链接】twentyThe open alternative to Salesforce, designed for AI.项目地址: https://gitcode.com/GitHub_Trending/tw/twentyTwenty开源 CRMSalesforce 的开源替代方案前端是重交互的 React 应用视图、看板、工作流页面长期驻留用久了变卡、变慢多半和内存泄漏有关。本文带你用 Chrome DevTools 把 Twenty 内存泄漏查个水落石出——先用分配采样Allocation sampling圈出可疑代码再用堆快照对比拿到实锤最后给出一份可复用的排查清单。一、先认症状这 3 个信号才是 Twenty 内存泄漏的实锤排查前先确认问题真的存在别拿正常缓存当泄漏。信号 1同一页面反复操作后明显变慢。比如在工作流页面反复创建、触发流程第二遍开始掉帧、输入有延迟。信号 2刷新能续命。页面重载后立刻恢复流畅说明是内存累积而非 CPU 瓶颈——这是泄漏的经典前兆。信号 3任务管理器里 JS 堆只涨不跌。按 ShiftEsc 打开 Chrome 内置任务管理器盯着 twenty 标签页的内存列连续执行几次完整操作、再等垃圾回收GC跑完数值仍单调上涨就可以开查了。Twenty 的交互链路长packages/twenty-front/src/modules/ 下有数千个组件模块长会话累积效应比一般项目更明显这三个信号值得优先盯。二、排查前的环境准备跑起来 Twenty 再打开 DevTools 内存面板1. 本地把 Twenty 跑起来仓库是只读的先克隆地址https://gitcode.com/GitHub_Trending/tw/twenty确认 Node 24 和 Yarn 4 后执行yarn install yarn start # 同时拉起前端、后端和队列 worker浏览器访问本地应用并登录一个有数据的工作区。2. 打开 Memory 面板把操作序列固定下来按 F12 打开 DevTools切到 Memory 面板。开始前先做一件关键小事把复现序列写下来例如进入工作流页 → 新建工作流 → 触发一次 → 进出 5 条记录详情。序列越接近真实使用泄漏信号越强后续每一步检测都复用同一套序列结果才可对比。三、如何用分配采样Allocation sampling圈出可疑代码1. 开启分配采样并录制Memory 面板左上角下拉菜单选择Allocation sampling点录制按钮开始。完整执行一遍你写好的操作序列然后再等 30 秒左右让 GC 把该回收的对象回收掉——这一步很多人漏掉会导致大量正常对象混进结果。最后点停止。2. 读取采样结果结果默认按分配大小 调用栈聚合。两个视角配合看切到Timeline视图看整段过程中分配随时间的分布找操作结束后仍在持续出现的分配点回Allocation视图按 Size 排序看调用栈顶部反复出现的源码行。判断标准只有一条执行完操作、GC 之后仍然持续出现的分配才是嫌疑对象。选中一行Source 列直接给出文件和行号定位到具体代码。但要记住分配采样只回答哪里在分配不回答对象是否真的没被释放——后者靠下一步。四、内存快照对比的三个关键点1. 先 GC 再拍基线快照Memory 面板下拉改回Take heap snapshot先点一次 Collect garbage再拍第一张快照——这是干净的基线。2. 操作后拍第二张快照执行同一套操作序列拍第二张。DevTools 会生成对比视图Comparison对象被分成 New新增、Deleted已删、Moved 几类。只看 New 类和数量明显上涨的类Deleted 类直接略过。3. 按 Retained Size 排序追 Retainers 链在对比结果里按Retained Size排序找涨幅大的对象。点开它看Retainers是谁在引用它沿引用链一路回溯到源码文件。Retainers 就是凶手现场定时器回调window 上的监听器某个没退订的订阅一句话总结两者分工分配采样指方向快照对比抓证据Retainers 指认元凶。五、Twenty 前端最典型的泄漏模式定时器与监听器没清理Twenty 前端依赖 jotai 原子 大量长驻组件见 packages/twenty-front/src/modules/。快照里如果看到组件卸载后其旧实例仍被引用九成是这四类定时器、事件监听器、RxJS/订阅未退订、闭包引用。最典型的写法问题// 泄漏cleanup 忘了清定时器卸载后回调闭包仍引用着组件 useEffect(() { const t setInterval(poll, 5000); }, []); // 修复卸载时成对清理 useEffect(() { const t setInterval(poll, 5000); return () clearInterval(t); }, []);同类问题还包括window.addEventListener(keydown, handler)没有配对的removeEventListener、subscribe()返回的 subscription 未在组件卸载时unsubscribe。对照快照里 Retainers 指向的源文件和行号在源码中确认清理逻辑是否存在即可。六、排查清单把这 6 步固化成你自己的流程确认现象任务管理器中 JS 堆 GC 后不回落 → 继续否则停下分配采样用固定操作序列录一段Timeline 里找操作后仍在持续的分配快照对比先 GC 拍基线操作后拍第二张只看 New 类 Retained Size 涨幅追 Retainers沿引用链定位到源文件和行号过四类嫌疑定时器 / 事件监听 / 订阅 / 闭包引用逐个确认清理逻辑复测闭环修复后用同一套序列重跑一遍确认增长消失。顺手几条Twenty内存使用的优化建议给缓存设上限和过期策略Twenty 服务端本身有 packages/twenty-server/src/engine/workspace-cache/、packages/twenty-server/src/engine/core-entity-cache/ 这类缓存模块前端自定义缓存同理长驻页面优先用原子更新局部数据而不是反复重建大对象大文件导入导出这类重操作单独验证一轮把这套序列纳入发版前回归当作性能指标看。总结排查 Twenty 内存泄漏不需要神秘工具Chrome DevTools 两件套就够用分配采样指方向快照对比抓证据Retainers 链指认元凶修完再用同一序列复测闭环。按上面清单走一遍从发现变卡到定位元凶10 分钟到半小时足够。【免费下载链接】twentyThe open alternative to Salesforce, designed for AI.项目地址: https://gitcode.com/GitHub_Trending/tw/twenty创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Twenty 内存泄漏排查完整指南：用 Chrome DevTools 分配采样 10 分钟定位元凶
Twenty 内存泄漏排查完整指南用 Chrome DevTools 分配采样 10 分钟定位元凶【免费下载链接】twentyThe open alternative to Salesforce, designed for AI.项目地址: https://gitcode.com/GitHub_Trending/tw/twentyTwenty开源 CRMSalesforce 的开源替代方案前端是重交互的 React 应用视图、看板、工作流页面长期驻留用久了变卡、变慢多半和内存泄漏有关。本文带你用 Chrome DevTools 把 Twenty 内存泄漏查个水落石出——先用分配采样Allocation sampling圈出可疑代码再用堆快照对比拿到实锤最后给出一份可复用的排查清单。一、先认症状这 3 个信号才是 Twenty 内存泄漏的实锤排查前先确认问题真的存在别拿正常缓存当泄漏。信号 1同一页面反复操作后明显变慢。比如在工作流页面反复创建、触发流程第二遍开始掉帧、输入有延迟。信号 2刷新能续命。页面重载后立刻恢复流畅说明是内存累积而非 CPU 瓶颈——这是泄漏的经典前兆。信号 3任务管理器里 JS 堆只涨不跌。按 ShiftEsc 打开 Chrome 内置任务管理器盯着 twenty 标签页的内存列连续执行几次完整操作、再等垃圾回收GC跑完数值仍单调上涨就可以开查了。Twenty 的交互链路长packages/twenty-front/src/modules/ 下有数千个组件模块长会话累积效应比一般项目更明显这三个信号值得优先盯。二、排查前的环境准备跑起来 Twenty 再打开 DevTools 内存面板1. 本地把 Twenty 跑起来仓库是只读的先克隆地址https://gitcode.com/GitHub_Trending/tw/twenty确认 Node 24 和 Yarn 4 后执行yarn install yarn start # 同时拉起前端、后端和队列 worker浏览器访问本地应用并登录一个有数据的工作区。2. 打开 Memory 面板把操作序列固定下来按 F12 打开 DevTools切到 Memory 面板。开始前先做一件关键小事把复现序列写下来例如进入工作流页 → 新建工作流 → 触发一次 → 进出 5 条记录详情。序列越接近真实使用泄漏信号越强后续每一步检测都复用同一套序列结果才可对比。三、如何用分配采样Allocation sampling圈出可疑代码1. 开启分配采样并录制Memory 面板左上角下拉菜单选择Allocation sampling点录制按钮开始。完整执行一遍你写好的操作序列然后再等 30 秒左右让 GC 把该回收的对象回收掉——这一步很多人漏掉会导致大量正常对象混进结果。最后点停止。2. 读取采样结果结果默认按分配大小 调用栈聚合。两个视角配合看切到Timeline视图看整段过程中分配随时间的分布找操作结束后仍在持续出现的分配点回Allocation视图按 Size 排序看调用栈顶部反复出现的源码行。判断标准只有一条执行完操作、GC 之后仍然持续出现的分配才是嫌疑对象。选中一行Source 列直接给出文件和行号定位到具体代码。但要记住分配采样只回答哪里在分配不回答对象是否真的没被释放——后者靠下一步。四、内存快照对比的三个关键点1. 先 GC 再拍基线快照Memory 面板下拉改回Take heap snapshot先点一次 Collect garbage再拍第一张快照——这是干净的基线。2. 操作后拍第二张快照执行同一套操作序列拍第二张。DevTools 会生成对比视图Comparison对象被分成 New新增、Deleted已删、Moved 几类。只看 New 类和数量明显上涨的类Deleted 类直接略过。3. 按 Retained Size 排序追 Retainers 链在对比结果里按Retained Size排序找涨幅大的对象。点开它看Retainers是谁在引用它沿引用链一路回溯到源码文件。Retainers 就是凶手现场定时器回调window 上的监听器某个没退订的订阅一句话总结两者分工分配采样指方向快照对比抓证据Retainers 指认元凶。五、Twenty 前端最典型的泄漏模式定时器与监听器没清理Twenty 前端依赖 jotai 原子 大量长驻组件见 packages/twenty-front/src/modules/。快照里如果看到组件卸载后其旧实例仍被引用九成是这四类定时器、事件监听器、RxJS/订阅未退订、闭包引用。最典型的写法问题// 泄漏cleanup 忘了清定时器卸载后回调闭包仍引用着组件 useEffect(() { const t setInterval(poll, 5000); }, []); // 修复卸载时成对清理 useEffect(() { const t setInterval(poll, 5000); return () clearInterval(t); }, []);同类问题还包括window.addEventListener(keydown, handler)没有配对的removeEventListener、subscribe()返回的 subscription 未在组件卸载时unsubscribe。对照快照里 Retainers 指向的源文件和行号在源码中确认清理逻辑是否存在即可。六、排查清单把这 6 步固化成你自己的流程确认现象任务管理器中 JS 堆 GC 后不回落 → 继续否则停下分配采样用固定操作序列录一段Timeline 里找操作后仍在持续的分配快照对比先 GC 拍基线操作后拍第二张只看 New 类 Retained Size 涨幅追 Retainers沿引用链定位到源文件和行号过四类嫌疑定时器 / 事件监听 / 订阅 / 闭包引用逐个确认清理逻辑复测闭环修复后用同一套序列重跑一遍确认增长消失。顺手几条Twenty内存使用的优化建议给缓存设上限和过期策略Twenty 服务端本身有 packages/twenty-server/src/engine/workspace-cache/、packages/twenty-server/src/engine/core-entity-cache/ 这类缓存模块前端自定义缓存同理长驻页面优先用原子更新局部数据而不是反复重建大对象大文件导入导出这类重操作单独验证一轮把这套序列纳入发版前回归当作性能指标看。总结排查 Twenty 内存泄漏不需要神秘工具Chrome DevTools 两件套就够用分配采样指方向快照对比抓证据Retainers 链指认元凶修完再用同一序列复测闭环。按上面清单走一遍从发现变卡到定位元凶10 分钟到半小时足够。【免费下载链接】twentyThe open alternative to Salesforce, designed for AI.项目地址: https://gitcode.com/GitHub_Trending/tw/twenty创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考