上周三下午机器的风扇突然拉满我第一反应是哪个编译任务又跑飞了。切到活动监视器一看Cursor 已经稳稳吃满一个核心CPU 占用 100%而我只是开着三个文件在改样式。更难受的是 AI 对话框敲一个字要等半秒才回显Tab 补全弹不出来CtrlS 之后转圈转到怀疑人生。这种“编辑器本身没崩但交互全卡”的状态最折磨人因为它不像崩溃那样给你一个明确的错误弹窗你得自己去把它刨出来。这篇记录讲的就是我完整走完的一次排查最终把矛头指到了 bookmarks 这类书签导航插件身上——它在一个两千多条书签的工作区里持续做装饰重绘恰好和 AI 对话框的流式渲染抢同一个主线程。整个过程我没有靠肉眼猜而是让 Codex 这个命令行 AI 助手介入并统一走本地部署的 TaoToken 令牌网关来管理调用凭据把散落的排查动作固化成可以重复执行的脚本。如果你也是把 Cursor 当主力编辑器、装了三十多个扩展、又离不开 AI 对话框的那类人这篇里的路径大概率能直接复用。1. CPU 100% 的三种形态先分清再动手1.1 把“卡”变成可以读的数字“卡”是个主观感受排查的第一步是把它翻译成指标。我见过太多人一上来就卸载扩展卸了七八个发现没用最后发现是首次索引还没跑完。所以先做三件事看总占用、看分布、看时间形态。总占用分两种单核拉满一个核心 100%其他闲置和多核总和很高但每核都不满。前者通常是单线程重活比如大文件的语法解析、同步的文件扫描后者多半是并发的 I/O 或者多个进程同时在干活。这两种情况的凶手完全不是一类东西方向搞错就是白折腾。分布要看进程不是看应用。Cursor 底层是多进程架构任务管理器或活动监视器里一个“Cursor”图标下面藏着好几个进程。macOS 下我习惯用这条命令按 CPU 排序把进程树拉出来ps -Ao pid,ppid,%cpu,%mem,comm | sort -k3 -nr | head -20Windows 上用 PowerShell 等价物Get-Process | Sort-Object CPU -Descending | Select-Object -First 20 Name, Id, CPU, WorkingSet时间形态更关键。打开就高、几分钟后回落那是索引和预热正常。周期性尖峰比如每 5 秒跳一次那是定时任务或者文件监听器在空转。持续高位且随操作波动那才是真问题。我第一次采样是在打开工作区 90 秒后开始的那时候索引已经跑完CPU 依然稳在 95% 以上这就排除了预热期的干扰。提示采样窗口至少给到 30 秒。10 秒的采样很容易刚好错过一次周期性尖峰然后你得出了一个“CPU 不高”的错误结论。1.2 主进程、渲染进程和扩展宿主谁在背锅多进程架构里责任划分其实很清晰记住这张对应表能省掉一半时间。进程类型典型职责CPU 高的常见原因主进程main窗口管理、文件系统监听、原生菜单文件监听器风暴、大工作区递归扫描渲染进程renderer编辑器界面、DOM、装饰层绘制装饰器全量重算、超长行渲染、动画扩展宿主extensionHost所有第三方扩展的逻辑单个扩展死循环、同步 I/O、定时器共享进程shared搜索索引、扩展市场、更新搜索索引重建我当时的采样结果是扩展宿主稳定在 60% 上下渲染进程 25% 到 30% 之间来回跳主进程不到 5%。这个组合非常有指向性扩展宿主在持续消耗同时把渲染进程也拖着一起忙。如果纯是扩展宿主高而渲染进程安静那多半是某个扩展在自己循环里转渲染进程也跟着高说明这个扩展正在疯狂地改界面——改界面就要重绘重绘就在渲染进程里计费。分辨这两个进程不能靠任务管理器里的名字因为名字都叫 Cursor。我用的是 Cursor 自带的命令面板Developer: Open Process Explorer它会用一棵树把每个子进程的实际角色标出来同时显示实时 CPU 和内存。这个面板是排查这类问题的第一站比系统监视器信息密度高得多。2. 为什么这次我把排查交给了命令行 AI 助手2.1 编辑器已经卡了就别在编辑器里排查这里有个很现实的矛盾我要排查的是编辑器卡顿而我的排查工具本身就在这个卡顿的编辑器里。AI 对话框卡成那样一次提问要等十几秒改一行脚本要等补全效率低到离谱。所以我换了条路退出图形界面用终端里的 Codex 命令行助手来做这件事。它能读目录、能执行命令、能写脚本、能根据输出继续追问整个交互都在终端里完成完全不受编辑器卡顿影响。这一点在排错场景里价值极高——你的诊断工具不应该和被诊断的对象共用同一套资源。具体分工是这样的我负责观察和判断把我的观察用自然语言描述给它它负责把观察翻译成命令、跑出结果、解析输出、对比前后差异。比如我只说“扩展宿主 CPU 一直在 60% 附近抖帮我写一个 30 秒采样脚本每 2 秒记一次输出成 CSV”它会直接给我一个能跑的脚本而不是让我去查ps的参数手册。2.2 TaoToken 这一层解决的是凭据散落问题排查过程中我会反复让助手做不同的事模型调用次数不少。以前的做法是把密钥硬编码在环境变量里时间一长就出问题不同项目用不同供应商、密钥轮换要改一堆地方、某次不小心把.env提交上去了。这次我用 TaoToken 做统一入口。它是一个本地跑的小服务核心作用就三件集中保管各个供应商的凭据、按项目签发子令牌、记录每次调用的明细。助手侧只认一个本地地址和一个子令牌不需要知道背后到底连的是哪家。配置层面长这样写在家目录下的一个配置文件里权限设成 600# ~/.config/codex/env export CODEX_GATEWAY_URLhttp://127.0.0.1:8787/v1 export CODEX_GATEWAY_KEYproj-local-diag-7f3a然后在启动助手前source一下。子令牌是按项目隔离的proj-local-diag这个前缀对应的就是我这台机器的本地诊断用途即使泄露影响范围也只在这个项目配额内随时能吊销。我觉得这套东西真正的价值不在于“能用”而在于调用日志。排查到后半程我怀疑过一件事会不会是排查工具自己在吃资源翻了下网关的调用记录发现某段时间我平均每分钟发四五个请求每次都带着一整份采样输出确实占了一些 CPU。如果没有这层日志这个怀疑就只能停留在猜测。注意密钥和令牌永远不要写进会被 git 管理的文件。我用的是家目录下的独立配置文件仓库里只放一个.env.example里面全是占位符。2.3 把一次性排查变成可复跑的检查脚本手工排查最大的问题是不可复现。三天后再出问题你得把整套动作重来一遍而且大概率记不全。所以这次每验证一个猜想我都让助手把命令固化成一个脚本统一放在~/diagnostics/cursor/下面。最终攒出来四个sample.sh定时采样进程 CPU输出 CSVtop-ext.sh抓当前扩展宿主的 CPU 分布diff.sh对比两次采样算均值、峰值和长任务数量report.sh把上面三个的输出打包成一份 Markdown最后这个report.sh特别有用。我后来给插件作者提反馈的时候直接把生成的报告贴过去里面有复现步骤、有采样文件、有火焰图截取对方回得很快因为不需要再来回问“你能不能提供更多信息”。3. 用扩展二分法把 bookmarks 钉死在靶子上3.1 命令面板里的隐藏神器Running Extensions在动手禁用任何东西之前先看一个面板命令面板搜Developer: Show Running Extensions。它会列出所有已激活的扩展并且实时显示每个扩展的 CPU 占用和激活耗时。这个面板的价值在于它直接给你嫌疑名单。我打开的时候三十多个扩展里大部分都是 0%只有两三个有数字其中 bookmarks 那一行在 30% 到 60% 之间持续跳动而且它旁边显示的激活耗时也明显高于其他1.8 秒其他普遍在 100 毫秒以内。激活耗时高说明它启动时做了重活运行期 CPU 高说明它还在持续干活。两个信号叠在一起基本可以锁定。但“基本锁定”不等于“确认”因为面板显示的 CPU 是估算值有可能把别人的账算到它头上。所以还得往下走一步。3.2 扩展二分法六次重启换一个确定答案官方内置了Developer: Start Extension Bisect这是个自动化的二分流程。它会把扩展分成两半先禁用一半让你用一段时间问你“问题还在吗”根据回答再切一半。三十多个扩展大概六轮就能定位到唯一一个。这里有两个实操细节值得说。第一判断标准要提前定死。二分过程会反复问你“问题还在吗”如果你的判断标准是“感觉有点卡”那答案会非常不稳定最后结论也不可信。我定的标准是打开工作区后第 60 秒用sample.sh采 20 秒扩展宿主平均 CPU 超过 40% 就算“问题还在”。有了量化标准每次回答都是确定的。第二二分结束后一定要手动再验一次。二分工具最后会告诉你“疑似是某某扩展”但它只是基于你的回答做的推断。我在它给出结论后单独禁用 bookmarks 重启采样对比状态扩展宿主均值渲染进程均值AI 对话框输入延迟实测bookmarks 启用61%27%350–500msbookmarks 禁用7%6%40–60ms输入延迟这一栏是我用秒表粗测的方法很简单按住一个字母键不放看屏幕上字符出现的滞后感同时用手机的慢动作录像回放数帧。不精确但量级差异足够大350 毫秒和 50 毫秒是两种完全不同的体验。3.3 火焰图告诉我的事真正的热点不在输入框到这一步其实已经能“解决”问题了——禁用插件就完事。但我不甘心因为我想知道它到底在干什么万一换成别的插件又踩同一个坑呢。于是录了一段性能剖析。命令面板执行Developer: Start Recording GPU Profile或者用Developer: Toggle Developer Tools里的 Performance 面板录制 10 秒正常操作打开文件、滚动、在 AI 对话框里打字然后看火焰图。我原本的假设是AI 对话框的 DOM 太复杂流式输出时频繁重排导致卡。火焰图直接推翻了这个假设。主线程上最长的那条任务栈顶层是_updateDecorations往下是getVisibleRanges再往下是遍历一个两千多项的数组做区间判断。一次重算 38 毫秒。38 毫秒听起来不多但它是每次光标移动、每次滚动、每次内容变化都触发一次。我打字的速度大概是每 100 毫秒一个字符也就是说主线程有接近 40% 的时间被这件事占着。AI 对话框的流式输出需要在这 40% 的缝隙里挤进去更新 DOM挤不进去就表现为“字打出来了但没显示”。这个发现改变了我对问题的定性不是 AI 对话框本身有性能问题是它被一个高频的装饰重算挤到了队列后面。4. bookmarks 类插件怎么会把 AI 对话框拖下水4.1 书签高亮的实现原理决定了它的开销书签类插件要做的核心事情是在你标记过的行旁边显示一个标记可能是行号旁的图标、背景色、或者行尾的装饰。这在编辑器 API 里对应的是 Decoration装饰器。装饰器的机制是你注册一个 DecorationType然后告诉编辑器“把这一批区间用这个类型渲染”。问题在于装饰不是静态贴图它得跟着视口走——你滚动、你折叠代码、你增删行之前算好的区间就全变了。朴素实现的做法是每次变化都全量重算遍历所有书签判断哪些在当前视口内重新计算行号偏移然后重新 apply。两千条书签每次遍历加上区间判断38 毫秒就是这么来的。好的实现会做增量只重算受影响的区间或者用编辑器提供的onDidChangeTextDocument里的 delta 信息做局部更新。差的实现就是全量。而我用的这个版本从火焰图看显然是全量。4.2 文件监听器踩到的“回声”陷阱除了重绘还有一个更隐蔽的开销文件监听。书签数据一般存在工作区里的某个文件里插件监听这个文件的变化变了就重新加载。逻辑上没问题但如果“加载”这个动作本身会写回文件比如规范化格式、补全缺失字段、更新时间戳那就形成了循环写文件 → 触发监听 → 重新加载 → 又写文件 → 再触发监听。这个循环不会瞬间烧掉 CPU但会让扩展宿主一直保持在半活跃状态无法进入空闲。我用fs_usagemacOS观察了一段时间发现那个书签文件的写入频率是每秒 2 到 3 次而且内容几乎没变化——典型的回声。判断方法很简单找到插件的存储文件记下修改时间静置两分钟不动再看修改时间。如果它自己变了说明有东西在空转。4.3 主线程是共享的AI 面板没有特权这是整件事最值得记住的一点。编辑器的主线程是所有 UI 工作的公共通道渲染、输入响应、装饰绘制、Webview 更新全都在这一条线上排队。AI 对话框在 Cursor 里是个 Webview它的流式输出意味着每收到一小段文本就要更新一次 DOM。这个更新不是免费的它得进主线程的队列。当队列前面堵着一堆 38 毫秒的装饰重算时你的输入事件也被堵在后面。所以“AI 对话框卡顿”这个现象很多时候不是 AI 功能的锅。我做过一个对照实验把 AI 面板关掉只开编辑器光标移动依然有明显的粘滞感只是没有打字时那么刺眼。这说明底层问题一直在只是 AI 面板让它在感知上被放大了。反过来说如果你只优化 AI 面板比如换模型、减少上下文是治不好的。得从抢占主线程的那个源头下手。5. 四层递进的处置从配置收敛到长期守门5.1 第一层先把扫描范围和刷新频率摁住能不换插件就不换先看配置能不能救。我把这个插件的设置项翻了一遍找到了三个关键开关。第一个是扫描排除目录。默认它只排除了极少数目录node_modules、dist、.next、build这些统统没排。我的工作区里光node_modules底下就有几十万文件虽然真正被标书签的不多但扫描阶段的开销是实打实的。加上排除之后首次扫描时间从 12 秒降到 1.4 秒。{ bookmarks.scanExclude: [ **/node_modules/**, **/dist/**, **/build/**, **/.next/**, **/coverage/**, **/*.min.js, **/*.map ] }第二个是实时高亮开关。这个插件有个“实时高亮当前行所属书签区域”的选项默认开启。它在每次光标移动时都会触发一次装饰重算正是我在火焰图里看到的那个热点。关掉之后改成“仅在打开书签面板时高亮”光标移动的开销直接归零。第三个是注释标记扫描。这类插件通常有两种书签来源手动添加的和从代码注释比如// TODO、// BOOKMARK自动识别的。自动识别需要全文正则扫描而且文件一变就要重扫。我的工作区里有大量历史遗留的 TODO 注释加起来几千条全被当成书签处理了。关掉这个功能书签数量从两千多降到 187 条。这三项加起来扩展宿主 CPU 从 61% 降到 11%渲染进程从 27% 降到 8%。AI 对话框的输入延迟肉眼可见地恢复了。5.2 第二层用采样证明真的修好了而不是感觉好了改完配置不能靠“感觉快了”就收工得有数据。我跑了修前修后两组采样每组 60 秒每 2 秒一个点。#!/usr/bin/env bash # sample.sh —— 采样指定进程的 CPU输出 CSV set -euo pipefail PATTERN${1:-Cursor} DURATION${2:-60} INTERVAL${3:-2} OUTsample-$(date %Y%m%d-%H%M%S).csv echo timestamp,pid,comm,cpu $OUT END$(( $(date %s) DURATION )) while [ $(date %s) -lt $END ]; do ps -Ao pid,%cpu,comm \ | grep -i $PATTERN \ | grep -v grep \ | awk -v ts$(date %s) -F {print ts,$1,$3,$2} $OUT sleep $INTERVAL done echo written: $OUT跑完用diff.sh对比重点看三个数均值、95 分位、超过 50% 的采样点占比。均值容易被尖峰拉偏95 分位更能反映“大部分时间的体感”。指标修前修后扩展宿主均值61%11%扩展宿主 95 分位78%19%渲染进程均值27%8%CPU 超 50% 的采样点占比83%0%最后一栏是我最看重的。均值降下来但仍有零星尖峰说明还有偶发触发占比归零说明稳态问题解决了。5.3 第三层配置救不回来时的替代路线如果你的书签数量天然就很大比如维护一个跨多个仓库的知识库配置调优可能还是不够。这时候有三条路。换实现更克制的插件。判断标准不是看功能列表而是看它怎么描述自己的装饰策略。如果一个插件在说明里提到“增量更新”“懒加载”“仅在视口内计算”那通常说明作者想过性能问题。反过来功能列表里塞满了“实时”“自动同步”“全局扫描”这类词就要警惕。回归编辑器原生能力。很多书签需求其实可以用内置功能替代用搜索面板保存搜索、用任务列表管理待办、用文件级标记配合全局搜索。原生实现走的是同一条主线程但它的实现经过了大量优化不会出现每帧全量重算这种事。自己写一个最小实现。这是我在另一个项目里的做法只需要“在指定行加个标记、能跳转”这两个功能写了不到 150 行用编辑器的TextEditorDecorationType配合onDidChangeTextEditorSelection只算当前视口内的可见行。因为没有 UI 面板、没有自动扫描、没有文件监听CPU 开销在采样里看不出来。这条路的前提是你愿意维护它。如果只是个人用、需求稳定性价比很高如果要分享给别人就得考虑配置、迁移、兼容这些成本未必划算。5.4 第四层把守门脚本挂在后台别等下次再卡修好之后最容易发生的事是三个月后装了新插件、换了大工作区问题悄悄回来而你已经忘了当时是怎么查的。所以我把整套流程收成了一个守门脚本用系统的定时任务每周跑一次采样 60 秒只要扩展宿主均值超过 30% 就往日志里写一条记录同时把采样 CSV 归档。#!/usr/bin/env bash # guard.sh —— 每周检查一次超阈值留下证据 set -euo pipefail LOG$HOME/diagnostics/cursor/guard.log THRESHOLD30 ./sample.sh Cursor Helper 60 2 /dev/null LATEST$(ls -t sample-*.csv | head -1) AVG$(awk -F, NR1 $40 {sum$4; n} END {if(n0) printf %.1f, sum/n; else print 0} $LATEST) if awk -v a$AVG -v t$THRESHOLD BEGIN{exit !(at)}; then echo $(date %F %T) ALERT avg${AVG}% file${LATEST} $LOG else echo $(date %F %T) ok avg${AVG}% $LOG fi这个东西的价值不在于它能自动修复什么而在于它把“发现问题”的时间点提前了。等你自己感觉到卡的时候问题通常已经积累了一段时间。6. 复盘几个只有亲手做过才知道的细节第一个细节首次索引期千万别误判。新装插件、换工作区、清缓存之后都会有几分钟的高负载期。我的做法是在采样脚本里加一个前置检查如果进程启动时间不足 5 分钟直接跳过本次判定避免自己吓自己。第二个细节禁用扩展不等于扩展宿主重启。有些插件即使被禁用它注册的监听器和服务对象可能还挂在内存里得完全退出编辑器再打开才算干净。我第一次对比测试时就吃了这个亏禁用后 CPU 只降了一点点差点误判成“不是它”。后来改成彻底退出、重新启动数据才对上。第三个细节关掉 AI 面板再测一次是有必要的。因为这能区分两种完全不同的情况插件单独就能把 CPU 拉满还是插件 AI 面板叠加才出问题。前者说明插件本身有问题后者说明是资源竞争。处理方式不一样——前者要换插件后者只需要限制插件的开销。第四个细节报告要写给插件作者而不是写给自己的备忘录。我在提反馈的时候把复现步骤、采样 CSV、火焰图的关键帧、以及“关掉哪个选项后问题消失”这条信息一起给了。有一句特别好用的话是“这个开关打开时 CPU 61%关闭后 7%其他配置不变”这种对照信息对作者来说价值很高因为它直接把怀疑范围缩到了一个功能上。第五个细节排查工具本身也要计量。我在排查过程中频繁调用 AI 助手每次都把几十行采样输出贴进去。翻网关日志时发现有个十分钟窗口里我自己发了四十多次请求那段时间本机 CPU 也有明显抬升。这不影响结论因为量级差得远但提醒我一件事诊断行为会污染观测数据。后来我改成先离线分析、只在关键节点问一次数据干净了很多。最后说一个我自己的体会。这类“编辑器卡但没崩”的问题最怕的是靠感觉修。卸载扩展、重启、清缓存这套动作能碰运气解决一部分但你永远不知道是哪一步起的作用下次照旧。真正让排查变快的是把手感翻译成数字——哪怕只是用秒表量一下按键延迟用ps记一下 CPU 曲线也比“好像快了点”强得多。我现在的工作区里常驻着那个sample.sh遇到任何“最近有点慢”的抱怨先跑 60 秒再说多数时候答案就在那几个数字里。