vscode本身不提供镜像同步能力，所谓“镜像同步”需依赖外部工具实现；sftp扩展仅支持手动或保存触发的单向上传，remote-ssh是直接编辑远程文件而非同步副本，dev containers通过bind mount实现真正镜像但限于容器场景。
VSCode 本身不提供“镜像同步”这种底层文件系统级能力，所谓“镜像同步”在实际开发中通常指双向、实时、路径严格对齐的文件同步——但 VSCode 官方扩展（如 Remote - SSH）默认只做单向增量同步，而 SFTP 扩展默认是手动/保存触发上传。真要接近“镜像”效果，得组合使用或切换机制。
Remote - SSH 的同步行为不是镜像，而是按需加载
Remote - SSH 连接后，VSCode 实际把远程文件系统挂载为本地工作区视图，所有编辑操作直接作用于远程磁盘。它不复制、不比对、不监听本地文件变更——你改的是远程文件，自然“看起来同步”。但这也意味着：
- 本地磁盘上没有副本，断网即无法编辑（除非提前用
scp或rsync拉取） - 远程删除文件，本地视图立刻消失；本地新建文件夹，远程立即创建（因为是同一文件系统）
-
uploadOnSave这类配置在 Remote - SSH 下无效——它根本不用上传 - 如果你需要本地留一份可离线编辑的副本，并和远程保持强一致，Remote - SSH 不满足“镜像”定义
SFTP 扩展无法自动双向同步，uploadOnSave 有路径陷阱
很多人以为开启 "uploadOnSave": true 就能“镜像”，但实际行为受限于 remotePath 和本地文件位置：
- 只有保存路径在
remotePath对应的本地子目录下时，才会触发上传（例如remotePath: "/var/www/app"，本地必须在./app/xxx.js编辑才生效） - 如果本地项目根目录和
remotePath不对齐（比如本地是/Users/me/project，远程是/opt/app），保存不会上传，也不会报错，只是静默失效 - 下载操作（
Download from SFTP Server）是手动的，且不会自动覆盖已修改的本地文件，容易冲突 - 没有内置的文件删除同步：远程删了文件，本地不会自动删；本地删了，远程也不会删
Dev Containers 是最接近“镜像同步”的方案
当你用 devcontainer.json 配置 mounts，本质是 Docker bind mount，属于操作系统级目录映射：
- 主机与容器内文件系统完全共享，任意一方修改，另一方立刻可见（包括创建、删除、权限变更）
- 不需要插件介入，不依赖 SSH 或 SFTP 协议，无传输延迟，无中间缓存
- 但仅适用于容器场景；若目标是远程 Linux 服务器（非容器），这条路走不通
- 注意
source必须是绝对路径或使用${localWorkspaceFolder}变量，相对路径会挂载失败 - Windows 主机挂载到 Linux 容器时，换行符、大小写敏感性、符号链接可能出问题，需在
postCreateCommand中预处理
真正需要镜像同步？别依赖 VSCode 插件
VSCode 的所有同步方案都是编辑器层的“便利功能”，不是文件系统工具。如果你的场景要求：
- 本地和远程目录完全一致（含空目录、隐藏文件、删除同步）
- 离线编辑后联网自动补全差异
- 跨平台（Windows ↔ Linux）保留权限与编码
那就该用 rsync + inotifywait 或 lsyncd 这类专业工具，在远程机器上部署监听服务。VSCode 可以调用它们（通过 tasks.json 或终端命令），但不能替代它们。
最容易被忽略的一点：所谓“实时镜像”，90% 的问题其实出在路径映射没对齐、忽略规则写错、或误以为 Remote - SSH 的“打开远程文件夹”等于“本地有副本”。先确认你到底要的是“编辑体验一致”，还是“两份独立磁盘内容强一致”——前者用 Remote - SSH，后者绕开 VSCode 更靠谱。
