Remote Tunnels 并非远程运行本地代码，而是将本地 VS Code 的编辑、调试、终端能力通过微软中继服务暴露给远程客户端，执行始终在本地；需 1.82+ 桌面版、Microsoft/GitHub 账户登录且状态栏显示头像 + “Tunnels Ready”，隧道进程持续运行，工作区须用 code /path/to/project 显式打开，否则浏览器访问会卡在“Loading workspace…”或连接失败。
Remote Tunnels 不能“远程运行本地代码”——它只是把本地 VS Code 的编辑、调试、终端能力，通过官方中继服务暴露给远程浏览器或另一台 VS Code 客户端。真正执行代码的，始终是你的本地机器。
Remote-Tunnels: Create Tunnel 命令不出现？先查账户和版本
命令面板搜不到 Remote-Tunnels: Create Tunnel，不是插件没装，而是基础条件没满足：
- VS Code 必须是
1.82+桌面版（macOS/Linux/Windows），vscode.dev或移动端 App 不支持创建 - 必须用 Microsoft 账户（Outlook/Hotmail 邮箱）或 GitHub 账户登录——GitHub Enterprise、GitLab、Google 账户均无效
- 登录入口在左下角状态栏「未登录」→「使用 Microsoft 账户登录」，不能靠点击 GitHub 图标“碰运气”
- 已用其他方式登录过？先点齿轮图标 →「帐户」→「注销」，再重登
- 登录成功后，状态栏右下角必须同时显示头像 +
Tunnels Ready，缺一不可
生成的 https://vscode.dev/tunnel/xxx 打不开？重点看三件事
页面卡在 “Connecting…” 或跳转到 GitHub 登录页后无响应，不是链接错了，而是隧道服务没就绪：
- 确认远端 VS Code 桌面版仍在运行，且
remote.tunnels.enabled设置已开启（设置里搜该配置项并勾选） - 执行
ps aux | grep tunnel（macOS/Linux）或在 Windows 任务管理器搜索code-tunnel，看后台进程是否存活——关机、休眠、手动kill都会中断 - 本地开了 Clash/Surge/Proxyman 等代理？必须关闭。Remote Tunnels 不走系统代理，强行转发会导致
WebSocket connection failed
浏览器能打开链接，但终端卡在 “Loading workspace…”？工作区没绑定对
Remote Tunnels 共享的是「当前打开的文件夹」，不是整个系统：
- 必须用
code /path/to/project启动 VS Code，而不是开空窗口再手动打开文件夹 - 如果远端 VS Code 关闭过或虚拟机重启了，隧道进程已退出，需回到远端重新执行
Remote-Tunnels: Create Tunnel - 浏览器访问时，即使你已在本地登录账户，Web 端仍要独立完成一次 GitHub/Microsoft 登录校验
Web 端终端能跑代码，但和本地 shell 不是一回事
Web 端终端是 WebAssembly 实现的轻量版，功能受限明显：
- 不继承本地 shell 的
history、alias或zsh配置 - 跑不了
sudo、systemd、dockerd等需要 root 权限或守护进程的服务 - 大文件搜索（
Ctrl+Shift+F）和全量项目索引变慢，因为文件需经中继节点传输，不是本地读取 - Python、Pylance 这类语言支持插件可用，但
Remote-SSH、Docker、GitLens等依赖本地进程的扩展会直接灰掉
真正容易被忽略的点是：隧道不是“连接上就一劳永逸”。它默认 7 天过期，但更早失效的往往是本地进程意外退出——比如 macOS 自动清理后台进程、Windows 快速启动导致休眠后隧道未恢复、或者你顺手关掉了那个挂着 code-tunnel 的终端窗口。只要它停了，所有链接立刻失效，连刷新都没用。
