不能直接在宿主机装依赖而要进容器开发，因为环境一致性是核心诉求，需确保开发与生产环境的node版本、pip路径、glibc等完全一致。

为什么不能直接在宿主机装依赖，而要进容器开发

因为环境一致性是核心诉求。本地装的 node 版本、pip 包路径、甚至 glibc 小版本，都可能和生产镜像不一致。Docker 容器内开发不是为了炫技，而是让「写代码时的环境」和「上线跑的环境」完全对齐——比如你用 python:3.11-slim 镜像，那开发时就该在这个镜像里装 black、跑 pytest、连容器内的 redis，而不是靠本地 redis-cli 去连容器端口。

用 Remote-Containers 扩展打开项目目录后没反应

常见原因是工作区根目录下缺少 .devcontainer/devcontainer.json，VSCode 不会自动猜测你要进哪个容器。必须手动创建这个文件，并明确指定镜像或 Dockerfile：

Docker Container Cleaner

CLI工具，用于清理已停止的Docker容器、未使用的镜像、卷和网络，释放磁盘空间。

下载

• 最简配置：指定基础镜像，如 "image": "mcr.microsoft.com/devcontainers/python:3.11"
• 若已有 Dockerfile，改用 "dockerFile": "Dockerfile.dev"（路径需相对于工作区）
• 务必检查 docker CLI 是否可用：docker version 能正常返回，否则扩展会静默失败
• Windows 用户注意：WSL2 后端必须启用，且 Docker Desktop 设置中要勾选 “Use the WSL 2 based engine”

容器启动后 Python 解释器找不到，或者 pip install 失败

这是路径和权限的典型错配。Remote-Containers 默认把项目挂载到 /workspaces/your-project，但很多镜像的 PYTHONPATH 或 pip 默认不认这个路径：

• 在 devcontainer.json 中加 "customizations": { "vscode": { "settings": { "python.defaultInterpreterPath": "/usr/local/bin/python" } } }
• 如果要用虚拟环境，别在宿主机建 venv，而是在容器内运行 python -m venv /workspace/.venv，然后在设置里指向它
• pip install 报权限错误？不是加 sudo，而是改 devcontainer.json 的 "remoteUser": "root"（仅开发用），或更稳妥地用 "features" 安装包（如 "ghcr.io/devcontainers/features/python:1"）

调试 Flask/FastAPI 时断点不命中，或热重载失效

根本原因在于容器默认没有暴露调试端口，且进程没以调试模式启动。VSCode 的调试器需要双向通信，不是简单跑个 python app.py 就行：

• 确保 devcontainer.json 有端口转发："forwardPorts": [5000, 8000]，否则浏览器打不开 localhost:5000
• 启动命令得带调试参数，例如 FastAPI：用 uvicorn main:app --reload --host 0.0.0.0:8000，其中 --host 0.0.0.0 是关键，不然只监听 localhost（容器内 loopback）
• VSCode 调试配置（.vscode/launch.json）里 "justMyCode": false 可能导致跳过断点，建议设为 true 并确认源码路径映射正确（"pathMappings"）

容器内开发真正卡住人的地方，往往不是“怎么连进去”，而是“进去之后，哪些路径、端口、用户权限、网络模式是默认关闭或隔离的”。这些细节不会报红错，只会让你觉得“代码没变，但就是不生效”。