VSCode 默认不识别 Podman 或 Rancher Desktop 的 socket，Dev Containers 扩展仅探测 /var/run/docker.sock，不会自动 fallback 或检测其真实 socket 路径（如 Linux 的 /run/user/1000/podman/podman.sock 或 macOS/Rancher Desktop 的 $HOME/.podman/machine/qemu/podman.sock），导致“Cannot connect to the Docker daemon”报错、容器启动失败、端口映射不生效；绕过方式是手动配置 remote.containers.dockerSocketPath 指向正确 socket，并在 devcontainer.json 中同时设置 forwardPorts 和 runArgs（如 ["--publish=3000:3000"]）以确保端口真正暴露，还需校准 remoteRoot 与 sourceFileMap 解决路径映射错位问题。
直接说结论：VSCode 默认不识别 Podman 或 Rancher Desktop 的 socket，Dev Containers 扩展会 fallback 到 Docker Desktop 检测逻辑，导致容器启动失败或端口映射不生效。绕过方式不是“换工具”，而是手动接管 socket 连接与端口转发链路。
确认 Podman socket 是否被 VSCode 识别
VSCode 的 Remote-Containers 扩展默认只检查 /var/run/docker.sock，Podman 的 socket 路径是 /run/user/1000/podman/podman.sock（Linux）或 $HOME/.podman/machine/qemu/podman.sock（macOS，Rancher Desktop 默认路径）。扩展不会自动探测后者。
- 打开命令面板（
Ctrl+Shift+P），运行Dev Containers: Show Container Logs—— 如果日志里出现Cannot connect to the Docker daemon，基本就是 socket 路径未命中 - 终端执行
podman info --format '{{.Host.ContainersStorage}}'确认 Podman 正常运行；再查ls -l $HOME/.podman/machine/qemu/podman.sock（macOS）或ls -l /run/user/$(id -u)/podman/podman.sock（Linux）验证 socket 存在 - 别信
docker info成功就等于 OK —— Rancher Desktop 可能启用了 Docker 兼容层，但底层仍是 Podman，此时docker命令只是代理，Dev Containers仍可能因权限或上下文错乱而无法挂载调试端口
devcontainer.json 中必须显式配置 forwardPorts + runArgs
forwardPorts 在 Podman 环境下仅触发 VSCode 端口转发 UI，**不等价于 -p 映射**。若服务需被本地 curl、Postman 或其他进程访问（不只是浏览器），必须补 runArgs 做底层绑定。
-
"forwardPorts": [3000, 9229]—— 让 VSCode 状态栏显示并允许点击打开localhost:3000，但仅限隧道内流量 -
"runArgs": ["--publish=3000:3000", "--publish=9229:9229"]—— 这才是让 Podman 实际暴露端口的关键，缺了它，localhost:3000在浏览器里也打不开（除非服务监听0.0.0.0且你手动podman port查到宿主机映射） - Rancher Desktop 用户注意：
--publish在其默认 VM 模式下有效；若启用了 “Use the command line tools from Windows”（WSL2 backend），则runArgs需改为["-p", "3000:3000", "-p", "9229:9229"]，因为底层调用的是 WSL2 的podmanCLI，参数风格更接近 Docker
Node.js 调试端口必须监听 0.0.0.0:9229，且 launch.json 的 port 对应宿主机端口
常见错误是 Node 进程监听 127.0.0.1:9229，即使 runArgs 正确映射，VSCode attach 也会超时 —— 因为容器内 localhost ≠ 宿主机 localhost，隧道走的是 Podman 主机网络命名空间。
- 启动命令必须含
--inspect=0.0.0.0:9229，例如CMD ["node", "--inspect=0.0.0.0:9229", "server.js"] -
.vscode/launch.json中的"port"字段填的是**宿主机上暴露的端口**（即runArgs里右边那个数字），不是容器内端口：{ "name": "Attach to Node", "type": "node", "request": "attach", "port": 9229, "address": "localhost", "localRoot": "${workspaceFolder}", "remoteRoot": "/workspace" } - 如果用了非标准端口（比如
--inspect=0.0.0.0:9230），runArgs和launch.json必须严格一致，差一位都会连接失败
调试断点不命中？重点检查 remoteRoot 和 sourceFileMap
Podman 容器默认挂载路径和 Docker 不同：Docker Desktop 默认把项目挂到 /workspace，而 Podman（尤其 Rancher Desktop 的 WSL2 模式）常挂到 /workspaces/your-project-name 或 /home/username/project。VSCode 断点依赖路径 1:1 映射，错一个层级就失效。
- 进容器执行
pwd和ls -la，确认代码实际所在路径（比如/workspaces/myapp） - 在
launch.json中硬编码"remoteRoot": "/workspaces/myapp"，别信${workspaceFolder}自动推导 - 如仍有问题，加
"sourceFileMap": { "/workspaces/myapp": "${workspaceFolder}" }显式声明映射关系 - 特别注意：Rancher Desktop 启用 “Open in WSL” 选项后，
remoteRoot很可能是/home/username/myapp，而非/workspaces/...—— 这个细节几乎没人提，但踩中必跪
真正麻烦的从来不是“怎么配”，而是 Podman/Rancher Desktop 的路径、socket、网络命名空间三者之间存在隐性耦合，任何一个环节没对齐，端口就卡死。建议每次改完配置后，先 podman ps 看容器是否真在运行，再 podman exec -it <cid> netstat -tuln | grep 9229 确认监听地址，最后才切回 VSCode 点 F5。
