最可靠方式是用code --log=trace启动：macos/linux执行code --log=trace /path/to/project，windows powershell运行code --log=debug c:\myproject，日志存于对应系统logs目录，含main.log（主进程）、extensionhost.log（扩展宿主）和renderer.log（渲染进程）。
怎么生成 VSCode 主进程和扩展宿主的详细性能日志
直接用 code --log=trace 启动 VSCode 是最可靠的方式，它会强制写入完整事件流（包括 IPC 消息、模块加载耗时、渲染帧时间戳），而不是依赖 UI 里点几下就完事。
- macOS/Linux：终端执行
code --log=trace /path/to/your/project - Windows（PowerShell）：运行
code --log=debug C:\myproject（debug级别已足够定位多数卡顿，trace会产生大量日志，慎用） - 日志默认存放在：
%APPDATA%\Code\logs\（Win）、$HOME/Library/Application Support/Code/logs/（macOS）、$HOME/.config/Code/logs/（Linux） - 重点关注
main.log（主进程启动与窗口管理）、extensionHost.log（所有扩展的加载与通信）、renderer.log（UI 渲染线程异常）
为什么 extensionHost.log 里看不到你刚装的插件日志
不是所有扩展都会主动写日志——尤其那些没调用 vscode.window.showInformationMessage() 或没启用 console.log 的轻量插件，根本不会产生日志行。更常见的是：插件日志被过滤或重定向了。
- 检查插件是否支持配置日志级别，例如 Python 扩展需在
settings.json中显式设置"python.logging.level": "verbose" - 某些插件（如 ESLint）只在“Output”面板的对应通道输出，不在
extensionHost.log里；打开命令面板，输入Developer: Toggle Developer Tools，再切到 Console 标签页，才能看到它们抛出的未捕获错误 -
extensionHost.log默认只记录扩展生命周期事件（activate、deactivate）和崩溃堆栈，不包含业务逻辑日志，除非插件自己调用了vscode.extensions.getExtension(...).activate()后主动打点
如何从 main.log 里快速定位卡顿根源
别通读，直接搜关键词。VSCode 主进程日志里，卡顿几乎都表现为某段操作耗时异常，而不是报错。
- 搜索
WARN+slow：会出现类似[main 2026-07-22T15:42:18.123] [warn] Slow operation detected: fs.readdir (took 2345ms)这种明确提示 - 搜索
ERR!（注意带感叹号）：这是 VSCode 内部错误标记，比如ERR! Unable to load extension 'ms-python.python'，说明扩展加载失败并可能拖慢后续流程 - 搜索
Starting...和Finished...成对出现的耗时项：例如Starting extension host→Finished extension host之间间隔超过 3s，基本可判定是某个扩展初始化过重 - 留意时间戳跳跃：如果两行日志时间差 >500ms 且中间无其他输出，大概率是某次同步阻塞操作（如读大文件、正则爆炸）卡住了主线程
用 Process Explorer 配合日志分析时容易忽略的细节
Process Explorer 是实时视图，但它的数据来源和日志不完全同步——它显示的是当前内存/CPU 占用，而日志记录的是过去发生的事件。两者必须交叉验证才有效。
- 在 Process Explorer 中发现
extensionHost进程 CPU 占用 90%，但extensionHost.log里没有对应时间段的 ERROR 日志？大概率是插件在做纯计算（比如 LSP 语义分析），没抛异常，但也没打日志 - Renderer 进程内存持续上涨，但
renderer.log安静如鸡？这时候要打开 DevTools（Developer: Toggle Developer Tools），切到 Memory 面板拍快照，查 DOM 节点泄漏或未销毁的事件监听器 - 不要只看“CPU%”，更要盯住“Working Set”（内存占用）列：一个扩展长期占 800MB 内存，比它偶尔飙 CPU 更危险，但日志里往往只记一句
extension activated，毫无预警
slow 提示 + Process Explorer 里一个高内存扩展 + DevTools 里一堆重复创建的 Webview 实例共同作用的结果。盯着一个地方看，很容易漏掉真正拖垮编辑器的那条线。
