💻 欢迎参加 6 月 3 日 MS Build 上的 VS Code 直播活动。

远程开发常见问题解答

本文涵盖了各 Visual Studio Code 远程开发扩展的常见问题。请参阅 SSH、容器 (Containers) 和 WSL 文章，了解有关设置及使用各项功能的更多详细信息。或者，您可以尝试入门教程，帮助您快速在远程环境中运行。

有关 GitHub Codespaces 的问题，请参阅 GitHub Codespaces 文档。

通用

什么是 Visual Studio Code 远程开发？

Visual Studio Code 远程开发扩展包允许您在容器、远程机器（通过 SSH）或 Windows Linux 子系统 (WSL) 中打开任何文件夹，并利用 VS Code 的全部功能集。这意味着无论您的代码位于何处或托管在何处，VS Code 都能提供本地品质的开发体验，包括完整的 IntelliSense（代码补全）、调试等。

与本地编辑相比，VS Code 远程开发有哪些优势？

远程开发的部分优势包括：

  • 能够与本地运行环境不同的操作系统上进行编辑、构建或调试。
  • 能够在与目标部署环境相匹配的环境中进行开发。
  • 使用比本地机器更大或更专业的硬件进行开发。
  • 能够编辑存储在其他位置（例如云端或客户现场）的代码。
  • 分离开发环境以避免冲突、提高安全性并加快新成员上手速度。

与使用网络共享或同步文件相比，VS Code 远程开发提供了显著提升的性能，并能更好地控制开发环境和工具。

远程开发扩展与 GitHub Codespaces 有什么关系？

GitHub Codespaces 是一项提供托管云端开发环境的服务，可通过 VS Code 和基于浏览器的全新编辑器进行访问。该服务还允许 VS Code 和基于浏览器的编辑器访问自托管环境（桌面或服务器），而无需 SSH 服务器，甚至无需直接的网络路由。您可以在 GitHub Codespaces 文档中阅读更多信息。

虽然远程开发扩展和 Codespaces 扩展共享技术和功能，但远程开发扩展是单独发布的，可以独立于 GitHub Codespaces 运行。

远程开发扩展是如何工作的？

Visual Studio Code 远程开发允许您的本地 VS Code 安装通过将某些命令的执行移动到“远程服务器”，透明地与远程机器（无论是虚拟的还是物理的）上的源代码和运行时环境进行交互。当您连接到远程端点时，VS Code 会自动安装 VS Code Server，该服务器可以托管直接与远程工作区、机器和文件系统交互的扩展。

Architecture summary

有关扩展的更多详细信息，请参阅支持远程开发。

远程开发扩展如何保护对远程机器、虚拟机或容器的访问？

Visual Studio Code 远程开发使用现有的、众所周知的传输协议（如 Secure Shell (SSH)）来验证和保护流量。除了这些众所周知的安全传输协议所使用的端口外，无需公开开放任何端口。

注入的 VS Code Server 以您登录机器时所使用的相同用户身份运行，确保 VS Code 及其扩展不会在未经许可的情况下获得不恰当的提权访问。服务器由 VS Code 启动和停止，且不与任何用户或全局登录/启动脚本挂钩。VS Code 管理服务器的生命周期，因此您无需担心它是否正在运行。

VS Code Server 可以单独安装或使用吗？

不能。VS Code Server 是远程开发扩展的一个组件，由 VS Code 客户端管理。当 VS Code 连接到端点时，它会自动安装和更新；如果单独安装，可能会很快过期。它不供其他客户端使用或授权使用。

VS Code Server 的连接要求是什么？

安装 VS Code Server 需要您的本地机器具有通往以下地址的出站 HTTPS (端口 443) 连接：

  • update.code.visualstudio.com
  • vscode.download.prss.microsoft.com

默认情况下，Remote - SSH 会尝试在远程主机上下载，如果失败，则会在建立连接后回退到在本地下载 VS Code Server 并将其传输到远程。您可以通过 remote.SSH.localServerDownload 设置来更改此行为，选择始终在本地下载并传输，或者从不本地下载。

