扩展与插件供应链
IDE 插件看起来只是一个“安装”按钮，实际却是一段进入开发者账号、源码、凭证和内网的软件。它可能读写用户有权限访问的文件、发起网络请求、启动外部进程、修改构建或提交行为。团队如果只在仓库里放一份推荐清单，就等于把“建议使用”误写成“已经审批”。
真正的治理对象不是插件排行榜，而是一条供应链：谁提出需求，批准的是哪个发布者和版本，包从哪里来，签名和哈希如何验证，能访问什么数据，升级如何灰度，出问题怎样回滚，成员离开或插件停用时如何撤销凭证并清除残留。
先把测试环境与日常身份隔离
插件准入应从非生产账号、隔离 profile 和不含真实密钥的代表仓库开始。变更前记录 IDE 产品与版本、安装渠道、操作系统、扩展唯一 ID、发布者、包版本、下载来源和已安装清单；变更后才能回答“多了什么、由谁带入、如何撤回”。只截一张 Installed 页面，无法证明安装包来源、版本和残留状态。
测试仓库使用虚构数据，不登录生产账号，也不开放 SSH 私钥、云凭证目录或浏览器日常 profile。产品能力并不对等：组织级 allowlist、私有源、设备策略和安装基线解决的是不同问题，不能凭相似菜单名推断相同控制力。Marketplace、许可和企业策略发生变化时，团队基线应以受管设备上的实际策略诊断和产品官方说明为准。
先理解权限：插件不是浏览器里的小组件
VS Code 的扩展运行时安全说明指出，扩展运行在 Extension Host 中，拥有与 VS Code 本身相同的权限，可以读写文件、访问网络、运行外部进程和修改 workspace 设置。第三方发布者信任提示与 Marketplace 签名提高了来源可见性和包完整性，但不是细粒度权限沙箱。
JetBrains Marketplace 的插件安全说明同样明确：插件在 IDE 进程权限下运行，可读写或删除 IDE 用户能访问的数据、连接网络、执行代码；IDE 不提供细粒度权限限制，也不隔离插件。这意味着“只做主题美化”的描述不能代替对实际包和网络行为的审查。
Visual Studio 的 VSIX 可把组件加载进开发环境。官方建议签名，但扩展程序集运行前并不强制必须签名；VSIX 内容被篡改导致签名无效时，安装器可能只是警告。Visual Studio 默认不在管理员模式加载 per-user 扩展，这能缩小提权场景，却不等于普通用户态扩展是受限沙箱。
Eclipse 插件由 OSGi/p2 体系安装到 IDE。p2 可以验证签名者、PGP key 和受信 authorities，也可以被用户配置为允许未签名内容。签名策略如果留给每位开发者临时点击，就不是组织控制。
所以四类产品都应遵循同一条判断：插件按本机应用和供应链制品治理，不按网页小功能治理。
第一次跑通：先做一份可回滚的扩展变更
不要拿格式化、编译或认证类插件做第一轮，它们会改变代码或引入账号。选择一个无账号、无工作区写入需求的测试插件，在隔离 profile 中完成“盘点 -> 安装 -> 验证 -> 禁用 -> 卸载 -> 恢复盘点”。
VS Code 可先导出清单：
code --list-extensions --show-versions | Sort-Object | Set-Content .\extensions-before.txt审批记录中先确定完整 ID 和固定版本，再把占位值替换成真实批准项后安装：
$extension = "publisher.extension@1.2.3" # 替换为审批记录中的真实 ID 与版本
code --install-extension $extension安装后再次导出为 extensions-after.txt 并比较。预期只新增一个 publisher.extension@1.2.3。验证该插件的一个无副作用功能，再从 Extensions 视图禁用、重载窗口、确认功能消失；最后执行：
$extensionId = "publisher.extension" # 替换为刚才安装的真实 ID
code --uninstall-extension $extensionId再次导出清单，预期回到安装前状态。还要检查插件配置和外部 helper 是否残留，因为卸载扩展不保证撤销第三方账号 token 或删除插件创建的缓存。
JetBrains 可在 Settings | Plugins 查看 Installed，安装测试插件后执行相同的启用、禁用、卸载和重启验证。命令行支持 installPlugins <plugin-id>，但固定旧版本通常需要从 Marketplace 下载批准包后执行 Install Plugin from Disk。Visual Studio 在 Manage Extensions 中完成安装、禁用/卸载与重启；Eclipse 在 Installation Details 和 Installation History 中保留安装状态证据，并验证可回到变更前 profile。
最小验证的重点不是“按钮变成 Installed”，而是五项证据：ID 与发布者正确、版本正确、来源正确、功能符合申报、卸载后行为和凭证都被清理。
recommendation 不是 allowlist
VS Code 的 .vscode/extensions.json 或 multi-root workspace 中的 extensions.recommendations 会提示用户安装，用户可以忽略。它适合声明“这个仓库体验更好需要哪些扩展”，不阻止其他扩展，也不批准某个版本。企业扩展管理文档说明，自 VS Code 1.96 起可以使用组织级 AllowedExtensions / extensions.allowed 控制，按发布者、完整扩展 ID、具体版本和平台允许或阻止；未列出的扩展可被阻断，已安装但被策略禁止的扩展会被禁用。
JetBrains 的 Required Plugins 会把需求写入 .idea/externalDependencies.xml，可约束最低和最高版本并提醒成员安装或更新，但它仍不是安全审批或隔离。真正的组织级插件策略属于 IDE Services / IDE Provisioner 一类治理面，可按全部插件、仓库、vendor 或具体插件执行 allow、block、forced block 等规则。
Visual Studio 的 .vsconfig 用于复现 Visual Studio workload 和组件，不应冒充 VSIX 插件 allowlist。私有 extension gallery 能提供内部扩展发现与更新入口，但“能从私有源安装”也不自动阻止用户从其他位置安装 VSIX。需要强制准入时，必须结合受管设备、普通用户权限、网络源控制、应用控制和软件资产审计验证实际效果。
Eclipse 的 Oomph setup、p2 repository 和 feature/IU 列表适合复现基线；受控 update site 与 p2 trust 策略可约束来源和签名。它们是否构成强制 allowlist，取决于是否同时锁定仓库、禁止任意本地安装并管理 trust store。一个团队共享的 update site URL 本身仍只是来源配置。
因此文档中应使用三个不同词：
recommend：提示或便利，用户可忽略。baseline：团队期望安装的产品、版本和配置，可验证重建。allowlist：未批准对象会被技术控制阻断，并有策略生效证据。
签名与发布者：证明来源，不证明安全
VS Code Marketplace 会对发布的扩展签名，客户端安装时验证包的来源与完整性；首次安装第三方发布者时还有发布者信任提示。签名能发现包在分发后被改动，不代表代码没有恶意行为，也不代表依赖无漏洞。扩展包、依赖扩展和 extension pack 的发布者都要分别进入审查范围。
JetBrains Marketplace 的签名链同样用于确认插件在发布和传输过程中未被修改。自定义仓库不会自动获得 JetBrains Marketplace 的重新签名，组织需要用受信内部 CA 或显式受信证书，并限制 trust store 只包含所需 CA。把公共 CA 全部放入插件 trust store 会扩大接受面。
Visual Studio 的 VSIX 签名能显示证书并检测篡改，但官方文档明确，扩展程序集不需要签名才能运行，签名无效时安装器可能只警告。因此治理流程必须把“拒绝未签名/无效签名包”作为组织规则，而不是假设产品总会硬阻断。
Eclipse p2 的 trust 页面允许选择信任的 signer，也可允许未签名内容。企业基线应固定 trusted authorities，启用只信任签名内容的安装方式，并在自动化安装时让签名失败直接失败，不能依赖开发者看懂弹窗。
发布者名称也不是永久身份。批准记录至少保存生态、唯一 ID、发布者账号、下载 URL、证书/签名信息、包哈希、审核版本和审核日期。显示名称变得相似时，唯一 ID 和哈希才是重建依据。
私有源、镜像与离线包
私有源解决的是可用性、知识产权和分发控制，不自动完成安全审查。正确流程是从批准来源获取包，进行恶意代码、秘密、许可证和依赖扫描，记录哈希与签名，再进入内部仓库。客户端只消费已经批准的通道。
VS Code 官方提供企业私有 Marketplace，可选择上游、重托管公共扩展和服务隔离网络；该能力有产品和账号条件，且当前官方说明不支持 VS Code Server 或 Web 客户端连接。规模较小的团队也可保存固定 VSIX，但要保留来源、版本和哈希，不能从聊天附件安装来历不明的包。
JetBrains 支持 custom plugin repository，也可替换默认 Marketplace；内部插件应签名，客户端配置受控仓库和受信证书。IDE Services 的 corporate repository 还能承载组织分发与策略，但能力取决于部署/订阅方案。
Visual Studio Enterprise 支持 additional private extension galleries。离线环境应保存 VSIX、签名验证结果和兼容矩阵；若扩展依赖 MSI、SDK 或外部服务，这些依赖必须一起进入离线清单，不能只缓存 VSIX。
Eclipse 适合用内部 p2 repository 或镜像固定 feature/IU、依赖和 metadata。离线包要同时保存 artifacts 与 metadata，并在隔离环境实际安装；只复制几个 JAR 容易破坏依赖解析和 profile 历史。
从下载到执行：把插件加载链变成可观察对象
插件故障经常被笼统归因于“IDE 不稳定”，因为团队只记录了安装结果，没有记录包怎样进入进程。实际链路至少经过仓库索引、包下载、哈希或签名验证、解包、插件注册、进程加载、工作区激活和外部依赖启动。任一层失败都可能表现为“按钮不存在”或“重启后仍不可用”，但证据完全不同。
VS Code 通常把第三方扩展放入 Extension Host，宿主崩溃、阻塞事件循环或内存失控会同时影响一组扩展；Remote SSH、WSL 和 Dev Container 又会让扩展分别安装在本地 UI 或远端 Extension Host。排障时要同时保存 code --status、扩展宿主日志、扩展运行位置和远端目录，不能只看本地 ~/.vscode/extensions。
JetBrains 插件多在 IDE JVM 权限内运行。插件初始化、索引监听器、VFS 访问和 UI 线程任务可能把启动慢、输入卡顿与索引抖动混在一起；应使用 IDE 日志、线程转储、插件性能报告和禁用对照确认责任。Visual Studio 的 VSIX 还可能安装组件、模板或外部工具；Eclipse p2 则维护 profile、IU 与依赖解析历史。四类产品的目录结构不同，但都要回答三个问题：包是否真的被注册、代码在哪个进程执行、禁用后哪个残留仍在运行。
一次可复核的反向实验可以故意阻断测试插件依赖的无害本地端口，记录激活失败日志和进程树；恢复端口后重新加载窗口，预期插件恢复且不产生第二个 helper。随后禁用插件并重启 IDE，验证 Extension Host / JVM / devenv / Eclipse 进程中不再加载对应组件，外部 helper 退出，网络连接消失。若 UI 显示 Disabled 但 helper 仍存活，说明卸载边界位于插件之外，必须由进程管理、登录项或项目脚本继续清理。
加载证据还决定策略放置位置。仓库 allowlist 只能限制下载候选，签名验证只能证明包来源，受管设备策略负责阻断安装，运行时日志负责发现越界行为，出口代理或终端检测负责观察真实网络与进程。把所有责任压给 Marketplace，会在包已获签名但运行行为失控时失去最后一道证据。
版本、升级与回滚：批准版本而不是批准名字
插件与 IDE API 紧密耦合，IDE 升级和插件升级应进入同一兼容矩阵。基线至少包含 IDE 产品/版本、插件 ID/版本、平台架构、运行时要求、外部 helper 和配置 schema。自动更新适合个人低风险扩展，不适合未经灰度的团队关键链路。
升级采用“小批 canary -> 代表仓库验证 -> 扩大范围”的节奏。验证不仅看 IDE 能启动，还要运行打开项目、索引、构建、调试、提交、代理和认证等受影响路径，并观察启动时间、CPU、内存、网络目标、错误日志和崩溃。
回滚必须在升级前准备：
保存旧插件包、哈希和签名验证结果。导出升级前安装清单和插件配置。记录兼容的 IDE 版本，避免只降插件仍不兼容。
明确禁用、卸载、安装旧包和恢复配置的顺序。若插件创建了数据库、索引或外部账号，确认数据格式能否向后兼容。
VS Code 可安装指定版本或本地 VSIX，并通过 allowlist 钉住批准版本；JetBrains 可从磁盘安装旧版本；Visual Studio 通常需要卸载问题版本后重新安装保留的旧 VSIX，不能把 Marketplace 有旧包当成回滚承诺；Eclipse 可利用 p2 Installation History 或 director 的 revert 回到先前 profile，但回退前仍要备份 workspace 和配置。
AI 插件需要双重准入
AI 插件首先仍是插件，包来源、ID、版本、签名、安装策略、更新回滚、进程与网络行为、卸载和资产登记都要进入插件供应链账本。只要它能读取工作区、调用终端、访问 Git 凭证、连接 MCP 或其他工具，或者把内容发送到云端，就必须提高风险级别。
模型选择、提示词、代理权限、上下文上传、训练与保留策略、MCP 工具批准、代码生成审查和费用治理还需要 AI 工具专项评审。插件准入单中必须附上这份评审结论，至少回答数据发送到哪里、使用哪个企业账号、是否允许读取未打开文件、是否能执行命令、是否能自动应用改动、日志保留多久、如何撤销 token。
不要因为插件来自知名 Marketplace 就输入个人 API key。若发现插件可疑，先禁用并隔离设备，再撤销它接触过的 token、会话和 OAuth 授权；仅卸载插件无法让已泄露凭证失效。
建立插件 SBOM 与审计账本
IDE 插件 SBOM 不必一开始追求复杂平台，但必须可机器读取。每条记录至少包含：IDE 与版本、插件唯一 ID、版本、发布者、来源仓库、下载 URL、包哈希、签名/证书、许可证、直接依赖、外部二进制或服务、安装范围、数据权限、owner、批准单、部署时间、最后使用时间和退场日期。
如果组织已有 CycloneDX 或 SPDX 流程，把 VSIX、ZIP/JAR、Eclipse feature/IU 视为组件，并用 properties 或外部引用补充生态特有 ID。SBOM 解决“装了什么”，批准账本解决“为什么允许”，终端/代理日志解决“实际做了什么”；三者不能互相替代。
定期盘点至少比较四类差异：已安装但未批准、批准但版本漂移、批准但长期未使用、已退场但仍残留。VS Code 可用 code --list-extensions --show-versions 自动导出；其他 IDE 可通过受管部署平台、安装目录、产品清单或 p2 profile 采集。采集脚本必须识别 bundled 与 user-installed，避免把产品内置组件误判为个人插件。
审计还要记录策略本身是否生效。VS Code 可用 Developer: Policy Diagnostics 检查组织策略，但报告可能包含账号标识、会话和扩展访问认证信息，分享前要脱敏。JetBrains IDE Services、设备管理和 Eclipse p2 自动化也应保留策略版本、执行结果和失败设备，而不是只保存一张后台截图。
故障闭环：先隔离变量，再决定回滚
IDE 启动变慢、崩溃或索引异常
先用禁用所有非 bundled 插件或安全模式启动，确认问题是否消失；再二分启用，而不是直接删除整个 IDE 配置。记录问题插件版本、IDE build、堆栈和最小复现仓库。确认后先阻断问题版本，再决定升级、回滚或移除。
VS Code 提供 Extension Bisect；JetBrains 可禁用所有 downloaded plugins；Visual Studio 可在安全模式或禁用扩展后复测；Eclipse 可用干净 profile / 安装历史对照。产品入口不同，证据目标相同：同一 IDE、同一仓库，仅改变一个插件变量。
插件更新后配置不兼容
先备份配置并查看插件日志，区分配置 schema 迁移、IDE API 不兼容和外部 helper 版本不一致。若旧版本无法读取新格式，恢复旧包前同时恢复旧配置。回滚成功后锁住问题版本，不能继续让自动更新重新安装。
内网无法安装或签名验证失败
分别检查 DNS/代理/证书、仓库 metadata、包下载、哈希、签名链和 IDE 兼容范围。不要以“临时关闭签名验证”作为常规修复。若必须应急旁路，应限定设备和时效，记录批准，并在恢复后重装经验证的包。
禁用后行为仍存在
检查是否有另一个同类插件、bundled 组件、外部 helper、后台进程、浏览器扩展或 workspace 脚本承担同一行为。随后检查 token、OAuth grant、配置目录、缓存和自动启动项。退场验收以行为消失和凭证撤销为准，不以 UI 显示 Disabled 为准。
架构取舍：开放 Marketplace、受控上游还是完全离线
开放 Marketplace 成本最低、更新最快，适合低敏感个人环境，但资产漂移和供应链响应压力最大。受控上游允许团队从公共生态选择，经审批后重托管或 allowlist，兼顾更新和治理，适合大多数企业开发环境。完全离线源暴露面最小，但镜像、依赖闭包、签名、漏洞响应和过期包清理成本最高。
选型时看四个维度：数据敏感级别、终端是否受管、升级响应时限、治理团队容量。没有能力维护内部源时，粗暴复制包到共享盘并不会比官方 Marketplace 更安全；有严格隔离要求时，仅写推荐清单也完全不够。
团队治理与落地工程深水区
插件准入采用默认最小化：能用 IDE 内置能力完成的，不重复引入插件；功能重叠时保留一个 owner 明确的实现。高风险插件进入代码审查、网络目的地、外部进程、凭证和数据处理评审，低风险主题类也要登记 ID、版本和来源。
权限不是静态标签。插件升级可能新增依赖、网络服务、AI 能力或自动执行入口，所以版本变化要触发差异审查。对关键插件设置撤销时限：高危通告出现后多久能阻断、多久能盘点受影响设备、多久能撤销凭证。
私有源要有高可用和降级策略，但不能让客户端在内部源失败时自动回退到未受控公共源。包存储保留不可变版本、哈希、签名和下架标记；删除旧包前确认没有受支持基线仍依赖它。
每个插件都要有退场条件：功能进入 IDE 内置、发布者停止维护、许可证变化、漏洞超时未修、性能成本过高、数据边界不再满足或使用率长期为零。退场顺序是冻结新安装、通知 owner、导出依赖和配置、撤销凭证、禁用观察、卸载清理、更新基线与 SBOM，最后验证干净设备不再自动恢复它。
已记录插件唯一 ID、发布者、版本、来源、哈希、签名和许可证。已说明实际权限和网络/外部进程行为，没有把签名写成安全背书。recommendation、baseline、allowlist 三种语义没有混用。
私有或离线源包含完整依赖和 metadata，并在隔离环境安装验证。自动更新、canary、兼容矩阵、旧包和配置回滚路径均已准备。AI 插件已完成数据、账号、工具执行和凭证专项评审。
SBOM、批准账本和设备实际清单可以相互对账。禁用、卸载、残留进程、配置、缓存、OAuth 和 token 已做退场验证。