GlobalState适合存小体积、结构简单、非敏感的用户偏好或临时状态，如最近文件路径、面板开关、主题色ID；不适合存日志、大对象、二进制内容或需事务/查询的数据。
GlobalState 适合存什么数据
globalState 是 VSCode 插件中跨会话持久化存储的轻量级方案，但不是数据库。它只适合存小体积、结构简单、非敏感的用户偏好或临时状态，比如最近打开的文件路径、折叠面板开关、上一次选中的主题色 ID。不适合存日志、大对象（如 AST 树）、二进制内容或需要事务/查询能力的数据。
它的底层是序列化为 JSON 存在本地文件中（路径类似 ~/.vscode/extensions/your-ext-1.0.0/globalStorage.json），所以值必须能被 JSON.stringify 安全处理——undefined、function、Date、Map、Set 都会被丢弃或转成空对象。
如何正确读写 globalState
必须等 context.globalState 初始化完成再使用，通常在 activate 回调里直接用即可；但若在异步链路中（如命令触发后延迟执行），需确保 context 仍有效——它不会自动失效，但插件被禁用时 globalState 就不可写了。
- 写入用
globalState.update(key, value)，返回 Promise，记得 await 或 catch 错误（比如磁盘满、权限不足） - 读取用
globalState.get(key)，第二个参数可设默认值，避免手动判undefined - 删除用
globalState.setKeysForSync([])不影响删除，真正删是globalState.update(key, undefined) - 键名建议加前缀，如
myExtension.lastSearchQuery，避免和其他插件冲突
sync 属性没起作用？别乱设 keysForSync
globalState.setKeysForSync(['keyA', 'keyB']) 看起来像开启云同步，但实际只对启用了 VSCode Settings Sync（且登录了 GitHub/MS 账户）的用户生效，并且仅限于标记的 key。多数插件根本不需要它——99% 的场景下，关掉这个更省心。
问题在于：一旦调用了 setKeysForSync，VSCode 就会在每次启动时尝试从云端拉取这些 key，如果 key 值结构变了（比如从 string 改成 object），而旧端数据还没清理，就可能触发解析失败静默丢弃，导致“存了但读不出来”。
- 除非你明确要支持多设备间用户偏好同步，否则不要调用
setKeysForSync - 如果已启用又想停用，得手动调用
setKeysForSync([])，再重启 VSCode 才彻底关闭同步逻辑 - 同步过程不报错也不提示，出问题只能靠对比
globalState.get()和预期值来排查
globalState 与 workspaceState 的关键区别
很多人混淆 globalState 和 workspaceState。前者属于插件+用户维度，同一插件下所有工作区共享；后者属于插件+工作区维度，不同文件夹（哪怕同一台机器）数据完全隔离。
比如你在项目 A 里存了 globalState.update('lastBranch', 'main')，切换到项目 B 后依然能读到 'main'；但用 workspaceState 存，项目 B 就是 undefined。
- 跨项目复用的状态（如“是否显示调试工具栏”）用
globalState - 跟当前代码库强相关的状态（如“当前 Git 分支缓存”“eslint 配置加载标志”）用
workspaceState - 两者 API 完全一致，别因为名字带 “global” 就以为它能跨用户或跨机器
最常被忽略的一点：globalState 的写入不是原子的——多个 update 并发调用时，后写的会覆盖先写的，尤其在快速连续触发的 UI 操作中（比如按钮连点）。真有并发风险，得自己加锁或节流，不能依赖它内置保障。