Dev Containers 扩展始终在本地下载并传输到容器中。

您可以使用 Extensions: Install from VSIX... 命令在没有互联网连接的情况下手动安装扩展，但如果您使用扩展面板或 devcontainer.json 安装扩展，您的本地机器和 VS Code Server 将需要通往以下地址的出站 HTTPS (端口 443) 访问权限：

  • marketplace.visualstudio.com
  • *.gallerycdn.vsassets.io (Azure CDN)

最后，一些扩展（如 C#）从 download.microsoft.com 或 download.visualstudio.microsoft.com 下载次要依赖项。其他扩展（如 Visual Studio Live Share）可能有额外的连接要求。如果你遇到问题，请查阅扩展的文档以获取详细信息。

服务器与 VS Code 客户端之间的所有其他通信均通过以下传输通道完成（取决于扩展）：

  • SSH：已验证的安全 SSH 隧道。
  • Containers：Docker 的配置通信通道（通过 docker exec）。
  • WSL：随机本地端口。

您可以在网络连接文章中找到 VS Code 本身需要访问的位置列表。

为什么在使用 Remote - 扩展时，无法在 Container Tools 扩展中看到我的本地容器？

默认情况下，Container Tools 扩展将在远程运行。虽然这在某些情况下是合理的默认设置，但这意味着当 VS Code 连接到远程 SSH 主机、容器或 WSL 时，扩展可能不会显示本地容器。

您可以使用以下解决方案之一来解决此问题：

使用远程开发需要在主机上安装哪些 Linux 包或库？

远程开发要求内核 >= 4.18，glibc >= 2.28 以及 libstdc++ >= 3.4.25。近期基于 x86_64 glibc 的发行版支持效果最好，但具体要求可能因发行版而异。

Dev Containers 和 WSL 扩展支持基于 musl 的 Alpine Linux，Remote - SSH 支持 ARMv7l (AArch32) / ARMv8l (AArch64)。但是，某些扩展中的原生依赖项可能导致它们无法在非 x86_64 glibc 发行版上运行。请注意，实验性的 ARMv8l (AArch64) 仅在 VS Code Insiders 中可用。

有关详细信息，请参阅Linux 远程开发。

我可以在较旧的 Linux 发行版上运行 VS Code Server 吗？

从 VS Code 1.99 版本（2025 年 3 月）开始，VS Code 分发的预构建服务器仅与基于 glibc 2.28 或更高版本的 Linux 发行版兼容。例如，这些包括 Debian 10、RHEL 8 或 Ubuntu 20.04。

如果您提供了包含所需库版本的 sysroot，VS Code 仍然允许用户通过 Remote - SSH 扩展连接到不受支持的操作系统（glibc < 2.28 或 libstdc++ < 3.4.25 的 OS）。此方法为您和您的组织提供了迁移到较新 Linux 发行版的时间。

VS Code 版本 基础要求 备注
>= 1.99.x 内核 >= 4.18, glibc >=2.28, libstdc++ >= 3.4.25, binutils >= 2.29 <无>
重要

此方法是一种技术规避方案，并非官方支持的使用场景。

按照以下步骤为该规避方案配置环境：

  1. 构建 sysroot

    我们建议使用 Crosstool-ng 来构建 sysroot。以下是一些可以作为起点的示例配置：

    以下示例容器也可用于拥有已安装 Crosstool-ng 的环境：

    FROM ubuntu:latest

RUN apt-get update
RUN apt-get install -y gcc g++ gperf bison flex texinfo help2man make libncurses5-dev \
python3-dev autoconf automake libtool libtool-bin gawk wget bzip2 xz-utils unzip \
patch rsync meson ninja-build

