docker是本地docker，怎么会有网络链接的问题，你如果在mac上开发linux 的c/c++服务器程序就知道连接docker进行开发是多么理想的情况了
不够话说回来，vscode 的remote功能即时再好，在跳板机面前还是没用，这就很尴尬
1 个赞
同步文件可以用这个软件unison
vscode remote development实际上实现的东西远多于此，不仅包含 language sever，而且debugger protocol 也包含了，所以可以实现ssh到remote，或者在local docker机器上无缝debug，设置断点之类的。
当然如果是远程的docker下debug会复杂点，我自己也没尝试过，但是是可以通过exprot port然后attach的。python用的是这个debugpy GitHub - microsoft/debugpy: An implementation of the Debug Adapter Protocol for Python.
其实我目前远程开发的方式还是直接ssh + tmux然后完全在 terminal下用emacs去debug，复杂一点的就直接上gdb, pdb，简单一点能搞定的就用dap-mode了。
别用 ssh 用 mosh，爽的飞起。
自己玩的话，在自己电脑上装 Docker 是没问题的。如果是公司内使用，会有专用的服务器来承载，然后采用 macvlan 的网络（或类似技术），伪装成一台拥有独立局域网 IP 的服务器。
为了我们的需求，我在 DockerHub 上做了一个基于 Alpine 的镜像，把 Node.js、Git、rsync、Tmux、SSH 服务器以及 Emacs 都添加了进去，这样就可以在启动容器后随便玩了。
我是前端开发，这么做主要的目的就是转移 Node 服务，在夏天减少自己 Mac 的发热，防止电脑降频带来的开发效率影响。至于环境统一以及其它的理由，反而是次要的。
新员工入职后的一般操作是：
- 在本地以 Tmux 启动 rsync，监视本地项目文件夹改动，只要文件夹有更新就同步到自己专用的开发容器中；
- 关掉本地的控制台，需确保 Tmux 已经成功启动；
- SSH 到远程容器，使用 Tmux 启动 Node 服务器；
- 关掉远程 SSH 连接，需确保开发容器中 Tmux 已经启动；
- 以上操作只要系统不重启，不安装新的 NPM 包就不需要再重复了（一些必要的操作还需要远程操作）
这样只要在自己 Mac 中只需要修改，哪怕是晚上在家盲写了一堆代码，第二天带到公司，触发一次保存操作，就可以将代码同步到开发容器中，以独立 IP 的形式访问容器中的 Node 服务了。至于是否在开发容器中使用 TUI 形式的 Emacs，已经不重要了。
unison 牛逼！好好研究下
跳板机的话，可以通过 ssh config 的 proxy 命令来做，不太清楚你们那里能不能行，但我们这可以用一个类似下面这样的命令来做，vscode 做的还是比较方便的，只要支持 ssh host 能直连，vs code remote dev 就能用
Host * # 认证方式，他会挨个尝试，我们会用 kerberos
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no
PreferredAuthentications gssapi-with-mic,publickey,password,keyboard-interactive
Host jump-proxy
HostName jump-proxy.jumpserver.host # 这就是 jump server 的域名或者 IP
Host demo-env1
Hostname 0.0.0.0 # 真实要连的 IP
User root
ProxyCommand ssh -qW %h:%p jump-proxy
我们这儿不行，而且是违规操作
个人觉得这功能还是有市场的. 比如对一些系统相关的底层开发, 或者公司内部依赖库比较多, 再或者需要控制工具和依赖版本保证兼容性的, 大多最终都会采用一个统一的远程环境做编译和调试. 这样的话像 vscode 这种可以完成编辑, 编译, 调试一条龙的, 对一部分用户会很有吸引力.
另一方面对很多公司来说也降低了新员工的培训成本, 只需要让他装些 vscode 插件, 连上服务器就能开始干活了.
clipetty目前还不支持mosh。然后也mosh没有gpg foraward的功能。https://github.com/ztlevi/dotty/blob/master/misc/gpg/aliases.zsh#L18-L74
我的配置在这儿了，你可以查漏补缺https://github.com/ztlevi/dotty/blob/master/misc/unison/default.prf#L1
额，clipetty 和 gpg forward 我都没用过。我就是连上去开 emacs 然后开发。
不得不说，emacs 的远程开发能力在 vscode 面前就是弟弟🤣（折腾 tramp 一周后的感受，已经放弃）
能不能了解一下，主要是哪些操作vscode remote相比emacs tramp有明显优势？
想学习下，自己不是很熟vscode
tramp的原理我不是太了解具体的。vscode是服务器客户端的模式，在remote端可以理解为安装了一个vscode server，然后只要remote端的环境依赖都支持的话理论上本地可以装的插件远程都可以直接装上就可以用。然后本地client相当于就只是绘制前端显示，数据计算都在remote server上，交互通过网络协议传输。
体验上来说优点大概有：1. 配置特别简单，几乎就是透明而且自动化的，而且连接成功以后用户操作几乎和在本地没啥区别。2.插件支持完善，绝大部分开发常用的都直接可以装上去用。3.性能不错，只要网络延迟和带宽不错的话不会太卡，一些插件本身的性能不会受网络影响因为运算都在remote上面。4.官方原生支持WSL和docker连接，用windows的和需要连docker的比较方便。
tramp我看大佬们的帖子貌似主要是太卡了，而且只适合修改单个文件直接管理远程的workspace的能力比vscode差很多。这两点结合起来又导致很多插件并不能很好的支持tramp就没法在远程环境使用。
那远程装一个Emacs也没区别吧🤔
在远程装emacs然后通过终端远程访问应该可以吧，但是用emacs的有很多人想用gui啊 
- 配置特别简单
这个emacs就不比了。。。
- 插件支持完善
tramp里面应该大部分都是可以用的，我常用的magit projectile.el lsp-mode，应该都是可以的。
特别说lsp-mode的话，里面实际的server应该还是要装在server端。vscode这点应该是一样的。
不过我能理解这两个原理差别挺大的，emacs更多是本地的lisp代码在执行，通过统一的文件操作去实现插件的功能，vscode是直接执行server的代码了。
- 性能不错
tramp的性能确实很多人提，我自己的感觉的确实没那么好，但是只发生一些时候，比如新打开文件，或者保存，或者magit（我粗略的感觉是有时候到1s这个级别会能感觉出来），其他时候简单的找个文件都已经挺快了。
我没有用过太差的网络，不知道是不是有差异，以后可以试试。
- wsl docker
我自己不用wsl，但是docker常用，ssh | docker | ssh这种都可以支持。
workspace的能力是指什么呢，是不是类似projectile，那这个支持的也没问题。
没有GUI感觉很多特性都没了。。岂不是变成vim了 
。
不过话说回来，vim在remote上支持（如果是vim over ssh的话），不管是相比vscode还是tramp都差很多吧。
网络不好的时候，一个按键一次网络传输，相比vscode和tramp这种自己有buffer的，不太合理。那个延迟没法接受。
tramp具体我没配好所以也没怎么用，都是看帖子别人说的。插件确实我也看到支持比以前好一些，感觉主要还是性能问题吧？大部分好像都是反映说很卡的，尤其开了project的话。