Docker镜像按层构建而非压缩包，基础镜像选错（如alpine与glibc不兼容）将导致运行失败；应避免latest标签，优先选用python:3.11-slim-bookworm等稳定镜像；COPY用于明确复制，ADD慎用以防隐式解压；RUN指令需合并清理操作以减小体积；敏感信息须通过--secret传递，配置通过envsubst动态生成；构建后必须验证。
Docker 镜像不是“打包压缩包”，而是按层构建的可复现快照；直接用 docker commit 生成的镜像几乎无法维护，也违背容器设计原则。
为什么 FROM 后面的镜像选错会导致后续全崩
基础镜像决定整个构建链的 ABI 兼容性、glibc 版本、可用包管理器和默认用户权限。比如用 alpine:latest 构建依赖 glibc 的 Python C 扩展（如 psycopg2），会报 ImportError: Error loading shared library libc.musl-x86_64.so.1；而用 debian:slim 又可能因体积大、源慢拖慢 CI。
- Web 服务优先考虑
python:3.11-slim-bookworm（Debian 稳定、glibc 兼容、apt 源快） - 静态二进制（Go/Rust）可用
scratch或alpine:3.20，但得确认是否调用系统 DNS 或 TLS 根证书 - 避免用
latest标签——它不固定，CI 中某天突然拉到新版基础镜像可能触发隐式 break
Dockerfile 中 COPY 和 ADD 的真实区别与误用场景
COPY 是明确的文件/目录复制，ADD 多了自动解压和远程 URL 下载能力，但这也正是坑点来源。
- 本地代码一律用
COPY . /app，别用ADD . /app——后者在遇到.tar.gz文件时会静默解压，破坏预期目录结构 -
ADD https://.../config.json /app/config.json看似方便，但构建缓存失效：URL 内容变，Docker 不感知，缓存仍命中，导致旧配置被复用 - 真正需要解压时（如预编译的 FFmpeg 二进制包），显式用
COPY ffmpeg.tar.gz /tmp/ && RUN tar -xzf /tmp/ffmpeg.tar.gz -C /usr/local，行为可控且可调试
RUN 指令合并与分层膨胀的取舍逻辑
Docker 镜像每条 RUN 指令都产生一层，层数越多，镜像越臃肿，推送/拉取越慢，且历史层中残留的临时文件（如 apt-get install 下载的 deb 包）不会被自动清理。
- 把安装、清理写在同一行：
RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/* - 不要拆成三行——中间层会保留
/var/lib/apt/lists/，哪怕下一层RUN rm也无法从最终镜像中删掉这部分体积 - 多阶段构建（
multi-stage build）更适合复杂场景：编译环境用golang:1.22，运行环境用alpine:3.20，只COPY --from=builder /app/binary /usr/local/bin/app
构建时如何让敏感信息不进镜像也不硬编码
密码、API Key、私钥绝不能出现在 RUN 命令或 COPY 进来的配置文件里——它们会留在某一层中，docker history 一眼可见。
- 用
--secret传密钥：docker build --secret id=aws,src=./aws-cred.txt .，再在 Dockerfile 中用RUN --mount=type=secret,id=aws cat /run/secrets/aws -
环境变量靠
docker run -e DB_PASSWORD=xxx注入，但注意：进程内泄露风险仍在，生产建议用docker run --env-file或外部 secrets manager - 配置文件用模板 + 启动脚本生成：COPY
config.tmpl，启动时用envsubst /app/config.yaml，模板里写DB_HOST=${DB_HOST}
最常被跳过的一步是验证：构建完立刻 docker run --rm -it your-image sh -c 'ls -l /app && python -c "import requests; print(requests.__version__)"'。没这步，你永远不知道 COPY 是否漏了子目录，或 pip install 是否因网络问题静默失败。
