开源 AI CRM Twenty 卡顿白屏一文搞懂内存泄漏排查3 张快照揪出元凶【免费下载链接】twentyThe open alternative to Salesforce, designed for AI.项目地址: https://gitcode.com/GitHub_Trending/tw/twenty用了三个小时Twenty 从丝滑变得像在搅蜂蜜最后整个标签页直接白屏。这种越用越卡的毛病九成是 Twenty 内存泄漏内存就像个水池一边持续进水排水口却被你堵死了。读完这篇你能用 Chrome DevTools 在半小时之内自己把那个元凶揪出来。先听身体报警5 个症状对照表泄漏不会弹窗自首但它会留下痕迹。你对照下面的清单中两条以上就可以怀疑了启动时飞快几小时后越来越慢。对象该释放却没释放越攒越多GC 干的活一次比一次重。刷新一下立刻恢复但过阵子又卡。内存是租来的不是还掉的重启只是清桌桌子本身还在变大。反复开合侧面板、列表页后明显变沉。每次操作都往内存里添了新对象旧的却走不了。触发 AI 对话后尤其明显。流式输出会不断追加内容没清理的部分就会一直滞留。浏览器进程内存曲线只涨不跌。在任务管理器盯着它持续爬升就是水池水位在涨。更直白地说卡顿是表象只进不出才是病根。DevTools 实战三步定位泄漏对象准备工作一句话带过git clone拿到 Twenty 源码https://gitcode.com/GitHub_Trending/tw/twenty按文档把前后端跑起来然后在浏览器里按 F12 打开 Chrome DevTools切到 Memory 面板。1. 拍第一张基准快照Memory 面板选Heap snapshot点记录。拍完之前把应用操作到正常使用中的状态比如打开联系人列表、点开侧面板。2. 重复操作拍第二张快照原样再做一遍刚才的动作再拍一张。选中最新快照用Comparison 视图对比两张按Size delta排序——涨得最凶的对象基本就是嫌疑人。3. 顺着 Retainers 找引用链点中可疑对象看右侧是谁还攥着它。引用链往往穿过 React 组件、闭包或全局 Map 回到业务代码对照模块路径就能判断泄漏落在哪一层。内存快照对比的关键就一条让两次快照之间只差你关心的那组操作。对号入座高频泄漏点自查三个高频坑按命中率从高到低排。每个给几行最小示例方便你直接往 Twenty 的目录里套。第一优先级监听器没解绑window.addEventListener(resize, onResize); // 组件卸载时记得成对调用 removeEventListenerTwenty 里重点翻 前端模块SSE 数据库事件、浏览器事件、工作流凡是 addEventListener 的组件卸载路径里必须有对应的移除。第二优先级定时器清不掉const timer setInterval(poll, 5000); // 返回的清理函数里要 clearInterval(timer)典型如 AI 模块 的聊天保活轮询和 SSE 的 liveness 检查组件销毁时忘了停回调就抱着整棵组件树不走。第三优先级无上限的缓存// Map 当缓存写入不限量从不淘汰 cache.set(key, result);元数据、查询结果这类存了就当永久的对象重点看 元数据存储服务端侧顺带瞄一眼 工作区缓存。把优化变成肌肉记忆做什么具体收益每次改动后跑拍快照→重复操作→再拍泄漏当天就死在本地不会流到用户手里用 Allocation sampling 录 30 秒代替反复截图直接看到最热的分配点省掉人工比对缓存一律带 TTL 或容量上限给对象一条过期通道GC 才有机会回收切走窗口时暂停 AI / SSE 的保活轮询后台空转的定时器直接归零排查的顺序别反先听症状再抓快照最后对号入座改代码。如果还卡在某一步去 官方文档 翻一遍或者直接钻进源码看引用链答案都在里面。【免费下载链接】twentyThe open alternative to Salesforce, designed for AI.项目地址: https://gitcode.com/GitHub_Trending/tw/twenty创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 开源 AI CRM Twenty 卡顿白屏？一文搞懂内存泄漏排查，3 张快照揪出元凶
开源 AI CRM Twenty 卡顿白屏一文搞懂内存泄漏排查3 张快照揪出元凶【免费下载链接】twentyThe open alternative to Salesforce, designed for AI.项目地址: https://gitcode.com/GitHub_Trending/tw/twenty用了三个小时Twenty 从丝滑变得像在搅蜂蜜最后整个标签页直接白屏。这种越用越卡的毛病九成是 Twenty 内存泄漏内存就像个水池一边持续进水排水口却被你堵死了。读完这篇你能用 Chrome DevTools 在半小时之内自己把那个元凶揪出来。先听身体报警5 个症状对照表泄漏不会弹窗自首但它会留下痕迹。你对照下面的清单中两条以上就可以怀疑了启动时飞快几小时后越来越慢。对象该释放却没释放越攒越多GC 干的活一次比一次重。刷新一下立刻恢复但过阵子又卡。内存是租来的不是还掉的重启只是清桌桌子本身还在变大。反复开合侧面板、列表页后明显变沉。每次操作都往内存里添了新对象旧的却走不了。触发 AI 对话后尤其明显。流式输出会不断追加内容没清理的部分就会一直滞留。浏览器进程内存曲线只涨不跌。在任务管理器盯着它持续爬升就是水池水位在涨。更直白地说卡顿是表象只进不出才是病根。DevTools 实战三步定位泄漏对象准备工作一句话带过git clone拿到 Twenty 源码https://gitcode.com/GitHub_Trending/tw/twenty按文档把前后端跑起来然后在浏览器里按 F12 打开 Chrome DevTools切到 Memory 面板。1. 拍第一张基准快照Memory 面板选Heap snapshot点记录。拍完之前把应用操作到正常使用中的状态比如打开联系人列表、点开侧面板。2. 重复操作拍第二张快照原样再做一遍刚才的动作再拍一张。选中最新快照用Comparison 视图对比两张按Size delta排序——涨得最凶的对象基本就是嫌疑人。3. 顺着 Retainers 找引用链点中可疑对象看右侧是谁还攥着它。引用链往往穿过 React 组件、闭包或全局 Map 回到业务代码对照模块路径就能判断泄漏落在哪一层。内存快照对比的关键就一条让两次快照之间只差你关心的那组操作。对号入座高频泄漏点自查三个高频坑按命中率从高到低排。每个给几行最小示例方便你直接往 Twenty 的目录里套。第一优先级监听器没解绑window.addEventListener(resize, onResize); // 组件卸载时记得成对调用 removeEventListenerTwenty 里重点翻 前端模块SSE 数据库事件、浏览器事件、工作流凡是 addEventListener 的组件卸载路径里必须有对应的移除。第二优先级定时器清不掉const timer setInterval(poll, 5000); // 返回的清理函数里要 clearInterval(timer)典型如 AI 模块 的聊天保活轮询和 SSE 的 liveness 检查组件销毁时忘了停回调就抱着整棵组件树不走。第三优先级无上限的缓存// Map 当缓存写入不限量从不淘汰 cache.set(key, result);元数据、查询结果这类存了就当永久的对象重点看 元数据存储服务端侧顺带瞄一眼 工作区缓存。把优化变成肌肉记忆做什么具体收益每次改动后跑拍快照→重复操作→再拍泄漏当天就死在本地不会流到用户手里用 Allocation sampling 录 30 秒代替反复截图直接看到最热的分配点省掉人工比对缓存一律带 TTL 或容量上限给对象一条过期通道GC 才有机会回收切走窗口时暂停 AI / SSE 的保活轮询后台空转的定时器直接归零排查的顺序别反先听症状再抓快照最后对号入座改代码。如果还卡在某一步去 官方文档 翻一遍或者直接钻进源码看引用链答案都在里面。【免费下载链接】twentyThe open alternative to Salesforce, designed for AI.项目地址: https://gitcode.com/GitHub_Trending/tw/twenty创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考