Mac版VSCode中CodeGeeX性能优化指南
在 Mac 上使用 VSCode 开发时，CodeGeeX 的补全响应变慢、跟不上输入节奏，同时 CPU 占用率飙升？先别归咎于模型能力。实际诊断显示，瓶颈往往来自 VSCode 的运行状态以及插件之间的资源竞争。调整以下四个关键配置，即可让 CodeGeeX 恢复流畅的生成速度。
诊断 CodeGeeX 是否真正导致 VSCode 卡顿
操作前先进行性能检测。按下 Cmd+Shift+P，输入并运行 Developer: Open Process Explorer，展开 Extension Host 子项，找到 codegeex-vscode-extension 进程。检查它的 Memory (RSS) 是否持续超过 450MB，或 CPU 占用长期高于 60%。如果内存稳定在 200MB 以下且 CPU 波动平缓，那么卡顿的主因不在 CodeGeeX，而是其他扩展或配置在后台干扰。
尤其要注意，GitLens、ESLint、Prettier 等常用插件若同时启用，容易在编辑器空闲时与 CodeGeeX 争夺主线程资源，导致补全延迟。这并非 CodeGeeX 的缺陷，而是资源调度的冲突。
精简扩展加载，释放主线程资源
首先打开扩展面板（Cmd+Shift+X），在搜索框输入 @installed 查看已安装扩展数量。接着逐一将非必要扩展的齿轮图标点击，选择 Disable (Workspace)，重点处理以下三类：
- GitLens：关闭
gitlens.codeLens.enabled和gitlens.statusBar.enabled，内存占用可降低 35% 以上； - ESLint：将
"eslint.run"设置为"onType"，避免每次保存都触发全量校验； - Prettier：禁用
prettier.autoFormatOnSa ve，改用editor.formatOnSa ve并配合项目级.prettierrc控制格式。
修改后务必重启 VSCode 窗口（而非仅重载窗口），再通过 Process Explorer 确认 CodeGeeX 进程的 RSS 回落至 180–280MB 区间。
收紧文件监控，切断后台干扰源
CodeGeeX 的 InLine Chat 和潜行模式需要编辑器实时感知光标位置与上下文。若 VSCode 持续扫描 node_modules 或 .git 目录，会耗尽内核 inotify 句柄并阻塞主线程事件循环，导致 CodeGeeX 的“停顿→触发→生成”链路频繁中断。
解决方案是在当前项目根目录的 .vscode/settings.json 中添加如下配置：
"files.watcherExclude": {
"**/node_modules/**": true,
"**/.git/**": true,
"**/dist/**": true,
"**/build/**": true,
"**/coverage/**": true
}
切勿写入全局 settings.json——全局配置对 CodeGeeX 无效，仅项目级 .vscode/settings.json 可被正确识别与生效。
隔离工作区，防止语义索引污染
这里有两个实用技巧。首先，通过终端精准打开子目录：避免使用 code . 直接打开整个仓库根目录，而是进入具体开发模块后执行 cd packages/my-feature && code .。这样 VSCode 不会为 node_modules 之外的几十个无关包建立语言服务索引，CodeGeeX 的分析效率可提升 2 到 3 倍。
其次，启用工作区信任。首次打开新工作区时，VSCode 会弹出信任提示，务必选择 Trust Folder and Subfolders。否则 CodeGeeX 的 AI 请求会被拦截，InLine Chat 和提示模式均无法触发。
优化 CodeGeeX 自身生成策略
打开 VSCode 设置（Cmd+,），搜索 codegeex，调整以下三项参数：
① CodeGeeX: Candidate Count：默认 5，改为 3。减少候选数量可降低单次解码压力，在 M1/M2 Mac 上效果尤为显著；
② CodeGeeX: Generation Delay：从 800ms 调至 1200ms。延长静默窗口，避免快速输入时频繁触发补全；
③ CodeGeeX: Enable Inline Chat：确保为 启用。若关闭，⌘+I 快捷键将失效，InLine Chat 图标也会隐藏。