应显式指定Python小版本镜像如python:3.11-slim-bookworm，避免使用python:latest或python:3.11；requirements.txt须带版本号和哈希校验，用pip-tools生成；Dockerfile中先COPY requirements.txt再RUN pip install；务必配置.dockeringore排除无关文件。
直接用 python:3.9-slim-buster 这类官方镜像 + requirements.txt 安装依赖，是最稳妥、最易维护的方式；硬编码 Python 版本、跳过依赖锁定、或在运行时动态安装包，都会让环境变得不可控。
为什么不能直接用 python:latest？
python:latest 指向的版本会随时间漂移，今天构建的镜像明天可能拉不到相同内容。CI/CD 流水线里一旦缓存失效或镜像被覆盖，pip install 可能装上不兼容的新版包，导致应用启动失败或行为异常。
应该显式指定小版本号，例如：python:3.11-slim-bookworm —— 这样基础镜像的 OS 和 Python 解释器都固定，后续所有构建可复现。
- 避免使用
python:3.11（只锁主次版本，补丁版仍可能变） - 不要用
python:alpine除非你确认所有 C 扩展（如numpy、psycopg2）都能顺利编译 - Debian slim 镜像（如
-slim-buster或-slim-bookworm）比 Alpine 更兼容，调试也更方便
requirements.txt 必须带版本号，且建议用 pip-tools 生成
只写 flask 不写 flask==2.3.3，等于把依赖解析权交给了 pip，而 pip 的解析策略在不同版本间有变化。生产环境必须锁定全部依赖版本。
立即学习“Python免费学习笔记（深入）”；
推荐用 pip-compile（来自 pip-tools）从 requirements.in 生成带哈希的 requirements.txt：
pip install pip-tools echo "flask>=2.0" > requirements.in pip-compile --generate-hashes requirements.in
生成的 requirements.txt 包含每行的 --hash 校验，Docker 构建时 pip install -r 会校验下载包完整性，防止中间人篡改。
Dockerfile 中 COPY 和 RUN 的顺序不能错
Docker 层缓存非常敏感。如果把 COPY . . 放在 RUN pip install 前面，只要代码任意文件变动，pip 安装这层就完全失效，每次都要重装所有依赖——构建慢、镜像大、CI 耗时飙升。
正确顺序是：
COPY requirements.txt .RUN pip install --no-cache-dir -r requirements.txtCOPY . .
这样只要 requirements.txt 不变，pip 安装层就能复用，哪怕你改了 100 行代码，构建也只花几秒。
别忽略 .dockerignore 文件
没这个文件，docker build 会把整个上下文（包括 __pycache__、.git、venv/、大型数据文件）打包传给 Docker daemon，不仅拖慢构建，还可能意外把敏感配置或大文件塞进镜像层。
一个最小可用的 .dockerignore 应该包含：
.git __pycache__ *.pyc *.pyo *.pyd .Python env/ venv/ .venv/ pip-log.txt .hg .svn CVS .dockerignore .gitignore README.md requirements.in
注意：它不支持通配符递归匹配（如 **/__pycache__），每行写死路径最可靠。
最常被忽略的一点是：即使你用了多阶段构建、slim 镜像、哈希校验，只要 requirements.txt 里有一行是 git+https://... 或 -e ./some-local-package，构建就可能因网络波动或本地路径缺失而失败——这类依赖必须提前 vendor 到镜像上下文中，或改用发布到 PyPI 的稳定版本。
