pycharm 配置 docker 运行环境的核心是启用 docker 插件并使用“on docker”解释器类型，而非手动执行 docker run 或 ssh；需确认插件已启用、docker 守护进程连接正常、python 路径准确（如 python:3.9-slim 对应 /usr/bin/python3）、端口映射手动配置，且所有运行时修改不持久——必须通过自定义镜像或解释器环境变量实现持久化。
PyCharm 配置 Docker 容器运行环境，核心是用 Docker 插件 + On Docker 解释器类型，而不是手动 SSH 连容器或自己跑 docker run 命令 —— 后者无法触发 PyCharm 的调试、代码补全、包管理等关键功能。
确认 Docker 插件已启用且连接正常
PyCharm 默认捆绑 Docker 插件，但可能被禁用或连接失败。这不是“装了 Docker Desktop 就自动好”的事。
- 按
Ctrl+Alt+S（Windows/Linux）或Cmd+,（macOS）打开设置，进入Plugins→ 已安装，确认Docker插件已勾选 - 回到设置 →
Build, Execution, Deployment→Docker，检查Docker Engine连接方式：macOS/Windows 选Docker for Mac或Docker for Windows；Linux 选TCP socket并填tcp://localhost:2375（需 Docker daemon 开启 TCP） - 右下角状态栏应显示
Docker connected；若显示Disconnected，点它会弹出错误详情（常见如权限不足、Docker 服务未运行、WSL2 网络未桥接）
配置 On Docker 解释器时指定 Python 路径要精准
PyCharm 不会自动猜容器里 Python 在哪。填错路径会导致解释器加载失败，报错 Python interpreter not found 或直接卡在 “Connecting…”。
- 镜像为
python:3.9-slim时，Python 路径是/usr/bin/python3（不是/usr/local/bin/python） - 镜像为
continuumio/miniconda3时，基础环境路径是/opt/conda/bin/python；若创建了名为myenv的 conda 环境，则必须填/opt/conda/envs/myenv/bin/python - 不确定路径？先
docker run -it python:3.9-slim which python3或进容器执行which python确认 - PyCharm 会在后台自动挂载项目目录到容器的临时路径（如
/project），但不会帮你改PYTHONPATH—— 如果代码依赖特定路径，得在容器内设环境变量或改sys.path
容器启动后无法访问 localhost:端口？检查端口映射是否生效
PyCharm 的 On Docker 解释器本身不暴露端口，但你写 Web 服务或调试时需要访问容器服务（比如 Flask 的 5000 端口），这时得手动加端口映射。
- 在
Add Python Interpreter→On Docker页面，不要只填镜像名，点击…展开高级设置 →Container settings→Ports - 添加映射：
Host port填5000，Container port填5000，协议选TCP - 注意：PyCharm 启动容器时默认不加
-d（后台模式），所以你看到容器在Services工具窗口里是running状态，但一旦关闭 PyCharm，容器会被自动清理 —— 这是设计行为，不是 bug - 如果要用
docker ps查看该容器，得在 PyCharm 的Services窗口右键容器 →Open in Terminal，再执行命令，否则容器名是随机生成的，不好定位
为什么改了容器里的环境变量 / 安装了新包，下次运行就没了？
PyCharm 每次通过 On Docker 解释器运行时，都是基于镜像新建容器，而非复用旧容器。所有运行时修改（pip install、export VAR=xxx）都不会持久化。
- 想让包长期存在？要么用自定义
Dockerfile构建新镜像（推荐），要么在解释器配置页勾选Use container from image并指定一个已预装好依赖的镜像 - 想让环境变量生效？在解释器配置页的
Environment variables区域添加，比如PATH=/opt/conda/bin:$PATH，PyCharm 会把它传给容器启动命令 - 别在容器里手动改
/etc/profile或.bashrc—— PyCharm 启动容器用的是docker run --entrypoint直接调 Python，不走 shell 初始化流程
真正麻烦的不是配通，而是理解 PyCharm 的容器生命周期：它不管理你的容器，只按需拉起一个干净实例。所有“我想保留这个状态”的诉求，都得退回到镜像层解决。
