activate 函数在 activationevents 显式触发时调用，如 oncommand 或 onstartupfinished；deactivate 用于清理资源但非必选，需显式释放监听器；memento 数据持久存在。
activate 函数什么时候被调用？
它不是插件一安装就运行，而是由 activationEvents 显式触发的。比如你在 package.json 里写了 "onCommand:my-extension.doSomething"，那只有用户第一次执行这个命令时，activate 才会执行；如果写的是 "onStartupFinished"，则编辑器启动完成后立即调用。
常见误判是以为插件“开机自启”，其实默认是懒加载——没触发就不激活，也不占资源。但这也意味着：别在 activate 外部写初始化逻辑，否则可能根本没执行。
- 调试时可在
activate第一行加debugger或console.log验证是否进入 - 若插件始终不激活，先检查
package.json的activationEvents是否匹配当前操作（比如开了一个.js文件，但只声明了"onLanguage:python"） -
activate是同步函数，但内部可 await 异步操作（如读取配置、初始化 WebView）
deactivate 为什么经常被忽略？
deactivate 不是必选，但一旦你注册了定时器、WebSocket 连接、事件监听器或全局状态监听，就必须在这里清理。VS Code 在插件停用（比如禁用扩展、重载窗口）前会调用它，但不会等它完成——如果里面有未 await 的 Promise，很可能被直接中断。
典型问题：插件禁用后，后台仍在发请求或打印日志，说明 deactivate 没正确取消订阅。
- 所有通过
context.subscriptions.push()注册的Disposable对象，会在插件卸载时自动释放，这是最稳妥的方式 - 手动创建的
setInterval或vscode.workspace.onDidChangeConfiguration等监听器，必须显式调用.dispose() - 不要在
deactivate里做耗时操作（如写文件、网络请求），它没有超时保障，可能被强制终止
调试时如何确认生命周期是否按预期走？
VS Code 提供了内置调试支持，但默认不暴露生命周期钩子的执行痕迹。最直接的办法是结合 console.log 和 “Extension Development Host” 窗口观察输出。
注意：普通终端里的日志不会显示 activate/deactivate 调用，必须打开开发者工具（Help → Toggle Developer Tools），切到 Console 标签页。
- 在
activate开头和结尾各打一条带时间戳的console.log('activate start/end') - 在
deactivate开头也加日志，然后右键插件 → “Disable” 或执行Developer: Reload Window触发卸载 - 如果只看到
start没有end，大概率是activate报错中断了，需检查错误堆栈
Memento 数据在 deactivate 后还存在吗？
存在，而且这是设计使然。context.globalState 和 context.workspaceState 是持久化的，不依赖插件是否激活。它们写入磁盘，重启 VS Code 后依然可用。
但容易踩的坑是：在 activate 里反复读取并覆盖同一个 key，却没考虑多实例并发或旧数据残留。
-
globalState跨工作区共享，适合存用户偏好；workspaceState仅限当前文件夹，适合临时状态 - 读取时建议用
globalState.get('key', defaultValue)提供 fallback，避免undefined导致后续逻辑崩溃 - 不要在
deactivate里主动globalState.update()—— 它是异步的，且无意义：状态本就持久，写不写都保留
