Node环境Remote Containers挂载失败主因是UID/GID不匹配、consistency策略缺失及监听地址错误；需在devcontainer.json中配置consistency参数、确保remoteUser与宿主机UID一致，并将Node服务绑定0.0.0.0而非127.0.0.1。
Node环境在 Remote Containers 中挂载失败，99% 是因为容器用户 UID/GID 与宿主机目录权限不匹配，而不是路径写错或 Docker 没启动。
devcontainer.json 中 mounts 配置必须显式声明 consistency
macOS 和 WSL2 下，${localWorkspaceFolder} 默认挂载行为会触发文件系统一致性策略冲突，导致 Node 进程读取 package.json 或写入 node_modules 时静默失败（无报错，但 npm install 卡住、require() 找不到模块）。
-
mounts字段必须包含consistency参数：推荐设为"cached"（macOS）或"delegated"（WSL2/Linux） - 错误示例：
"source": "${localWorkspaceFolder}", "target": "/workspace"—— 缺少consistency和type - 正确写法：
"source": "${localWorkspaceFolder}", "target": "/workspace", "type": "bind", "consistency": "cached" - 若使用 Docker Desktop for Mac，不加
consistency会导致fs.watch()失效，热重载（如 nodemon）完全不触发
remoteUser 必须与 Dockerfile 中创建的用户 UID 一致
VSCode 默认以 root 启动容器，但 Node 应用不该用 root 运行；若你在 Dockerfile 中用 useradd -u 1001 node 创建用户，却在 devcontainer.json 里写 "remoteUser": "node"，而宿主机当前目录属主是 UID 501（macOS 默认），就会出现 Permission denied 写入 node_modules。
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- 运行
id -u查看宿主机当前用户 UID，Dockerfile 中useradd的-u值必须与之相同 - 或者反向操作：在
devcontainer.json中设"remoteUser": "root"，并在Dockerfile中保留USER root（仅用于调试，非生产） - 检查挂载目录权限：
ls -ld .输出中第三列应为当前 UID，否则chmod -R u+rw .不够，需sudo chown -R $(id -u):$(id -g) .
Node.js 启动命令绑定地址必须是 0.0.0.0 而非 127.0.0.1
挂载失败常被误判，实际是后续调试或服务访问失败——比如 npm start 启动 Express，但浏览器打不开 localhost:3000，日志却显示 “Listening on http://127.0.0.1:3000”。这不是挂载问题，但开发者常把它和挂载失败混为一谈。
- Node.js 进程默认只监听
127.0.0.1，容器内网络栈无法被 VSCode 主机端访问 - 必须改代码：
app.listen(3000, '0.0.0.0')或通过环境变量控制：HOST=0.0.0.0 npm start - 对应地，
devcontainer.json中"forwardPorts": [3000]才能生效；否则端口转发成功，但服务根本没对外暴露 - 验证命令：
docker exec -it <container> ss -tuln | grep ':3000'，输出中应含0.0.0.0:3000，而非127.0.0.1:3000
真正卡住的从来不是配置语法，而是 UID 映射、consistency 策略、以及监听地址这三处看不见的权限链。改完之后记得彻底删掉旧容器：docker rm -f $(docker ps -aq)，否则挂载缓存可能延续旧状态。
