VSCode的globalState和workspaceState不适合存储敏感数据，因为它们以明文形式保存在文件系统中，易被泄露；而vscode.SecretStorage API通过操作系统原生凭据管理器加密存储，提供更高安全性。
VSCode的扩展存储API在保存敏感信息时，核心安全机制并非直接通过其通用状态存储（如globalState或workspaceState），而是通过专门设计的vscode.SecretStorage API。这个API将敏感数据委托给操作系统原生的凭据管理器进行安全存储，从而利用了操作系统层面的加密和隔离能力，而不是在扩展自身的文件系统或配置中直接暴露。
解决方案
要安全地保存敏感信息，扩展开发者应始终使用VSCode提供的vscode.SecretStorage API。这个API抽象了底层操作系统凭据管理器的复杂性，为扩展提供了一个统一、安全的接口来存储和检索诸如API密钥、令牌或用户凭据等敏感数据。它确保了这些信息不会以明文形式存储在用户可轻易访问的文件中，并且通常需要用户认证才能访问，进一步提升了安全性。
为什么VSCode的globalState和workspaceState不适合存储敏感数据？
当我们谈到VSCode扩展的数据持久化，最先想到的可能就是context.globalState和context.workspaceState。它们确实非常方便，可以轻松地保存一些用户偏好设置或者扩展内部的状态。比如，我写一个代码片段管理器，可能会把用户最近使用的片段ID存到globalState里，或者某个工作区特有的配置存到workspaceState。这都没问题，因为这些数据通常不涉及安全敏感性。
但问题来了，它们的存储机制决定了它们不适合敏感数据。globalState的数据通常存放在用户配置目录下的一个JSON文件里，比如~/.config/Code/User/globalStorage/（Linux），而workspaceState则是在工作区.vscode目录下的一个文件。这些文件，说到底，就是硬盘上的普通文件。虽然VSCode对这些文件有一定的管理和隔离，但它们通常是未加密的，并且在用户机器被攻破的情况下，或者仅仅是用户不小心分享了这些文件，里面的内容就可能泄露。想象一下，如果你的API密钥就这么明晃晃地躺在一个JSON文件里，那简直就是给攻击者送钥匙。这对于开发者来说，是一个非常常见的误区，我当初也差点犯过。
vscode.SecretStorage API是如何工作的，它真的安全吗？
vscode.SecretStorage是VSCode为解决敏感数据存储问题而专门引入的API，它确实是目前最推荐和最安全的方案。它的工作原理其实是“借力打力”，它自己并不直接存储敏感数据，而是作为一个桥梁，将数据委托给操作系统原生的凭据管理器。
具体来说：
- macOS上，它会使用Keychain（钥匙串）。
- Windows上，它会使用Credential Manager（凭据管理器）。
-
Linux上，它通常会依赖
libsecret库，这又会与GNOME Keyring等凭据服务交互。
这些操作系统级别的凭据管理器都具备以下关键安全特性：
- 加密存储：数据在存储前会被加密，并且通常与用户账户或设备绑定。
- 隔离：不同应用程序或用户的数据是相互隔离的，一个应用无法轻易访问另一个应用的敏感数据。
- 用户认证：在某些情况下，尤其是在首次访问或长时间未访问时，凭据管理器可能会要求用户输入密码或进行生物识别认证，进一步增加了一层保护。
所以，当一个扩展使用vscode.SecretStorage存储一个API密钥时，这个密钥实际上是被OS的凭据管理器安全地保管起来了。VSCode扩展自身只知道如何通过API去“请求”这个密钥，而不知道它具体存在哪里，或者如何直接解密。
它真的安全吗？答案是：在大多数实际场景下，它提供了“足够”的安全。它的安全性与操作系统本身的安全性紧密相关。如果用户的操作系统被深度攻破，或者用户主动授予了恶意软件访问凭据管理器的权限，那么任何存储在其中的敏感信息都可能面临风险。但对于VSCode扩展的日常使用，这已经是最高级别的内置安全方案了，远比自己加密或者明文存储要靠谱得多。
下面是一个简单的使用示例：
import * as vscode from 'vscode';
export async function activate(context: vscode.ExtensionContext) {
let disposable = vscode.commands.registerCommand('myExtension.storeSecret', async () => {
const token = await vscode.window.showInputBox({
prompt: '请输入您的API令牌',
password: true // 确保输入时显示为点，增加私密性
});
if (token) {
await context.secrets.store('myApiToken', token);
vscode.window.showInformationMessage('API令牌已安全存储！');
}
});
context.subscriptions.push(disposable);
let retrieveDisposable = vscode.commands.registerCommand('myExtension.retrieveSecret', async () => {
const token = await context.secrets.get('myApiToken');
if (token) {
vscode.window.showInformationMessage(`检索到的API令牌: ${token}`);
// 实际应用中，你不会直接显示令牌，而是使用它
} else {
vscode.window.showWarningMessage('未找到API令牌。');
}
});
context.subscriptions.push(retrieveDisposable);
let deleteDisposable = vscode.commands.registerCommand('myExtension.deleteSecret', async () => {
await context.secrets.delete('myApiToken');
vscode.window.showInformationMessage('API令牌已删除。');
});
context.subscriptions.push(deleteDisposable);
}在实际开发中，如何选择合适的存储策略来平衡安全与便捷？
在开发VSCode扩展时，存储策略的选择并非一刀切，它需要根据数据的性质、敏感程度以及用户体验的需求来做权衡。这就像你在家里放东西，普通杂志和传家宝肯定不能放一个地方。
-
非敏感、用户偏好或UI状态：
- 使用场景：例如，用户界面的布局偏好、最近打开的文件列表、某个功能的开关状态、上次使用的选项等。
-
推荐API：
context.globalState（全局持久化）或context.workspaceState（工作区级别持久化）。 - 考量：这些数据不含隐私或安全风险，直接存储在JSON文件中便于管理和快速读写，也方便用户在必要时手动清理。便捷性是这里的首要考量。
-
敏感信息（如API密钥、令牌、密码）：
- 使用场景：任何可能导致账户被盗用、数据泄露或未经授权访问的凭证。
-
推荐API：
vscode.SecretStorage。 - 考量：安全性是这里的绝对优先。即使这意味着可能需要用户在某些情况下进行额外的认证，或者存储过程稍微复杂一点，也必须坚持使用。不要尝试自己实现加密，因为这通常比你想象的要复杂得多，而且很容易出错。
-
大量非敏感数据或自定义文件格式：
- 使用场景：例如，一个代码分析工具可能需要存储大量的缓存数据、索引文件，或者一些自定义的配置文件。
-
推荐方案：直接在文件系统中创建和管理文件。你可以使用
context.extensionPath或context.globalStorageUri来获取扩展的存储路径，然后在此路径下创建子目录和文件。 - 考量：对于这类数据，性能和存储容量可能是主要因素。文件系统提供了最大的灵活性。但需要注意的是，你仍然要确保这些文件不包含敏感信息，并且在卸载扩展时考虑是否需要清理这些文件。
一个好的实践是，始终问自己：“如果这段数据被公开，会有什么后果？”如果答案是“没什么大不了的”，那globalState或workspaceState就可能适用。如果答案是“灾难性的”，那么vscode.SecretStorage就是唯一的选择。有时候，开发者会想方设法绕过SecretStorage，觉得它麻烦，但这种“便捷”往往是以牺牲用户安全为代价的。我们作为开发者，有责任保护用户的数据，即便这意味着我们自己要多写几行代码。
