Dockerfile 中 COPY 放太前会导致镜像变大，因缓存失效使后续所有层（如 pip install）被迫重建；应先单独 COPY requirements.txt 再安装依赖，再 COPY 源码，并用 .dockerignore 排除无用文件。
为什么 Dockerfile 里 COPY 放太前会让镜像变大
因为 Docker 镜像层是按指令顺序缓存的，一旦某层内容变化（比如源码更新），它和之后所有层都会失效重构建。Python 项目通常先 COPY requirements.txt，再 RUN pip install，但如果把整个 src/ 目录提前 COPY 进去，哪怕只改了一个 .py 文件，pip install 这一层就再也无法复用——缓存断了，依赖得重装，耗时又臃肿。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 严格分离「不变」和「常变」内容：把
requirements.txt单独COPY，立刻RUN pip install，再COPY . /app - 用
--no-cache-dir和--upgrade-strategy only-if-needed减少 pip 自身缓存干扰层哈希 - 避免
COPY . .，改用.dockerignore排除__pycache__、.git、venv等无用文件，否则它们会悄悄塞进每一层
pip install --user 和系统级安装对分层的影响
在容器里用 --user 安装包，实际是把文件写进 /root/.local/（或 /home/$USER/.local），这个路径不在系统默认 PYTHONPATH 里，运行时容易报 ModuleNotFoundError；更重要的是，它绕过了镜像层的“显式意图”——你本想把依赖固化在镜像里，结果却藏进了用户目录，既难调试，又破坏层语义。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 一律用
RUN pip install --no-cache-dir -r requirements.txt，不加--user - 确认基础镜像的
PYTHONPATH和PATH是否包含/usr/local/lib/python3.x/site-packages（标准位置），这是多层复用的前提 - 如果必须用非 root 用户运行，用
USER指令切换后，仍应在pip install前用ENV PYTHONUNBUFFERED=1和ENV PATH="/home/app/.local/bin:$PATH"显式补全路径
多阶段构建中 python:slim 和 python:alpine 的取舍
alpine 镜像小，但 Python 扩展模块（如 psycopg2、cryptography）常需编译，而 Alpine 默认没 glibc，得换 musl 兼容版，装起来慢、易失败；slim 是 Debian 衍生，兼容性好，体积比 full 小 60%，且预装了 gcc 和 libc6-dev，适合大多数纯 Python 项目。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 优先选
python:3.11-slim-bookworm（Debian 12），不是slim-bullseye——后者已停止安全更新 - 若真要用 Alpine，别直接
pip install编译型包，改用apk add py3-psycopg2等预编译包，或切回多阶段：build 阶段用python:3.11，final 阶段用python:3.11-slim - 注意
slim镜像不含curl、vim，调试时别指望apt-get install，该用docker run -it --rm python:3.11-slim bash临时验证
用 pip-tools 锁定依赖对层稳定性的帮助
直接写 requirements.txt 用 == 锁版本看似稳妥，但漏掉间接依赖，不同机器上 pip install 可能因解析策略差异生成不同二进制包（比如 setuptools 版本波动导致 wheel 编译结果不同），最终让镜像层哈希不一致。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
pip-compile requirements.in生成带完整哈希的requirements.txt，确保每行末尾有# via xxx和--hash=sha256:... - 在
Dockerfile中COPY requirements.txt后加RUN pip install --no-cache-dir --require-hashes -r requirements.txt，强制校验哈希，避免网络污染或中间人篡改 - 别把
pip-tools装进生产镜像——它只在构建机上用，build 阶段装，final 阶段不 COPY 它的二进制
分层优化不是压缩游戏，而是让每一层表达一个清晰、稳定、可验证的意图。最容易被忽略的，是开发时本地 pip install -e . 和镜像里 pip install -r 的行为差异——前者绕过 wheel 构建，后者触发完整打包流程，连 pyproject.toml 里 build-system 的细微配置都可能让层哈希突变。
