Remote-SSH是当前最稳、最原生、最贴近真实开发流的VSCode远程方案，它通过在远程启动vscode-server进程实现完整语言服务与调试能力；SSHFS仅支持文件挂载，缺失后台语言功能；Remote Server Manager为快照式同步，不实时响应远程变更。
直接用 Remote-SSH 扩展，不是“能用”，而是当前最稳、最原生、最贴近真实开发流的选择。其他方案（如 SSHFS、Remote Server Manager）在特定场景下可用，但会绕开 VSCode 的核心远程机制，带来权限、调试、终端一致性等隐性问题。
Remote-SSH 是默认且推荐的远程文件树方案
VSCode 官方维护的 Remote-SSH 扩展把整个远程工作区“搬进”编辑器：它不是挂载文件，而是启动一个远程 VS Code Server 进程，所有语言服务（如 IntelliSense、调试器、格式化）都在远端运行。这意味着你看到的文件树就是真实的远程目录结构，且右键菜单、Ctrl+P 全局搜索、Git 状态栏都完全可用。
- 必须提前在服务器上安装
openssh-server并确保用户有 shell 权限（不能是/bin/false或/usr/sbin/nologin） - 连接配置写在
~/.ssh/config里比写进 VSCode 设置更可靠，支持 HostName 别名、ProxyJump、IdentityFile 等完整 OpenSSH 语法 - 首次连接时 VSCode 会自动上传并运行
vscode-server，若卡在 “Installing VS Code Server” 阶段，大概率是远程$HOME权限太严格（比如umask 077），需手动chmod 755 ~
SSHFS 扩展适合只读或轻量编辑，别指望调试
SSHFS 扩展本质是 FUSE 挂载，文件系统层面透传，VSCode 认为它是“本地路径”。好处是启动快、不依赖远程 server 进程；坏处是所有后台语言功能（比如 C/C++ 的 c_cpp_properties.json 解析、Python 的 Pylance 类型推导）都失效——因为这些服务默认只信任“Remote-SSH 工作区”上下文。
- 编辑大文件（>10MB）容易卡顿，因为每次保存都要走一次 SSH 写入，无缓冲优化
- 无法使用
Remote-SSH的Attach to Process调试，也看不到远程进程列表 - 如果服务器启用了
StrictModes yes（默认），而~/.ssh/authorized_keys权限是 644，SSHFS会静默失败——它不报错，只是挂载后资源管理器空着
Remote Server Manager 适合多协议混用，但文件树非实时同步
Remote Server Manager 的文件树是“快照式”的：点击展开目录时才发起 SFTP LIST 请求，不监听远程变更。这意味着你在终端里 touch new.js，VSCode 资源管理器不会自动刷新，必须手动右键“Refresh”。
- 支持 FTP/SFTP/SSH 多协议，适合要同时连老系统（只有 FTP）和新云主机的运维场景
- 右键“Open in Terminal” 启动的是独立 SSH 会话，和
Remote-SSH的集成终端不共享环境变量（比如没加载~/.bashrc中的pyenv） - 上传大文件时若断连，进度条消失但后台仍在传输，重连后不会续传，得从头来
真正关键的细节是：VSCode 的远程能力分两层——“文件可见性”（靠协议拉目录）和“开发能力完整性”（靠远程 server 进程）。Remote-SSH 两者都做，SSHFS 和 Remote Server Manager 只解决第一层。如果你需要打断点、看变量、跑测试、用 Git 图形化操作，就别跳过 Remote-SSH 的 setup 成本。
