我自己也遇到过和你一模一样的需求——公司严格禁止本地存储任何源码，只能在远程机器上操作，踩过不少坑后，现在稳定用这几个方案，分享给你：

1. 直接用SSH运行远程Neovim（最省心无依赖） #

这是我目前用得最多的方案，完全不需要额外插件，所有操作都在远程机器上完成，本地不会留下任何源码文件：

• 直接在本地终端执行：ssh user@你的远程机器IP "nvim +cd/项目路径"，就能直接在远程启动nvim并进入项目目录
• 如果怕断开连接丢失工作，可以配合远程的tmux：先SSH进远程机器启动tmux，再在里面打开nvim，之后断开重连时，只要敲ssh user@你的远程机器IP tmux attach就能恢复之前的会话
• 优势：延迟极低（所有计算、LSP服务都在远程运行），完全符合“本地无源码”要求，不需要折腾任何插件配置
• 小优化：可以在本地~/.ssh/config里加几行配置，让连接更顺畅：

  Host remote-dev
    HostName 你的远程机器IP
    User 你的用户名
    RequestTTY force
    RemoteCommand tmux attach || tmux new -s nvim-workspace
  

  之后只要敲ssh remote-dev就能自动连接并恢复tmux会话

2. 用Remote Neovim插件（本地UI + 远程核心） #

这个方案相当于把远程的Neovim核心和本地的UI界面打通，所有文件操作、LSP服务都在远程跑，本地只负责显示和输入，体验接近本地编辑：

• 给本地Neovim装个remote-nvim插件
• 配置好后，执行:RemoteStart user@你的远程机器IP /项目路径，插件会自动在远程启动Neovim实例，并把界面同步到本地
• 优势：能保留你本地Neovim的配置习惯，远程LSP完全正常工作，本地不会存储任何源码文件，延迟比sshfs低很多
• 注意：远程机器只需要安装Neovim即可，不需要额外依赖，非常轻量化

3. 优化Netrw的远程目录支持 #

你提到Netrw单文件编辑好用，但目录操作没搞定，其实Netrw本身就支持远程目录的完整操作，只要调整下使用方式：

• 打开远程目录时记得加末尾的斜杠：nvim scp://user@你的远程机器IP/项目路径/
• 打开后Netrw会以目录列表展示，你可以直接导航到文件打开，此时nvim会在本地/tmp创建临时缓存文件（符合你说的/tmp允许的要求），关闭Neovim后这些临时文件会自动删除
• 要让LSP正常工作，可以在本地Neovim里配置自动识别远程项目根目录，比如用vim.fs.root来检测项目的.git或package.json这类标识文件
• 可以加几个Netrw的配置优化体验：

  let g:netrw_liststyle = 3 " 树状显示目录结构
  let g:netrw_banner = 0 " 关闭顶部冗余横幅
  let g:netrw_tmpdir = '/tmp' " 指定临时文件存储目录
  

4. 解决Distant.nvim的依赖问题 #

你说Distant.nvim装不上，大概率是因为远程机器没装Rust环境，其实可以跳过编译，用预编译的二进制文件：

• 下载对应远程机器系统的Distant预编译二进制文件，传到远程机器的~/.local/bin目录（确保这个目录在系统PATH里）
• 本地安装Distant.nvim插件，然后执行:DistantConnect user@你的远程机器IP，之后就能像操作本地目录一样操作远程目录，所有文件操作都在远程完成，本地不会存源码
• 优势：支持完整的目录导航、LSP工作，延迟比sshfs好很多

最后说下你提到的rsync方案——真心不推荐，哪怕你手动删除本地文件，也难免会有缓存或临时文件残留，很容易违反公司的规定，还是上面几个方案更稳妥。

备注：内容来源于stack exchange，提问作者ataha322