Remote-SSH不提供文件实时同步，而是通过vscode-server直接读写远程文件系统；保存操作即真实写入远程磁盘，无上传动作。同时启用SFTP插件会引发路径错位、覆盖冲突与监听失效等问题，应禁用其uploadOnSave并避免叠用。
Remote-SSH 本身不提供文件实时同步，它直接操作远程文件系统；所谓“实时同步”是错觉，本质是本地编辑器通过 SSH 隧道读写远程磁盘——所以别配 SFTP 插件去叠床架屋，反而引入冲突和延迟。
Remote-SSH 连接后文件修改为什么“看起来像同步”
你保存一个 app.py，VSCode 并没有把文件传过去；它调用的是远程服务器上的文件系统 API（通过 vscode-server 进程），直接写入 /home/user/project/app.py。整个过程不经过本地磁盘中转，也没有“上传”动作。
- 所有 Git 操作（
git status、git commit）运行在远程，看到的是远程仓库真实状态 - 终端里
ls -l或cat app.py显示的内容，和你在编辑器里刚保存的一致 - 如果远程服务（如 Python 进程）监听文件变化并热重载，它感知的是真实文件变更，不是“同步事件”
为什么装了 SFTP 插件反而容易出问题
当你同时启用 Remote-SSH 和 SFTP 插件时，两个插件会争夺同一组文件的控制权：
- SFTP 插件默认开启
"uploadOnSave": true，你在 Remote-SSH 环境下保存文件，它会再触发一次上传，可能覆盖远程正在被调试进程修改的内容 - SFTP 的
remotePath和 Remote-SSH 当前打开的文件夹路径不一致时，会出现“编辑了 A 文件，SFTP 却上传到 B 路径”的静默错位 - Remote-SSH 的
vscode-server进程自带文件监听机制，SFTP 的watcher可能因权限或 inotify 限制失效，导致“改了没反应” - 错误日志里常出现
EPERM: operation not permitted或ENOSPC: no space left on device，其实是 SFTP 尝试写临时文件失败，而非磁盘满
需要真正双向同步时该怎么做
只有当你的工作流明确要求“本地有副本 + 远程有运行环境”（比如离线写代码、联网后批量推送到测试机），才考虑同步。此时应放弃 SFTP 插件，改用命令行工具并显式控制时机：
- 用
rsync -avz --delete ./ user@host:/path/to/project/手动触发，加--dry-run先预览 - 在 VSCode 任务中配置：
tasks.json里定义一个sync-to-server任务，绑定快捷键（如Ctrl+Alt+U） - 禁止自动同步：确保 SFTP 插件的
"uploadOnSave"设为false，Remote-SSH 的"remote.SSH.enableDynamicForwarding"保持默认false - 路径映射必须严格一致：SFTP 的
"localPath"应等于你用 Remote-SSH 打开的文件夹路径，否则 diff 逻辑失效
容易被忽略的关键点
Remote-SSH 的“编辑即生效”依赖远程服务器的 vscode-server 正常运行。如果你发现保存后远程文件没变，先检查：
- 远程用户家目录下
~/.vscode-server是否可写（常见于 NFS 挂载或容器环境） - 是否误启用了 VSCode 的“设置同步”功能，把本地的 SFTP 配置覆盖到了远程
- 终端里执行
ps aux | grep vscode-server，确认进程存在且没卡在Downloading... -
settings.json中不要出现"files.autoSave": "afterDelay"和"files.autoSaveDelay"同时配置，这会导致远程写入超时静默失败
