VSCode中不存在官方认证的“受信任扩展”标签，其安全性依赖工作区信任机制与扩展权限声明；用户需手动信任工作区，扩展须在package.json中明确声明untrustedWorkspaces支持级别。
“受信任的扩展”在 VSCode 市场中并不是一个官方认证标签，而是用户对扩展安全性、稳定性和维护质量的一种经验性判断。VSCode 官方市场本身不提供“受信任”或“已认证”的分级标识，也不会为扩展颁发安全背书。真正起作用的是 VSCode 编辑器自身的
工作区信任机制
和
扩展权限声明模型
——它们共同决定一个扩展能否在你的环境中运行、能做什么、以及是否需要你主动授权。
它和工作区信任直接挂钩
即使某个扩展来自知名作者（比如 Microsoft、ESLint 团队），只要它被安装在
未受信任的工作区
中，它的功能就可能被大幅限制：
无法自动执行任务（如通过
启动构建）
调试配置（
）被禁用
部分需要文件系统访问或进程启动的 API 调用会被拦截
智能感知、代码补全等依赖后台服务的功能可能降级或失效
扩展自身需明确声明信任需求
负责任的扩展开发者会在
中通过
字段说明其行为边界：
GitHub Copilot
GitHub AI编程工具，实时编程建议
下载
表示该扩展可在受限模式下提供基础功能（如语法高亮）
表示它完全适配未信任环境，无需额外权限
或未声明，则默认只在“受信任工作区”中启用全部能力
用户才是最终的信任决策者
所谓“受信任”，本质是你手动点击状态栏的“受限模式”提示、选择“信任此工作区”的那一刻。VSCode 不会替你判断一个扩展是否安全，而是把控制权交还给你：
打开 GitHub 克隆的陌生项目？先别急着点“信任”，可先检查
下的
配置文件
有无可疑命令
企业环境可通过策略配置
统一行为，但依然不等于自动授信扩展
看到某扩展要求
权限或声明“需要完整文件系统访问”，就要多留个心眼
基本上就这些——没有“官方盖章”的可信扩展，只有你自己确认过的可信工作区 + 明确声明权限的扩展 + 合理的本地策略配置。
tasks.jsonlaunch.jsonpackage.json"capabilities""untrustedWorkspaces": "limited""untrustedWorkspaces": "supported""untrustedWorkspaces": "restricted".vscode/"security.workspace.trust.untrustedFiles": "open""*"