vs code启动异常日志位于用户数据目录的logs子目录，windows为%appdata%\code\logs，macos为~/library/application support/code/logs，linux为~/.config/code/logs；每次启动失败会生成时间戳命名的子目录，含main.log等关键日志文件。
启动失败时日志在哪找
VSCode 启动异常（比如卡在黑屏、白屏、直接闪退）的日志不默认显示，但全在本地生成。关键路径是用户数据目录下的 logs 子目录，具体位置取决于系统：
- Windows：
%APPDATA%\Code\logs（即C:\Users\<username>\AppData\Roaming\Code\logs</username>） - macOS：
$HOME/Library/Application Support/Code/logs - Linux：
$HOME/.config/Code/logs
每次启动失败都会新建一个以时间戳命名的子目录（如 20240512T102345），里面包含 main.log（主进程）、renderer.log（渲染进程）、sharedprocess.log 等。优先看 main.log，它记录了 Electron 初始化、扩展加载、窗口创建等早期阶段的错误。
用 --log trace 启动获取更详细日志
默认日志级别太低，很多关键信息被过滤。必须加参数强制输出完整跟踪日志：
- Windows（CMD）：
code --log trace --user-data-dir="C:\temp\vscode-debug" - macOS（Terminal）：
code --log trace --user-data-dir="/tmp/vscode-debug" - Linux：
code --log trace --user-data-dir="/tmp/vscode-debug"
注意两点：一是 --log trace 必须放在命令最前面；二是强烈建议搭配 --user-data-dir 指定干净的临时目录，避免旧配置干扰——否则日志里混着历史扩展报错，很难定位本次问题。
常见日志错误线索怎么读
打开 main.log 后别通读，直接搜关键词：
-
ERR!或[error]：通常是致命错误，比如ERR! Failed to load extension后面跟着扩展 ID，说明某个扩展破坏了启动流程 -
ExtensionHost相关段落：如果日志卡在ExtensionHost: starting...之后没下文，大概率是某扩展的activate()函数抛异常或死循环 -
ENOENT/EACCES：文件不存在或权限拒绝，常见于插件试图读写受保护路径（如 macOS 的~/Library/Caches被沙盒拦截） -
Failed to create WebView：GPU 进程崩溃，可尝试加--disable-gpu验证
如果看到大量 Unable to resolve 'xxx' from 'yyy'，说明 TypeScript 或 JS 语言服务依赖解析失败，和 node_modules 路径或 tsconfig.json 配置有关，不是 VSCode 自身问题。
日志里看不到错误？试试从命令行启动并重定向
图形界面启动会吞掉部分 stderr 输出，而真正致命的 Electron 崩溃信息（如 segmentation fault、failed to initialize V8）只打到终端。直接在终端运行：
code --log trace --disable-extensions 2>&1 | tee vscode-startup.log
--disable-extensions 是关键开关——先排除扩展干扰；2>&1 | tee 把标准错误也捕获进文件。这样即使 VSCode 没弹窗，你也能在 vscode-startup.log 末尾看到类似 FATAL:memory_allocator.cc(234)] Out of memory 这种底层报错。
有些显卡驱动 bug 会导致日志里没提示，但加 --disable-gpu-sandbox 或 --no-sandbox（仅测试用）后能启动，这时问题就锁定在 GPU 沙盒机制上。
