不能在 dockerfile 中写 source venv/bin/activate，因为每条 run 指令启动独立 shell，source 仅当前 shell 生效，下一层即失效；误用会导致 pip 安装到全局而非虚拟环境，且语法错误、行为误导。
不用在容器里“激活”虚拟环境，直接用绝对路径调用 python 或 pip 就行；真正的污染风险来自构建阶段分层不当、未设非 root 用户、或误用 source 激活。
为什么不能在 Dockerfile 里写 source venv/bin/activate
Docker 的每条 RUN 指令都启动一个全新 shell，source 只在当前 shell 生效，下一层就失效了。写进去不仅没用，还会误导后续命令行为（比如你以为 pip install 装进了 venv，其实装到了系统 Python）。
- 常见错误现象：
RUN source venv/bin/activate && pip install flask→ 实际装到基础镜像的全局 site-packages - 正确做法：所有调用都走绝对路径，例如
/opt/venv/bin/pip install flask - 构建时无需“激活”，只要 PATH 或命令路径指向 venv 内二进制即可
python -m venv 是唯一推荐的创建方式
Python 3.3+ 自带 venv 模块，不需要额外装 virtualenv 包——那只会增大镜像体积、引入非标准行为。
Claw Code Suite (Python-Only Edition)
下载
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
- ✅ 正确：
RUN python -m venv /opt/venv - ❌ 不必要：
RUN pip install virtualenv && virtualenv /opt/venv - 注意：创建后默认 pip 版本旧，必须在同一
RUN层升级：RUN python -m venv /opt/venv && /opt/venv/bin/pip install --upgrade pip - 如果依赖编译（如
psycopg2），建议用多阶段构建，把gcc等工具留在 builder 阶段，不进入最终镜像
运行时让容器默认使用虚拟环境
关键不是“怎么激活”，而是“怎么让 python 命令自动指向 venv”。两种可靠方式：
- 用
ENV PATH="/opt/venv/bin:$PATH"—— 后续所有CMD或ENTRYPOINT中的python、pip都会优先取 venv 下的 - 或直接指定解释器路径：
CMD ["/opt/venv/bin/python", "app.py"]—— 更明确，避免任何 PATH 干扰 - ⚠️ 不要写
CMD ["source /opt/venv/bin/activate && python app.py"]：sh 不会执行 activate 后的命令链，且语法错误 - 记得加
USER appuser（非 root），否则即使用了 venv，root 权限仍可能写入系统路径或挂载卷
容易被忽略的细节：缓存、权限和 .dockerignore
这些点不显眼，但一出问题就难排查：
-
pip cache默认存在/root/.cache/pip，构建时若没清理，会悄悄增大镜像（尤其多阶段构建中 builder 阶段残留）；建议末尾加RUN /opt/venv/bin/pip cache purge -
venv目录权限需匹配运行用户，比如RUN chown -R appuser:appuser /opt/venv，否则非 root 用户运行时报PermissionError -
.dockerignore必须排除**/*venv和**/__pycache__，否则本地开发用的 venv 可能被 COPY 进镜像，覆盖构建生成的 -
PYTHONDONTWRITEBYTECODE=1和PYTHONUNBUFFERED=1应该始终设置，避免容器日志延迟或写入只读文件系统
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
