wsl+vscode调试断点不触发_程序员干货，微策略出品：容器时代的开发利器——VSCode预览版...

容器在DevOps世界已经火了若干年，容器的隔离性，移植性，扩展性为开发测试和产品发布带来一股清流，基本已经成为微服务架构的事实标准。但容器开发便利性一直不如本机，我们能做到的往往是把容器作为运行时。容器内工具缺失和调试的困难，让我们常常将开发工作区挂载后减少文件反复拷贝，然而容器的更改Build还是需要一堆额外的脚本来支持，基于命令行的调试就显得更加简陋。

作者曾用过一段时间的Jupyter，利用Jupyter的Web界面就有了一种在容器内编程的感觉。很可惜，Jupyter并不具备开发工具的所有特性，它只是一个交互渠道。

北京时间，在PYCon 2019大会上，微软发布了Visual studio code remote，将容器开发生产力上升到全新的高度。一时间VSCode成了程序员讨论的热门议题，今天作者抱着尝试的心态，看看这件新工具能为我们带来什么。

显然，VSCode remote将源代码放在的远端，它支持容器，远程计算机，以及微软的WSL。我们看看它具体如何工作。

首先，下载VSCode预览版，注意稳定版里还没有这个功能。本码农使用Mac，下载后直接拖入应用程序就开始使用。

微软提供了若干种基本语言的样例，我们选择顺手的Python，创建工作区。

选择Open Folder in Container后，VSCode自动创建容器。

容器创建完成，开始自动运行。

一切顺利，打开看了一下这个样例，是个基于Flask的Web应用，Flask果然火。

根据终端输出，Flask的端口显然暴露在9000上了，浏览器验证成功。

这是最激动人心的一部分，容器内的断点调试，实在是太方便了。想要这个功能的人不知有多少，也一直相信业界早晚会有开源支持，还是微软先做出来了。良心作品，必须点赞。

我们顺带看一眼容器的样子，vsc-vscode-remote前缀的显然是我们正在使用的容器，该容器由VSCode生成。

进入容器查看现有的安装，更多的包管理可以修改代码中Dockerfile或者requirements文件。

我们尝试做一些开发，加入echarts，修改requirements文件和app.py。

中间有一点小障碍，大致是echarts在flask集成时的templates被弃用了，反复调试了几把，正好充分享受了容器调试的乐趣。比如这个Terminal窗口就非常贴心，直接显示容器内部的情况，省去了每次docker ps后找出ID再docker exec –it进去看。

再比如这个Debug Console，方便查看运行时的值。

有了调试工具，几轮排查下来就搞定了，想想要是没有这个工具，反复的Build容器，起来，关闭，命令行进去，不知还得多费多少周折。

写在最后

经过验证，微软的VSCode的确是良心之作，鉴于VSCode开源还有跨平台，是时候从atom或者sublime转移到VSCode了。