developer: show running extensions 在远程窗口中不显示 activation time，因该指标依赖本地主进程采集，而远程 extension host 运行在远端且监控通道未上报；应改用远程终端执行 code --status 查看 extensions 区域的真实激活耗时（ms），此为唯一可信来源。
Developer: Show Running Extensions 在远程窗口里不显示 Activation Time
远程开发（SSH/Containers）下，VSCode 的扩展激活耗时数据常为空或不准，因为 Activation Time 依赖本地主进程采集，而远程场景中 Extension Host 运行在远端，指标未完整上报。这不是插件坏了，是监控通道被截断。
实操建议：
- 别信 GUI 里那列空值——改用终端命令验证：
code --status在远程 SSH 终端执行，输出中的Extensions区域仍会显示真实激活耗时（单位 ms），这是唯一可信来源 - 若
code --status也无数据，说明远端 VS Code Server 版本太旧（curl -fsSL https://update.code.visualstudio.com/install.sh | sh - 某些插件（如
ms-python.python）在远程 Python 环境未就绪时会卡在Activating状态却不报错，此时需手动检查远端~/.vscode-server/extensions/下对应插件日志目录里的output.log
gitlens.advanced.caching.enabled=true 导致远程仓库首次加载卡死
GitLens 默认开启全量符号缓存，在远程大仓库（尤其 >50k 提交）中，它会在连接后立即扫描整个 .git/objects 目录——这个操作走的是远端磁盘 I/O，且无法被 VSCode 的文件监视排除机制拦截。
常见错误现象：
- 打开远程项目后，资源管理器空白、右键菜单无响应，持续 90 秒以上
-
Developer: Open Process Explorer显示extensionHost进程 RSS 稳定在 1.2GB+，但 CPU 占用仅 5%——典型 I/O 阻塞而非计算瓶颈 - 远端
htop观察到git进程持续占用单核，iotop -o显示高磁盘读取
解决方式：
- 在远程工作区的
.vscode/settings.json中强制关闭缓存："gitlens.advanced.caching.enabled": false - 禁用自动历史预加载：
"gitlens.fileHistory.availability": "off" - 如必须用缓存，改用按需模式：
"gitlens.gitCommands.enabled": false+ 手动触发GitLens: Toggle File Blame Annotations
Copilot 插件在远程环境因代理配置缺失引发后台重试风暴
远程开发时，Copilot 插件默认复用本地 VSCode 的代理设置，但远端系统环境变量（如 HTTPS_PROXY）未同步，导致每次请求超时后进入指数退避重试，每分钟发起 12–18 次失败连接，拖垮整个 extensionHost 线程。
判断依据：
- 远端
journalctl -u code-server或~/.vscode-server/data/logs/下出现大量fetch failed: TypeError: fetch failed日志 -
Developer: Show Running Extensions中github.copilot的CPU列持续闪烁（非稳定高占，而是脉冲式跳动） - 本地网络正常，但远程终端执行
curl -v https://api.github.com超时
修复要点：
- 在远端
~/.bashrc或~/.zshrc中显式导出代理：export HTTPS_PROXY=http://your-proxy:8080 - 在远程工作区
.vscode/settings.json补充："http.proxy": "http://your-proxy:8080"和"copilot.proxy": "http://your-proxy:8080" - 重启远端 VS Code Server（非仅 reload window）：在远程终端执行
killall -9 code-server，再重新连接
Remote - SSH 连接失败时 extensionHost 不释放监听器
当 Remote - SSH 因网络抖动或密钥变更连接失败，插件会卡在 Activating 状态并持续轮询，但未正确清理 workspace.onDidChangeConfiguration 等全局监听器，导致后续所有扩展初始化被阻塞——这是云环境下最隐蔽的“假死”根源。
典型表现：
- 反复重连 SSH 后，新打开的文件不再有语法高亮，
Developer: Show Running Extensions中多数插件状态为Activated但Startup Time为 0 - 执行
Developer: Restart Extension Host无效，必须彻底退出 VSCode 并杀掉远端code-server进程 - 远端
lsof -i :port显示大量处于TIME_WAIT状态的连接，目标端口为 GitHub Copilot 或 LSP 服务地址
临时缓解：
- 连接前先确认 SSH 可通：
ssh -T git@github.com，避免插件在无效连接上浪费重试次数 - 在本地 VSCode 的全局
settings.json中加入："remote.SSH.enableDynamicForwarding": false（禁用动态端口转发，减少连接复杂度） - 长期方案：升级 Remote - SSH 至 v0.112+，该版本修复了连接失败后监听器泄漏问题（见 GitHub issue #8921）
远程开发环境下的插件性能退化，往往不是某个插件变慢，而是多个插件在不同层级（网络、I/O、事件监听）同时暴露设计缺陷。最麻烦的是那些不报错、不崩溃、只是默默把主线程锁住几秒的插件——它们不会出现在错误面板里，只能靠 code --status 和远端系统工具交叉验证。
