能找回，取决于是否启用files.hotexit及崩溃前是否生成备份快照；需检查系统backups目录中时间戳匹配的哈希命名文件，用文本编辑器确认内容后另存。
蓝屏后 VSCode 未保存的代码文件是否能找回，取决于它在崩溃前是否已写入磁盘或进入 VSCode 的备份缓存。如果 files.autoSave 是 off（默认值），且你没按过 Ctrl+S，那内容只存在于内存中——蓝屏会清空内存，此时**VSCode 本身无法恢复**；但仍有两条可行路径：VSCode 的崩溃备份缓存（若 hotExit 生效）和操作系统级临时文件残留。
检查 VSCode Backups 目录是否存在有效缓存
VSCode 在异常退出前，若 files.hotExit 为 onExit 或 onExitAndWindowClose（默认），且进程未被强制杀掉（比如蓝屏时系统已写入部分缓存），它可能把未保存内容落盘到本地备份目录。这不是实时同步，而是约每 5 分钟一次快照，所以关键看蓝屏发生前最近一次快照是否已生成。
- Windows：
%APPDATA%\Code\Backups\ - macOS：
~/Library/Application Support/Code/Backups/ - Linux：
~/.config/Code/Backups/
进入对应路径，找时间戳最接近蓝屏时刻的子目录（名称是哈希串，但修改时间可见）；打开里面以 .tmp 或无扩展名结尾的文件，用文本编辑器查看是否含你的代码。注意：这些文件没有文件名和语言标识，需逐个确认。
确认是否启用了 files.autoSave 并检查实际保存行为
很多人以为开了 files.autoSave 就万无一失，但有三个常见断点：
-
files.autoSave设为onFocusChange时，如果你一直没切出编辑器（比如专注敲代码没点终端/侧边栏），它根本不会触发保存 -
files.autoSave设为afterDelay但files.autoSaveDelay过大（比如 5000ms），而蓝屏发生在你停顿不足 5 秒时，内容仍滞留在内存 - 某些语言服务（如 TypeScript Server）可能拦截保存事件，导致
autoSave日志显示“已保存”，但磁盘文件实际未更新（可用stat或Get-Item查看文件修改时间验证）
若你确定曾看到状态栏出现“已保存”提示，直接去原路径找文件；否则别假设它已落盘。
排查系统级临时文件与 Office 类自动恢复机制干扰
VSCode 不会把代码写进 Windows 的 UnsavedFiles 目录（那是 Office 专用），但蓝屏可能中断其他程序的自动保存流程，间接影响你对“是否真没保存”的判断：
- 如果你用的是 Remote-SSH / WSL，
Ctrl+S保存的是远端路径，蓝屏后远端服务若也崩溃，需登录服务器查~/.vscode-server/data/Backups/ - 某些插件（如
vscode-drawio）自带独立备份逻辑，其备份不走 VSCode 主目录，而在工作区的.vscode/drawio-backup/下 - 蓝屏后若立即重启，部分 SSD 的固件缓存可能尚未刷盘，旧版本文件内容仍残留在磁盘扇区——这时需用
photorec扫描原始设备，但成功率随后续写入量快速下降
真正容易被忽略的是：VSCode 的备份机制依赖于进程能执行“优雅退出”的一小段窗口期。蓝屏属于内核级崩溃，用户态进程通常来不及写缓存——所以不要依赖它，而应把 files.autoSave + git add -N（跟踪新文件）作为日常动作，让 Git 成为你真正的“最后防线”。
