VSCode启动失败时必须查看main.log、sharedprocess.log和renderer.log三类日志：main.log记录初始化失败，sharedprocess.log反映沙箱或IPC问题，renderer.log缺失说明卡在更早阶段；可通过code --log trace --verbose命令实时输出并定位断点。
VSCode 启动失败时，main.log、sharedprocess.log 和 renderer.log 是唯三必须看的日志文件；缺任何一个，都可能让你在错误方向上浪费一小时。
怎么看日志文件在哪？别手动翻目录
用户数据目录位置因系统而异，硬记路径容易出错。最稳的方式是用命令行直接打开：
-
code --log trace --verbose：强制最高级别日志，并实时输出到终端——启动卡死时，终端最后一行就是断点 - Windows 下若提示
'code' is not recognized，改用完整路径，例如：C:\Users\XXX\AppData\Local\Programs\Microsoft VS Code\Code.exe --log trace --verbose - macOS/Linux 若提示
command not found，先在 VSCode 中执行Shell Command: Install 'code' command in PATH
--log trace 会生成带时间戳的新日志，不覆盖旧记录，比 warn 或 error 级别更能暴露初始化顺序问题（比如某个扩展在 workbench.main.js 加载前就访问了未就绪的 API）。
main.log 里哪些线索真正有用？
main.log 记录主进程初始化阶段，重点不是堆栈本身，而是它出现的位置和上下文：
- 看到
Extension host terminated unexpectedly+ 大量ERR!行 → 某个扩展的activate()抛出未捕获异常；用code --disable-extensions验证，再逐个启用排查 - 反复出现
Failed to create GPU process→ Electron GPU 沙箱启动失败；加--disable-gpu或--disable-gpu-sandbox测试是否为显卡驱动兼容性问题 - 日志停在
Starting extension host with pid XXXX后无后续 → 扩展主机进程 fork 成功但立刻退出；检查~/.vscode/extensions/下是否有解压不全的.vsix包，删掉可疑目录再试 - 含
ENOENT: no such file or directory, open '/path/to/user-data-dir/globalStorage/'→ 用户数据目录权限异常，特别是 macOS 上，globalStorage文件夹可能被系统策略锁死
sharedprocess.log 缺失或报错意味着什么？
sharedprocess.log 在同一 logs/ 目录下，反映共享进程行为。它缺失或报错往往指向更底层的 IPC 或沙箱问题：
- 文件完全不存在 → 主进程甚至没走到启动共享进程那步，大概率是
main.log里已崩溃（比如配置解析失败、扩展阻塞初始化） - 日志里有
Failed to connect to shared process或IPC channel closed→ Chromium IPC 初始化失败，常见于企业环境策略限制或 Docker 容器未启用cap_sys_admin - 大量
Failed to watch+ 路径 → 文件监视器（chokidar）初始化崩溃，通常由杀毒软件拦截或磁盘挂载异常引起
注意：renderer.log 只有窗口成功打开后才生成；如果连这个都没有，说明卡在了比 sharedprocess 更早的阶段——比如 Electron 渲染进程创建失败，或 GPU 进程根本没起来。
code --status 和 code --log trace 怎么配合用？
code --status 是轻量级快照，code --log trace 是全量手术刀。两者配合才能准确定位：
- 先运行
code --status：观察输出末尾是否卡在某个扩展名、是否有Activating extension长时间无响应、或ERR! spawn ENOENT类错误 - 若
--status也卡住，说明问题在主进程早期（如配置加载、用户数据目录读取），此时必须上--log trace - 运行
code --log trace --status：日志直接打到终端，比 GUI 启动更干净；重点搜CRASHED、Cannot create window、EACCES、ENOENT - Linux 下若提示
Failed to move to new namespace，基本可锁定为容器权限问题，--no-sandbox是必要排查参数（但勿长期使用）
真正容易被忽略的是日志的时间顺序和进程标识——main.log 里的时间戳不是系统时间，而是进程启动后的相对毫秒数；同一操作在多个日志中可能跨进程出现，得靠 PID 和时间偏移对齐，否则你会把 A 进程的错误当成 B 进程的问题。
