VSCode启动失败时，main.log和sharedprocess.log位于用户数据目录的logs//子目录下：Windows为%APPDATA%Codelogs\，macOS为~/Library/Application Support/Code/logs//，Linux为~/.config/Code/logs//。
启动失败时 main.log 和 sharedprocess.log 在哪找
VSCode 启动失败，第一手线索就藏在用户数据目录下的 logs 子目录里，不是临时弹窗或系统日志。三个核心日志文件必须按顺序查：main.log、sharedprocess.log、renderer.log，但后两者未必存在——renderer.log 只有窗口成功打开才会生成，如果连窗口都没出来，说明卡在更早阶段。
-
main.log：记录主进程初始化，比如扩展加载阻塞、配置解析失败、settings.json语法错误。路径为：
Windows：%APPDATA%Codelogs<timestamp>main.log</timestamp>
macOS：~/Library/Application Support/Code/logs/<timestamp>/main.log</timestamp>
Linux：~/.config/Code/logs/<timestamp>/main.log</timestamp> -
sharedprocess.log：反映沙箱启动、IPC 通信、文件监视器初始化等共享服务问题。同一目录下，和main.log时间戳一致 - 别在
logs目录里盲目翻最新文件夹——崩溃可能发生在某个旧时间戳的会话中，尤其当 VSCode 曾异常退出过
用 code --log trace 快速触发带时间戳的日志输出
手动翻日志容易漏掉关键上下文，最稳的方式是用命令行强制生成结构化日志流。它不依赖 GUI 是否弹出，只要进程启动了就会写。
- 先关闭所有 VSCode 实例（包括后台隐藏进程）
- 终端执行：
code --log trace --verbose（Windows PowerShell / macOS Terminal / Linux bash） - 若启动卡死，终端最后一行就是断点；若成功启动，日志会持续滚动，Ctrl+C 中断后，当前目录下会生成
vscode-debug.log，内容含主进程、扩展主机、渲染进程混合事件 -
--log trace比error或warn级别更能暴露初始化顺序问题，比如某个扩展在 workbench 尚未 ready 时就调用了vscode.workspaceAPI
为什么 renderer.log 缺失？说明问题比你想象的更底层
很多用户查不到 renderer.log 就以为“没日志”，其实这本身就是关键信号：VSCode 卡在 Electron 渲染进程创建之前，根本没走到 UI 层。
- 常见原因包括：
Failed to create GPU process（显卡驱动兼容性问题）、ENOENT: no such file or directory, open '/path/to/user-data-dir/globalStorage/'（用户数据目录权限异常，尤其 macOS 上）、或Checking for running code instance卡住（Linux 下$XDG_RUNTIME_DIR不可写或 dbus 未就绪） - 此时
main.log和sharedprocess.log往往也为空或只有一两行，因为主进程都未能完成初始化 - 验证是否 GPU 相关：加
--disable-gpu参数启动，能进界面就基本锁定问题域
别信“帮助 → 查看日志”菜单项
那个菜单项（Help → Toggle Developer Tools → View → Output → Logs）实际只打开开发者工具控制台，不是本地磁盘日志文件。它对插件运行时错误有用，但对启动失败完全无效——进程都没起来，哪来的开发者工具？
- 真正有效的入口只有两个：
code --log trace终端命令，和手动去~/.vscode/logs/（或对应平台路径）翻文件 - Windows 用户注意：
code命令需已加入 PATH，否则要用完整路径，例如：C:UsersXXXAppDataLocalProgramsMicrosoft VS CodeCode.exe --log trace --verbose - macOS 用户若提示
Failed to create CoreImage context，大概率是系统版本低于 12.0 或显卡驱动陈旧，main.log里通常不会明说，得结合系统信息交叉判断
