code --status是vscode性能诊断第一入口，可直接读取extension host、cpptools-srv等子进程cpu%和pid，结合files.watcherexclude严格配置（如"/node_modules/": true）及inotify限制调优，快速定位并解决插件导致的cpu满载问题。
code --status 是第一真相入口，别等 UI 卡死再查
VSCode 插件引发 CPU 100%，往往不是界面卡顿，而是某个 Extension Host 在后台持续满载。此时 code --status 比任何 UI 操作都快、都准——它直接读取进程状态，不依赖渲染线程。
执行后重点关注这几类进程的 CPU%：
-
Extension Host：绝大多数插件运行在此，CPU 长期 >30% 就值得怀疑 -
cpptools-srv或pylance：C/C++ 或 Python 插件的语言服务器，常因路径配置不当反复重解析 -
Shared Process：遥测、同步、自动更新在后台轮询，telemetry.telemetryLevel设为"off"可快速验证
记下高占用进程的 PID，再用 ps -p [PID] -o comm=（macOS/Linux）或任务管理器“打开文件位置”（Windows）确认具体是哪个插件在跑。
files.watcherExclude 配错等于放任监听爆炸
VSCode 默认用 chokidar 监听整个工作区，一旦 node_modules、build、.git/objects 没被排除，成千上万个文件变更事件就会让 Node.js 子进程持续 100% 跑。
必须写进 .vscode/settings.json，且语法严格：
- 通配符必须是
**，写成*或*/node_modules/*无效 - 路径末尾加
/**才能递归排除子目录，"**/node_modules/**": true才对 - Linux/macOS 用户还要检查
/proc/sys/fs/inotify/max_user_watches，低于524288就得调高，否则 watcher 会静默失败并反复重试
常见漏掉的目录："**/.git/objects/**"、"**/tmp/**"、"**/bower_components/**"。
C/C++ 和 Python 插件的 includePath 是隐形 CPU 火药桶
cpptools 和 ms-python.python 的 includePath 配置不当，会导致 IntelliSense 解析器陷入死循环：不断尝试重新解析、找不到头文件、再重试……最终多个核心跑满。
典型错误包括：
- 滥用
**递归包含，比如"${workspaceFolder}/**/include"，实际扫描了整个磁盘 - 系统头文件路径（如
/usr/include）放在工作区路径之前，导致同名头文件被错误覆盖 - 没用
C/C++: Log Diagnostics命令验证生效路径，只靠猜测配置
正确做法是显式列出必要路径，顺序为：工作区路径 → 第三方库路径 → 系统路径，并避免通配符。
Remote-SSH 下 Samba 共享会触发 smbd 进程 CPU 爆表
如果你通过 Windows 网络映射或 macOS smb:// 挂载远程目录，再在本地 VSCode 中打开工程，smbd 进程就会成为瓶颈。C/C++ 插件频繁访问 SDK 中大量小文件时，Samba 的元数据解析会过载，smbd CPU 持续 100%，VSCode 却显示“正在索引”。
这不是插件问题，是协议层冲突：
- 关闭 VSCode 后
smbdCPU 立即回落，就能确认 - 改用
Remote-SSH扩展直连服务器，绕过 Samba，smbd完全不参与 - 配合
C_Cpp.workspaceParsingPriority设为"low"、C_Cpp.intelliSenseEngine切到"Tag Parser"，进一步压低负载
远程开发场景下，Samba 共享 + VSCode 本地编辑 = 隐形性能陷阱，这点容易被忽略，但影响最直接。
