一.趋势
伴随着容器化、深度学习等技术的生产应用，越来越多的场景面临“远程”开发的问题，例如：
服务器
虚拟机
容器
而这些远程环境很难甚至不可能在本地重建一份，比如：
特定配置：例如曾遇到的
.Net Framework 4.0 + MSSQL 2000，并且各自安装了一堆特定版本补丁的历史项目，几乎无法还原其环境特定操作系统：例如在 Windows 下开发运行在 Linux 的项目
对本地环境的破坏性太大：一些全局性的东西，很难都做到隔离
依赖本地不具备的硬件能力：例如深度学习需要的计算及存储能力
无论什么原因，总会面临本地与远程环境差异带来的各种不便
二.现状
对于远程开发的场景，一般有 4 种解决方案：
远程桌面：开发体验与本地环境差距较大，并且有些 Linux 发行版无法安装远程桌面
SSH + Vim：不如现代开发工具方便，影响生产力
文件同步工具：慢，而且容易出错
基于浏览器的工具：难以结合本地工具链使用
能够解决一部分问题，但大多牺牲了本地开发环境的诸多便利
那么，有没有办法从本地环境无缝切入远程环境呢？既能享受本地熟悉的全套工具链带来的便利，同时还能进行远程开发呢？
当然有
三.思路
从开发工具的角度来看，需要提供 3 方面的支持：
支持 Windows 下开发 Linux
支持 SSH 连接
支持容器环境
对于 Windows 下开发 Linux 的问题，Win 10 在 2016 年已经提供了Windows Subsystem for Linux (WSL)，可以在 Windows 下直接（没错，不是虚拟机）运行一个 Linux 子系统：
WSL
WSL 提供了基本的文件共享支持，但开发工具（例如 VS Code）面临的情况要更复杂一些：
If you have Python 2.7 and Flask installed on Windows (or none at all!) and Python 3.7 and Django installed in the Linux distro, you wouldn’t get proper completions or linting because VS Code was looking at the Windows versions of everything.
开发工具需要明确区分不同环境，于是产生了一种很有意思的思路：
We convinced ourselves that what we needed was a way to run VS Code in two places at once, to run the developer tools locally and connect to a set of development services running remotely in the context of a physical or virtual machine (for example, a container or VM).
简言之，让一部分（环境无关的）插件运行在本地环境，另一些（环境相关的）插件运行在远程环境，比如容器、虚拟机、WSL、服务器等等……
如此这般，一切问题都解决了，在支持远程开发的同时兼顾了本地开发体验：
This gives you a rich local development experience in the context of what is in the remote environment.
四.VS Code 远程开发套件
VS Code 在 1.35 版本（2019/6/4）正式发布了 Remote Development 支持：
Remote Development (Preview) available in Stable – You can now use the Remote Development extensions in Stable.
并在最新 1.36 版本丰富了更多特性：
Remote Development (Preview) improvements – Save to local file system, drag and drop files to remotes, and more.
安装Remote Development插件包即可，目前（2019/7/6）插件包里提供了 3 个插件：
Remote – SSH：将远程机器或虚拟机作为开发环境
Remote – Containers：将 Docker 容器用作开发环境
Remote – WSL：将 Windows 子系统作为开发环境
Remote – SSH
通过 SSH 通道连接远程机器、虚拟机或容器，继而访问其文件系统、管理终端、运行/调试应用，如下图：
具体的，基于 SSH 的远程开发支持让我们：
不必受限于本地环境的硬件条件
能够管理多套不同的远程开发环境
能够远程调试
应用运行在远程，而开发调试都能在本地进行，继续享受熟悉的本地完备工具链带来的便利
P.S.关于 SSH 远程开发的更多细节，见：
Remote – Containers
更进一步地，容器支持允许将指定的 Docker 容器作为开发环境，进而：
能够保证工具链的一致性，并且依靠容器可以快速重建一整套工具链
容器间有着天然的环境隔离，可以在不同的开发环境间切换而不影响本地环境
能够保证开发/构建/测试环境的一致性，便于协作
实现上，结构与 WSL 支持完全一致：
P.S.关于 Docker 容器远程开发的更多细节，见：
Remote – WSL
通过 Remote – WSL 插件，可以将 WSL 用作整套开发环境，具体的，支持以下特性：
用 Windows 在 Linux 环境中开发，而且可以使用平台相关的工具链
编辑位于 WSL 的文件，包括挂载自 Windows 文件系统的那些（如
/mnt/c）在 Windows 上调试运行 Linux 应用程序
P.S.关于 WSL 远程开发的更多细节，见：
五.总结
就目前而言，能够无缝切入远程环境的 IDE，似乎要比云 IDE 更实在一些：
Browser-based tools are useful in a variety of scenarios, but developers don’t want to give up the richness and familiarity that desktop tools provide, or their existing locally installed tool chains.
