远程开发常见问题解答
本文涵盖了每个 **Visual Studio Code 远程开发** 扩展的常见问题。有关每个扩展的设置和使用其功能的更多详细信息，请参见 SSH、容器 和 WSL 文章。或者尝试介绍性的 教程，帮助您快速在远程环境中运行。
有关 GitHub Codespaces 的问题，请参阅 GitHub Codespaces 文档。
常规
什么是 Visual Studio Code 远程开发？
Visual Studio Code 远程开发扩展包 允许您在容器、远程机器（通过 SSH）或 Windows Subsystem for Linux 中打开任何文件夹，并利用 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**，并可以托管直接与远程工作区、机器和文件系统交互的扩展。
有关扩展的更多详细信息，请参见 支持远程开发。
远程开发扩展如何确保对远程机器、VM 或容器的访问安全？
Visual Studio Code 远程开发使用现有的、众所周知的传输方式，如 安全 shell 来进行身份验证和安全流量。除了这些众所周知的安全传输方式使用的端口外，无需公开打开任何端口。
注入的 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*.vo.msecnd.net（Azure CDN）
默认情况下，Remote - SSH 会尝试在远程主机上下载，如果失败，则会回退到本地下载 VS Code Server，并在建立连接后将其远程传输。您可以使用 remote.SSH.localServerDownload 设置更改此行为，始终在本地下载，然后传输，或从不本地下载。
开发容器扩展始终在本地下载并传输到容器中。
您可以使用 **Extensions: Install from VSIX...** 命令手动安装扩展而无需互联网连接，但是如果您使用扩展面板或 devcontainer.json 安装扩展，则您的本地机器和 VS Code Server 将需要到以下地址的出站 HTTPS（端口 443）访问：
marketplace.visualstudio.comvscode.blob.core.windows.net*.vo.msecnd.net（Azure CDN）*.gallerycdn.vsassets.io（Azure CDN）
最后，一些扩展（如 C#）从 download.microsoft.com 或 download.visualstudio.microsoft.com 下载辅助依赖项。其他（如 Visual Studio Live Share）可能具有额外的连接要求。如果您遇到问题，请参阅扩展的文档以了解详细信息。
服务器和 VS Code 客户端之间的所有其他通信都通过以下传输通道完成，具体取决于扩展：
- SSH：经过身份验证的安全 SSH 隧道。
- 容器：Docker 配置的通信通道（通过
docker exec）。 - WSL：随机本地端口。
您可以在 网络连接文章 中找到 VS Code 本身需要访问的位置列表。
为什么使用 Remote - 扩展时，我在 Docker 扩展中看不到我的本地容器？
默认情况下，Docker 扩展将远程运行。虽然在某些情况下这是一个合理的默认设置，但它意味着当 VS Code 连接到远程 SSH 主机、容器或 WSL 时，扩展可能无法显示本地容器。
您可以使用以下解决方案之一来解决此问题。
-
打开一个新的本地窗口（**文件 > 新窗口**），并使用它来处理本地容器。
-
安装 Dev Containers 扩展，并在需要查看本地容器的情况下使用 远程资源管理器。
-
仅限 WSL：使用 Docker for WSL 2 技术预览版 或 配置 Docker Desktop 以在 WSL 1 中使用。
-
仅限 Dev Containers：在容器中转发 Docker 套接字并安装 Docker CLI（仅此而已）。
-
使用 extensionKind 属性 强制扩展为
ui。但是，这会阻止某些命令运行。
要在主机上使用远程开发，需要安装哪些 Linux 软件包或库？
远程开发需要内核 >= 4.18、glibc >=2.28 和 libstdc++ >= 3.4.25。最新的 x86_64 glibc 基于的 Linux 发行版具有最佳支持，但具体要求可能因发行版而异。
对基于 musl 的 Alpine Linux 的支持适用于 Dev Containers 和 WSL 扩展，而 ARMv7l（AArch32）/ ARMv8l（AArch64）则适用于远程 - SSH。但是，某些扩展中的本机依赖项可能导致它们无法在非 x86_64 glibc 发行版上运行。请注意，实验性的 ARMv8l（AArch64）仅在 VS Code 预览版 中可用。
有关更多详细信息，请参阅 使用 Linux 进行远程开发。
我可以在较旧的 Linux 发行版上运行 VS Code 服务器吗？
从 VS Code 1.86.1 版本（2024 年 1 月）开始，远程服务器构建工具链的最低要求已提高。VS Code 分发的预构建服务器与基于 glibc 2.28 或更高版本的 Linux 发行版兼容，例如 Debian 10、RHEL 8 或 Ubuntu 20.04。VS Code 仍允许用户连接到不受 VS Code 支持的操作系统（未提供 glibc >= 2.28 和 libstdc++ >= 3.4.25 的操作系统），直到 2025 年 2 月。这为您和您的公司迁移到更新的 Linux 发行版提供了时间。当您连接到不受 VS Code 支持的操作系统版本时，VS Code 会显示一个对话框和横幅消息。
我可以安装单个扩展而不是扩展包吗？
是的。 远程开发扩展包 为您提供了一种便捷的方式，可以访问所有最新的远程功能，这些功能会在它们发布时提供。但是，您始终可以从 Marketplace 或 VS Code Extensions 视图安装单个扩展。
如何查看和配置扩展设置？
与 Visual Studio Code 的其他部分 一样，您可以通过其设置自定义每个远程开发扩展。以 Dev Containers 为例，您可以在扩展视图（⇧⌘X（Windows、Linux Ctrl+Shift+X））中打开扩展，然后导航到**功能贡献**，以查看所有 Dev Containers 设置的列表。
WSL
扩展相对于将 WSL 用作终端有什么优势？
您可以将 WSL 视为在 Windows 上运行的 Linux 机器，您可以在其中安装特定于 Linux 的框架/工具（例如 Python、Go、Rust 等），而不会影响您的 Windows 设置。然后，您可以使用 VS Code 和 WSL 扩展在 WSL 中安装的内容的上下文中进行开发，与 Windows 上安装的内容隔离。
例如，您可能会在 WSL 中安装 Go 堆栈（编译器、调试器、linters 等）。如果您仅在 Windows 上运行 VS Code，则还必须在 Windows 上安装相同的 Go 堆栈才能获得智能完成、调试、转到定义导航等功能。由于语言服务在 Windows 上运行，因此它们不知道 WSL 中的内容。
确实，您可以从 Windows 在 WSL 中运行二进制文件，反之亦然，但常规的 VS Code 扩展不知道如何执行此操作。这就是我们最初支持在 WSL 中调试的方式，但很快意识到我们必须更新所有扩展以了解 WSL。
我们决定让 VS Code 的部分内容在 WSL 中运行，并让在 Windows 上运行的 UI 与在 WSL 中运行的 VS Code 服务器进行通信。这就是 WSL 扩展所启用的功能，借助它，Go 扩展与其他 Go 工具（编译器、调试器、linters）一起在 WSL 中运行，而 VS Code 在 Windows 上运行。
使用这种方法，智能完成等语言功能只需针对 WSL 中的内容正常工作，而无需在 Windows 上进行任何设置。您无需担心路径问题，也无需在 Windows 上设置不同版本的开发堆栈。如果您将应用程序部署到 Linux，您可以将 WSL 实例设置为类似于您的运行时环境，同时仍然获得在 Windows 上的丰富编辑体验。
扩展作者
作为扩展作者，我需要做什么？
VS Code 扩展 API 使本地/远程细节抽象化，因此大多数扩展无需修改即可正常工作。但是，鉴于扩展可以使用它们想要的任何节点模块或运行时，因此在某些情况下可能需要进行调整。我们建议您测试您的扩展（尤其是在容器中），以确保不需要任何更新。有关详细信息，请参阅 支持远程开发。
当用户远程连接时，扩展可以访问本地资源或 API 吗？
当 VS Code 连接到远程环境时，扩展被归类为UI 或工作区扩展。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”之间的差异 和 Microsoft 扩展许可证 文章。
对远程开发扩展可以连接的位置有限制吗？
您可以自由使用这些扩展来连接到您自己的物理机器、虚拟机或容器，无论是个人使用还是企业使用。这些机器可以位于内部、您自己的私有云或数据中心、Azure 或其他云/非云托管提供商。您不能在这些扩展或其相关组件（请参阅下一个问题）的基础上构建公共产品或服务。
我可以使用 VS Code 远程开发扩展来构建自己的产品或服务吗？
您可以将这些扩展与您自己的内部或私有服务一起使用。您不能在 VS Code 远程开发扩展或其相关组件（例如 VS Code 服务器）的基础上构建公共或商业服务。您不能创建扩展其他扩展或操纵远程开发扩展的其他扩展。虽然许可证声明您可能不会“将软件作为独立或集成产品提供或将其与您的任何应用程序组合起来供他人使用”，但您可以在文档中说明如何在您的服务中使用这些扩展。
我可以在自己的公共服务产品中重新打包或重用 VS Code 服务器吗？
不行。许可证声明您可能不会“将软件作为独立或集成产品提供或将其与您的任何应用程序组合起来供他人使用”，这意味着您不能在 VS Code 服务器的基础上构建公共产品或服务。
关于我是否可以使用这些扩展来完成 X，我该向谁询问？
请提交 问题。
GDPR 和 VS Code 远程开发
VS Code 远程开发扩展遵循与 Visual Studio Code 本身相同的 GDPR 政策。有关更多详细信息，请参阅 常见问题解答。
问题或反馈
有疑问或反馈吗？
- 请参阅 技巧与窍门。
- 在 Stack Overflow 上搜索。
- 添加一个功能请求或报告问题。