# Install crosstool-ng
RUN wget http://crosstool-ng.org/download/crosstool-ng/crosstool-ng-1.26.0.tar.bz2
RUN tar -xjf crosstool-ng-1.26.0.tar.bz2
RUN cd crosstool-ng-1.26.0 && ./configure --prefix=/crosstool-ng-1.26.0/out && make && make install
ENV PATH=$PATH:/crosstool-ng-1.26.0/out/bin

    一旦您拥有了安装有 Crosstool-ng 且配置准备就绪的环境，运行以下命令以生成 sysroot：

    mkdir toolchain-dir
cd toolchain-dir
cp <path-to-config-file> .config
ct-ng build

  2. VS Code Server 在安装过程中会使用 patchelf 来从 sysroot 中提取所需的库。

重要

已知 patchelf v0.17.x 会导致远程服务器段错误，我们建议使用 patchelf >=v0.18.x。

  1. 在远程主机上安装 patchelf 二进制文件和 sysroot

  2. 创建以下 3 个环境变量：

    • VSCODE_SERVER_CUSTOM_GLIBC_LINKER 指向 sysroot 中动态链接器的路径（用于 patchelf 的 --set-interpreter 选项）。
    • VSCODE_SERVER_CUSTOM_GLIBC_PATH 指向 sysroot 中库位置的路径（用作 patchelf 的 --set-rpath 选项）。
    • VSCODE_SERVER_PATCHELF_PATH 指向远程主机上 patchelf 二进制文件的路径。

现在，您可以使用 Remote - SSH 扩展连接到远程主机。连接成功后，VS Code 将显示一个对话框和横幅消息，提示该连接不受支持。

我可以在 32 位 ARM Linux 主机上运行 VS Code Server 吗？

VS Code 1.122 版本是最后一个支持在 32 位 ARM Linux 主机上运行预构建服务器的版本。从 VS Code 1.123 版本开始，您将需要使用受支持的 x86_64 或 ARM64 Linux 主机进行远程开发。

我可以安装单个扩展而不是扩展包吗？

可以。远程开发扩展包为您提供了一种方便的方式，让您可以在功能发布时访问所有最新的远程功能。但是，您可以随时从应用商店或 VS Code 扩展视图中安装单个扩展。

如何查看和配置扩展设置？

与 Visual Studio Code 的其他部分一样，您可以通过各自的设置自定义每个远程开发扩展。以 Dev Containers 为例，您可以通过在扩展视图中打开该扩展（⇧⌘X），并导航到功能贡献 (Feature Contributions) 来查看所有 Dev Containers 设置的列表。

List of settings in Feature Contributions

WSL

使用该扩展与使用 WSL 作为终端相比有什么优势？

您可以将 WSL 视为运行在 Windows 上的 Linux 机器，您可以在其中安装 Linux 特定的框架/工具（例如 Python、Go、Rust 等），而不影响您的 Windows 设置。然后，您可以使用 VS Code 和 WSL 扩展在 WSL 中安装的上下文里进行开发，与 Windows 上安装的内容隔离。

例如，您可能会在 WSL 中安装 Go 栈（编译器、调试器、Lint 工具等）。如果您仅在 Windows 上运行 VS Code，则必须同时在那里安装相同的 Go 栈才能获得智能补全、调试、“转到定义”导航等功能。而且由于语言服务是在 Windows 上运行的，它们不知道 WSL 中有什么。

诚然，您可以从 Windows 在 WSL 中运行二进制文件，反之亦然，但常规 VS Code 扩展不知道如何做到这一点。这是我们最初支持 WSL 调试的方式，但很快意识到我们必须更新所有扩展以了解 WSL。

我们决定让部分 VS Code 在 WSL 中运行，并让在 Windows 上运行的 UI 与在 WSL 中运行的 VS Code Server 通信。这就是 WSL 扩展实现的功能，随之而来的是，Go 扩展与其余 Go 工具（编译器、调试器、Lint 工具）一起在 WSL 中运行，而 VS Code 在 Windows 上运行。

