通过 VPN 远程构建 C++：把工具链留在主机上

共享目录挂载成功，编辑器能打开文件，构建却仍然跑在笔记本上。没有任何报错，这正是最容易迷惑人的地方。远程路径不等于远程工具链，而能通过挂载读取文件的编辑器，会毫不犹豫地在本地调用编译器。要解决的是把工作区搬过去，而不只是搬字节。

挂载的目录不是工作区

通过 SSH 或 SMB 挂载只给了你一个路径。编译器、构建系统和调试器是否来自远端，取决于编辑器决定在哪里执行它们。很多配置会读取远程文件并在本地编译，随后在一个只存在于服务器上的头文件上报错。

症状很微妙：构建以部分结果“成功”，或者在编辑器里看起来正确的包含路径上失败。

证明哪台主机在响应

用真正的远程会话连接，而不是挂载，然后在该会话提供的终端里执行三条只读命令。VS Code 的SSH 指南写明：已连接的远程窗口中的终端运行在远程主机上，同一个会话也承载调试。如果组织限制了远程组件，请先取得批准。

hostname 会显示你所在的机器名，pwd 会显示工作区实际所在的位置，command -v c++ 会打印 shell 将要执行的编译器。三个答案都应该指向服务器，而不是笔记本。

它们不能证明版本或构建配置是对的。把这一步单独拿出来，与项目自己的说明对照。

让一次修改走完构建和调试

在远程工作区做一个小改动并保存在那里。从同一目录执行文档里的构建，确认输出反映的是你的改动，而不是别处的旧副本。随后通过同一个远程会话启动调试器，让二进制路径和工作目录指向服务器的构建树。源码路径必须一致，因为把改动解析到笔记本路径的调试器，调试的其实是另一个文件。

如果调试目标报告的路径以你本地的家目录开头，说明启动配置仍然在本地思考。

网络依赖留在主机上

在构建主机上发起的拉取依赖、git 操作或测试运行，用的是那台主机的网络和凭据，而不是你笔记本的 VPN 会话。笔记本能访问私有软件源，并不意味着服务器也能。若构建需要访问仓库，服务器就需要一条到它的路由，这是防火墙层面的事，不是编辑器设置。

反过来对测试应用同样成立。从浏览器访问服务器上的服务是另一条连接，需要获批的私有路径或受限的端口转发，而不是一个开放的监听端口。

断开连接而不丢失工作

在连接断开之前保存并提交，或者至少记录工作树。远程编辑会话并不保证正在运行的构建或未保存的缓冲区能挺过网络中断。凡是需要活得比你这次会话更久的东西，都要用项目支持的作业或会话流程。

分工于是很清楚：笔记本是界面，服务器拥有工作区和工具链，VPN 提供通路。搬文件和搬构建是两个不同的决定。