官方功能教程 / 使用技巧｜让 AI 功能更好用

内存占用高？TRAE 研发工程师 5 个方法教你解决

你日常是否会被这一些问题所困扰：

• 刚打开 IDE，感觉风扇就开始转
• 项目一大，编辑器变卡
• 开了几个窗口、几个插件后，电脑开始吃力
• 终端跑着构建或服务时，整个 IDE 有点卡顿
• 看到“内存占用很高”，但不知道到底高在哪、该怎么处理

我们真正应该弄清楚的是究竟是什么在占内存。是窗口？插件？终端任务？还是其他的呢？

在解决内存问题之前，我们先来理解内存的概念。

理解内存的概念

你可以把内存理解成电脑的 临时工作台。

你开的应用越多、处理的内容越复杂、后台同时跑的任务越多，这张“工作台”就会摆上越多东西。工作台大，应用切换和处理就更顺；工作台紧张，系统就会想办法腾地方，严重时就会变卡，甚至直接提示内存不足。

我们常说的内存一般指的是物理内存，像个人电脑的内存有 16G、32G 等。但操作系统为了更好地利用物理内存，让设备合理使用内存空间，对内存有更全面的定义。

不同系统的内存概念

Windows 和 MacOS 对内存的定义不是完全一致，大家可以根据自己的电脑系统针对性了解。

Windows 系统

在 Windows 里，常见的一个概念叫 工作集（Working Set）。你可以把它理解成：这个进程当前实际留在物理内存里的那部分内容。

它通常包含两部分：

• 私有工作集：只属于当前进程，不包含共享部分。活动监视器主页默认展示的内存这一栏，就是私有工作集。

• 共享工作集：包含共享的内存，比如共用的 DLL、共享内存等。

你只需要理解：

• 私有部分越大，越能代表这个进程自己“真的吃了多少内存”
• 共享部分不一定全是它独占的，所以看到大数字先别慌

macOS 系统

打开你 Mac 设备自带的「活动监视器」，可以看到对内存有很多概念，我们先带大家了解：

内存

在 MacOS 里，这个数据代表当前进程真正占用的物理内存，包含私有内存、压缩内存以及部分共享内存。

你可以把它理解成一个更接近实际体感的指标。TRAE 资源管理器里展示的进程级内存占用，也更接近这个口径。

实际内存

去除压缩部分的私有内存和共享内存部分，通常比「内存」小一些。

专用内存

私有的物理内存，不包含压缩或者交换（swap）到磁盘的部分。Mac 为了提高内存利用率，内存会和磁盘频繁交换，因此有了 swap 的概念。所以，磁盘余量太小，不够交换，也是导致进程 OOM 的一个原因。

共享内存

多个进程中共享的部分，比如多个进程都加载了同一个三方依赖，这部分会算到共享内存中。

VM 被压缩

Mac 有自己的内存压缩算法，当物理内存压力大时，会通过压缩的方式降低对物理内存的占用。活动监视器中展示的 VM 被压缩，是「压缩之前」的内存大小。

所以看到压缩内存，并不等于立刻有问题。真正要警惕的是：「压缩越来越多，同时磁盘剩余空间也很少」

TRAE 的内存主要分布

这里以 Mac 为例。

用户窗口：内存占用“大头”

这是你最直观接触到的部分，也就是编辑器窗口本身。

它通常负责：

• 展示代码和界面
• 打开文件、搜索内容、渲染标签页
• 维护你当前窗口里的很多交互状态

用户窗口代表当前代码编辑器的核心区域，通常占用内存最高。项目文件越多、代码文件内容越复杂，占用的内存越高，空窗口通常为 200MB 左右。如果经常使用 AI，AI Utility、AI Completion 的占用也会较高，约 300M 上下。

什么情况下它会明显“变大”？

• 打开的项目很大
• 同时打开很多文件
• 文件本身内容复杂，尤其是超长文件、超大 JSON、生成产物、日志文件
• 同时开了多个窗口

典型表现

• 输入延迟
• 搜索、跳转、滚动变得卡顿
• 风扇持续在转

如何优化

• 少开不必要的窗口：窗口越多，很多基础资源会跟着线性增加。
• 不要长期打开超大文件：例如构建产物、打包文件、超长日志。
• 尽量避免把超大的非源码目录一起纳入工作区。
• 卡顿时先观察是不是当前窗口本身占用很高，而不是先怀疑电脑配置不够。

社区插件：最常见的内存消耗来源

很多人的第一反应是“IDE 本身”，但实际排查下来，插件 往往才是高占用的重要来源。

插件的问题在于，它不一定一直稳定消耗资源。有些插件平时看着没事，但在下面这些场景会突然放大问题：

• 大仓库
• 文件频繁变动
• 持续保存、格式化、扫描
• 项目里文件数量非常多
• 插件之间相互叠加

插件越多，不一定越强

插件不只是“加一个按钮”这么简单。它可能会：

• 扫描项目
• 建索引
• 拉起额外进程
• 持续监听文件变化
• 频繁和编辑器主流程通信

典型表现

• 你明明没做复杂操作，CPU 和内存却一直占用很高
• 只要一打开某个项目就卡，换了一个项目反而正常
• 禁用某个插件后，体验明显改善一大截
• 插件宿主内存异常高

如何优化