使用这种方法，语言功能（如智能补全）只需针对 WSL 中的内容即可工作，而无需在 Windows 上进行任何设置。您不必担心路径问题，也不必在 Windows 上设置不同版本的开发栈。如果您要将应用程序部署到 Linux，则可以将 WSL 实例设置为看起来像您的运行时环境，同时仍然在 Windows 上获得丰富的编辑体验。

扩展作者

作为扩展作者，我需要做什么？

VS Code 扩展 API 抽象了本地/远程细节，因此大多数扩展无需修改即可工作。但是，鉴于扩展可以使用任何它们想要的 Node 模块或运行时，在某些情况下可能需要进行调整。我们建议您测试您的扩展（尤其是在容器中），以确保无需更新。详情请参阅支持远程开发。

当用户远程连接时，扩展可以访问本地资源或 API 吗？

当 VS Code 连接到远程环境时，扩展被分类为 UI 或 工作区 (Workspace) 扩展。UI 扩展在本地扩展宿主中运行，可以贡献 UI 或个性化功能（例如主题），并有权访问本地文件或 API。工作区扩展在远程扩展宿主中与工作区一起运行，并完全有权访问源代码、远程文件系统和远程 API。虽然工作区扩展不侧重于 UI 自定义，但它们也可以贡献资源管理器、视图和其他 UI 元素。

当用户安装扩展时，VS Code 会尝试推断正确的位置并根据其类型进行安装。不需要远程运行的扩展（如主题和其他 UI 自定义）会自动安装在 UI 端。所有其他扩展都被视为工作区扩展，因为它们的功能最全。但是，扩展作者也可以使用 package.json 中的 extensionKind 属性覆盖此位置。

如果您的扩展未按预期运行，可以采取一些步骤来检查它是否在正确的位置运行，或者是否应该具有不同的 extensionKind。另请参阅支持远程开发，了解关于扩展作者需要了解的远程开发和 Codespaces 的更多详细信息。

许可与隐私

位置

您可以在此处找到 VS Code 远程开发扩展的许可协议：

为什么远程开发扩展及其组件不是开源的？

Visual Studio Code 远程开发扩展及其相关组件使用开放的计划、问题追踪和功能请求流程，但目前不是开源的。这些扩展共享的源代码也用于完全托管的远程开发服务，例如 GitHub Codespaces 及其相关扩展。

有关更多信息，请参阅Visual Studio Code 与“Code - OSS”的区别以及微软扩展许可文章。

远程开发扩展的连接位置有什么限制吗？

您可以自由地将这些扩展用于个人或企业用途，以连接到您自己的物理机器、虚拟机或容器。这些可以是本地部署的，位于您自己的私有云或数据中心，Azure 或其他云/非云托管服务提供商处。您不能在这些扩展或其相关组件之上构建公共产品或服务（见下一个问题）。

我可以使用 VS Code 远程开发扩展来构建我自己的产品或服务吗？

您可以将这些扩展与您自己的内部或私有服务一起使用。您不能在 VS Code 远程开发扩展或其相关组件（例如 VS Code Server）之上构建公共或商业服务。您不能创建扩展或操纵远程开发扩展的其他扩展。虽然许可证指出您可能不会“提供该软件作为独立或集成的产品，或将其与您的任何应用程序组合供他人使用”，但您可以记录如何将这些扩展与您的服务结合使用。

我可以将 VS Code Server 重新打包或重复使用到我自己的公共服务产品中吗？

不能。许可证规定您可能不会“提供该软件作为独立或集成的产品，或将其与您的任何应用程序组合供他人使用”，这意味着您不能在 VS Code Server 之上构建公共产品或服务。

如果我对是否可以将这些扩展用于 X 有疑问，我该问谁？

请提交一个 Issue。

GDPR 与 VS Code 远程开发

VS Code 远程开发扩展遵循与 Visual Studio Code 本身相同的 GDPR 政策。有关详细信息，请参阅常规 FAQ。

问题或反馈

有问题或反馈？

5/28/2026
English 한국어 中文(简体) 中文(繁體)
© . This site is unofficial and not affiliated with Microsoft.