main.log报错“Failed to load locale”表明CachedData缓存损坏，需删除整个CachedData文件夹后重启VSCode重建；若code --disable-extensions可启动但普通启动卡顿，也大概率是Cache或CachedData异常。
直接看 main.log 里有没有 locale 或 cache 相关报错
VSCode 启动或切换语言、加载扩展时，如果缓存损坏，main.log 是第一个暴露问题的地方。它不像控制台那样一闪而过，而是持续写入、保留完整上下文。
定位方式很简单：按 Ctrl+Shift+P → 输入 Developer: Open Logs Folder → 进入打开的目录，找最新日期的 main.log 文件。用 VSCode 自带编辑器打开后，搜索以下关键词：
-
Failed to load locale（说明CachedData里中文资源加载失败） -
ENOENT或ENOTDIR+ 路径含Cache/CachedData（文件被删一半或权限异常） -
Corrupted或invalid+storage.json（同步状态文件损坏） -
GPU cache initialization failed（GPUCache目录写坏，常伴随白屏/卡转圈）
注意：main.log 不会主动提示“缓存异常”，但它记录的每一条路径错误，基本都指向某个缓存子目录失效。没报错 ≠ 正常，但有上述任一报错，基本可以确认缓存已出问题。
code --disable-extensions 能启动，但 code 卡在转圈，大概率是 Cache 或 CachedData 损坏
这个对比测试是最轻量、最可靠的缓存健康度判断方式。因为 --disable-extensions 会跳过大部分扩展初始化逻辑，但依然要读取 Cache（HTTP 缓存）、CachedData（语法/语言服务元数据）和 GPUCache（渲染层），所以只要这些目录里有损坏文件，即使禁用扩展也会卡住。
- 如果
code --disable-extensions能进，但普通启动卡在“正在加载扩展”或“正在连接语言服务器”，优先清理%APPDATA%\Code\Cache和%APPDATA%\Code\CachedData - 如果连
--disable-extensions都卡在启动界面（比如只显示 VSCode 图标不出现窗口），问题更底层，大概率是GPUCache或%LOCALAPPDATA%\Programs\Microsoft VS Code\Cache出错 - 别依赖任务管理器里的进程是否存在来判断——
Code.exe进程可能活着，但主线程早已阻塞在某个缓存文件的read()系统调用上
检查 CachedData 目录下是否有空文件夹或零字节文件
%APPDATA%\Code\CachedData 下每个子目录对应一个 VSCode 版本号（如 a5b4061a72），里面应包含 language-configuration.json、tokenization.json 等非空文件。一旦升级失败或磁盘突然断电，就容易留下空目录或 0 字节文件。
手动检查方法：
- 打开该目录，按修改日期排序，重点看最新创建的子目录
- 进入该子目录，用命令行执行
dir /s /a-d（Windows）或find . -type f -size 0（macOS/Linux），查零字节文件 - 若发现整个子目录为空，或关键文件缺失（比如没有
extensions子目录），说明缓存重建失败，直接删掉整个子目录即可
VSCode 启动时会自动重建缺失的 CachedData，但不会覆盖已存在的损坏内容——它只会跳过，然后卡在后续依赖环节。
同步功能异常时，盯紧 sessions 和 sync 相关文件
当设置同步开启但插件列表不更新、主题回退、或者左下角用户图标反复弹出“登录失败”，问题往往不在云端，而在本地同步状态缓存里。
- 路径
%APPDATA%\Code\User\sessions存的是当前登录态的临时会话快照，如果其中某个.session文件损坏，VSCode 会不断重试同步并失败，但不报具体错误 - 路径
%APPDATA%\Code\User\sync（如果存在）或storage.json是同步元数据持久化位置，损坏后会导致“已启用的扩展”与云端不一致，且无法自动修复 - 不要只删
sessions里的部分文件——要么全清，要么整个目录删掉；删完后重启 VSCode，它会新建干净会话，再重新拉取云端配置
真正难排查的是：这些目录本身存在、文件非空，但内容结构错乱（比如 JSON 格式非法、字段类型错配）。这时候日志不一定报错，但行为一定异常——最稳的办法就是清掉，而不是修。
缓存是否异常，从来不是靠“看起来正常”来判断的。它藏在 main.log 的某一行路径错误里，卡在 code 命令的无声等待中，也埋在 CachedData 目录下那个 0 字节的 tokenization.json 里。动手前先看日志，动手时别碰 User 和 Extensions 主目录，清缓存不是格式化，是精准剔除已知腐坏节点。