• 只保留高频、刚需插件。低频插件宁愿用的时候再开。
• 定期清理“装了但几乎没用”的插件。
• 遇到卡顿先做一次二分排查：分批禁用插件，看问题是否消失。
• 重点关注大仓场景下的扫描类、格式化类、语言服务类插件。
• 如果发现某个插件版本明显更差，可以考虑降级或暂时禁用。

某些插件可能没有独立的进程，会融合在插件宿主中。当看到插件宿主内存很高时，通常是这个原因导致的。在 Trae 中，可以通过对插件进行堆快照的采集，来定位具体的插件。在 Mac 上执行 Cmd + Shift + P，在 Windows 上执行 Ctrl + Shift + P，然后输入 Run HeapSnapshot 搜索 Extension Host，对插件进程进行「内存快照」，导入 Chrome Devtool 进行定位。

我们整理了一些容易触发性能问题的插件，大家可以自行选择卸载或禁用。

插件 ID	问题现象	建议
steoates.autoimport	大仓库代码变动时 CPU 占用飙升，导致卡死	卸载
IWANABETHATGUY.path-alias	占用大量 CPU 和内存	卸载
r3inbowari.gomodexplorer	创建大量 go list 进程，占用 CPU/内存	卸载
vscjava.vscode-java-upgrade	产生大量 rg 进程	卸载
pranaygp.vscode-css-peek	创建大量进程	卸载
plantunicorn.tetrishelper	占用大量内存	卸载
codex	运行中偶现占用大量内存	暂时禁用等待官方优化，或卸载
esbenp.prettier-vscode	12.x（代码删除/跳转卡顿）	降级到 11.x
ChakrounAnas.turbo-console-log	v3.16.0（大仓内存飙升）	降级到 v3.15.0

用户终端：很多 内存溢出 的真正来源

这是最容易被误会的一类。

很多用户看到 TRAE 主进程下面挂了很多子进程，就会直觉认为“IDE 把内存吃光了”。但实际情况常常是：不是 IDE 本体吃掉了这些内存，而是你在 IDE 终端里运行的命令，把这些资源带起来了。

比如这些常见操作：

• 本地启动多个服务
• 跑前端/后端构建
• 执行打包命令
• 跑测试
• 跑容器、脚本、数据处理任务

这些任务本来就较重，而且很多还是持续运行。一旦都挂在 IDE 的终端里，整个 IDE 的资源观感就会一起变重。

典型表现

• 终端一跑任务，IDE 就开始卡
• 停掉命令后，明显恢复
• 项目本身不大，但机器依然很喘
• OOM / Crash 经常发生在构建、编译、跑服务期间

如何优化

• 把长期驻留、特别吃资源的命令，尽量放到系统终端里跑。例如 macOS 的 Terminal、Windows 的 PowerShell。
• 不要在同一个 IDE 窗口里长期挂太多服务。
• 构建、测试、打包类任务结束后及时清理无用进程。
• 如果你只是想看代码，不一定要把所有本地服务都一起跑起来。

IDE 基础服务和 AI 能力：必要开销，但也会受使用方式影响

除了窗口、插件、终端，TRAE IDE 还会有一些基础服务和 AI 相关能力在后台运行，比如：文件监听、网络服务、GPU 渲染、AI Agent、代码补全、代码索引等。

这些能力存在的意义，是为了让体验更智能、更完整。但它们确实会带来一定资源消耗，尤其在下面这些场景：

• 高频使用 AI 问答和补全
• 工程规模很大，需要持续索引
• 文件变化很频繁
• 同时开多个窗口并都在活跃使用

你可以简单把它理解成“体验成本”。如果你希望 IDE 能更聪明、更快、更懂上下文，那它背后就需要额外的进程和资源来支持。关键不在于完全没有消耗，而在于：

• 消耗是否稳定
• 是否和你的使用行为相匹配
• 是否已经明显影响了体验

如果 AI 功能开着，但你几乎不用，或者你打开了很多窗口却并不活跃，那就会放大这部分“无效占用”。

5步排查法

如果你现在就觉得 TRAE 有点卡，或者内存数字看起来过高，可以直接按我们的【5步排查法】依次排查。

第一步：查看终端任务

这是最常见、也最容易定位的原因。

先问自己：

• 我是不是在跑构建？
• 我是不是挂着多个服务？
• 我是不是在 IDE 里跑了测试、打包、容器？

如果是，先停掉一部分，再观察是否恢复。

第二步：查看安装的插件

如果停掉终端任务后还是卡，优先怀疑插件。最省时间的方法不是一个个猜，而是：

• 先禁用最近新装的插件
• 再禁用低频插件
• 再观察是否恢复

第三步：查看打开的窗口

很多用户习惯同时开多个项目窗口，但每个窗口都不是“零成本”的。如果你同时打开多个大型工程，哪怕每个窗口都不算特别夸张，叠加起来也会把机器拖慢。

第四步：查看打开的文件

例如：

• 超大日志
• 构建产物
• 超大 JSON

这些内容会显著放大编辑器窗口本身的压力。

第五步：检查磁盘剩余空间

大家也可以保持检查自己的系统磁盘空间的习惯，如果本身磁盘的剩余空间已经很少，也可以先优先清理。这一步经常被忽略，但很有效。

相信阅读完这篇文章，你已经成了内存占用排查专家，遇见内存问题再也不用担心啦！

更多知识可以进入 TRAE 官方社区阅读。