VSCode本身不自带Node.js运行时或文件同步逻辑，所谓“实时同步”必须明确是「本地编辑→容器内生效」还是「本地编辑→远程服务器生效」；Remote-Containers依赖Docker bind mount实现即时双向同步，Remote-SSH则依赖SFTP+文件监听（需启用轮询防事件丢失），二者机制完全不同，选错将导致fs.watch失效、热重载卡住、断点不命中。
VSCode 本身不自带 Node.js 运行时或文件同步逻辑，所谓“实时同步”必须明确是「本地编辑 → 容器内生效」还是「本地编辑 → 远程服务器生效」。两种路径底层机制完全不同，选错会导致 fs.watch 失效、热重载卡住、甚至调试断点不命中。
确认你用的是 Remote-Containers 还是 Remote-SSH
这是所有配置的前提。Remote-Containers（基于 devcontainer.json）和 Remote-SSH（基于 SSH 连接）的文件同步机制完全独立：
- Remote-Containers 使用 Docker 的
bind mount，只要挂载路径正确，修改即刻反映在容器内，无需额外监听或插件 - Remote-SSH 默认走 SFTP 同步，依赖 VSCode 的文件系统事件监听；一旦本地路径在 NTFS/WSL2 挂载区或 iCloud 同步目录下，
inotify极易丢事件，必须手动启用轮询
查当前连接类型：看左下角状态栏有没有「>Dev Container」或「>SSH: xxx」标识。没有？那你只是在本地开发，根本不存在“远程同步”这回事 —— 所谓实时，只能靠 nodemon 或 ts-node --watch 这类工具监听并重启进程。
Remote-Containers 下必须检查 mounts 和 workspaceFolder
很多人以为写个 image 就完事，结果改了代码容器里完全没反应，问题几乎全出在挂载配置上：
-
source必须是绝对路径或 VSCode 变量（如${localWorkspaceFolder}），不能写相对路径如./src -
target路径要和workspaceFolder一致，否则 VSCode 语言服务找不到文件，TypeScript 类型检查失效 - 如果项目根目录含空格或中文，
source值必须被双引号包裹，否则 Docker 启动失败报错invalid mount config
典型正确写法：
{
"name": "Node.js Dev",
"image": "node:18-alpine",
"workspaceFolder": "/workspaces/my-app",
"mounts": [
{
"type": "bind",
"source": "${localWorkspaceFolder}",
"target": "/workspaces/my-app"
}
]
}
写完保存后，按 Ctrl+Shift+P → Dev Containers: Rebuild and Reopen in Container，别只点 “Reopen”。重建才能让挂载生效。
Remote-SSH 下必须启用轮询监听避免同步丢失
尤其在 macOS + iCloud Drive 或 Windows + WSL2 场景下，inotify 基本不可靠。不配轮询，你会遇到：
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- 保存文件后，远程服务器上对应文件没更新
- 调试时断点灰色，提示
Source map not found - 终端里
ls -l看时间戳没变，但本地编辑器显示已保存
解决方法：在远程主机的 settings.json（不是本地！）里加这两项：
"remote.experimental.fileWatcher.polling": true, "files.watchDogThreshold": 20000
注意：files.watchDogThreshold 单位是毫秒，值太小会频繁轮询拖慢响应，太大又延迟明显。20000 是平衡点，大型项目可提到 50000。
另外，确保远程主机已调大 inotify 限制（即使启用了轮询，某些插件仍会尝试用 inotify）：
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
Node.js 环境一致性不能只靠 devcontainer.json
就算容器启动成功、文件也同步了，require() 仍可能报错，原因常藏在三个地方：
-
package.json里没声明"type": "module"，但代码用了import—— Node.js 会按 CommonJS 解析，直接抛ERR_REQUIRE_ESM -
.vscode/settings.json里禁用了 TypeScript 自带的语言服务（比如装了第三方 JS 补全插件），导致路径跳转、自动导入全部失效 - 本地
node_modules被误同步进容器（尤其用rsync手动同步时），而容器内 Node 版本不同，npm install没跑过，二进制模块（如fsevents）直接崩溃
安全做法：在 devcontainer.json 的 postCreateCommand 里强制重装依赖，并把 node_modules 加进 .dockerignore 或远程同步排除列表（"files.exclude" 里加 **/node_modules/**）。
真正麻烦的从来不是配置本身，而是你以为同步完成了，其实只是 VSCode 没报错而已 —— 文件进了容器，但 nodemon 没监听到变化；代码传到了服务器，但 require.resolve() 因为路径映射错位返回了旧版本模块。动手前，先 ls -l 看时间戳，再 cat 读内容，最后 console.log(__filename) 验证执行路径，比反复重启容器快得多。
