docker构建失败、体积大等问题根源在于dockerfile写法与构建上下文不当：基础镜像不匹配包管理器、缓存滥用、copy顺序错误、缺少.dockerignore、未清理构建产物、多阶段构建缺失及基础镜像选型错误。
直接用 docker build 就能构建，但镜像构建失败、体积爆炸、本地能跑线上挂——这些问题几乎都出在 Dockerfile 写法和构建上下文上，而不是命令本身。
为什么 docker build 总是卡在 RUN pip install 或 apt-get update
常见现象是：命令执行超时、包找不到、依赖冲突，或者报错类似 Could not find a version that satisfies the requirement xxx。根本原因往往不是网络差，而是构建环境和本地开发环境不一致。
- 基础镜像里没有对应源（比如用
alpine却写apt-get） -
requirements.txt锁了已下架的老版本包，本地有缓存所以能装，Docker 构建是干净环境，拉不到就直接失败 - 没加
--no-cache时复用了过期的缓存层，导致后续 RUN 指令基于错误状态执行 - 构建上下文太大（比如把
node_modules或.git目录一起传进去了），拖慢传输，甚至触发 daemon 超时
建议先运行 docker build --no-cache -t myapp . 排除缓存干扰；再检查 FROM 镜像是否匹配包管理器，比如 alpine 用 apk add，debian 用 apt-get。
COPY 和 ADD 到底该用哪个？顺序为什么影响构建速度
COPY 是明确、可控的文件复制；ADD 多了自动解压、拉取 URL 等隐式行为，容易引入意外副作用。绝大多数场景只用 COPY 就够了。
- 把
COPY . /app放太前面，会导致每次改任意一个文件（比如 README.md），整个依赖安装层都失效，必须重跑RUN pip install - 正确顺序是：先
COPY requirements.txt /app/→RUN pip install -r requirements.txt→ 再COPY . /app。这样只要requirements.txt不变，pip 安装层就能复用 - 务必配
.dockerignore，过滤掉__pycache__、*.log、.git、venv等无用文件，否则它们会被打包进构建上下文，增大传输开销
构建出来的镜像为什么动辄 1.2GB？怎么瘦下来
体积大不是因为代码多，而是中间层残留了编译工具、缓存、文档、调试符号等构建期产物。Docker 默认不会清理这些。
- 别在同一个
RUN层里分开写apt-get update和apt-get install，否则前者的层里会残留/var/lib/apt/lists/，后者无法删掉它——要合并成一条：RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/* - Python 项目优先用
slim或alpine基础镜像，比如python:3.10-slim比python:3.10小一半以上 - 真正有效的瘦身手段是多阶段构建：第一阶段用完整镜像编译/构建，第二阶段只
COPY最终二进制或 dist 包到轻量镜像中，彻底丢弃构建工具链
多阶段构建不是“高级技巧”，而是生产环境的标配。比如前端项目用 node:18 构建，最后只把 dist/ 复制到 nginx:alpine 里，镜像能从 1.1GB 压到 20MB。
FROM 选错基础镜像会引发哪些连锁问题
基础镜像是所有层的起点，选错会传导到依赖安装、权限控制、glibc 兼容性、甚至容器启动失败。
- 用
alpine运行 glibc 编译的二进制（比如某些预编译的 Python C 扩展），会报No such file or directory——因为 alpine 用的是 musl libc - 用
scratch启动 Python 应用？直接exec format error，因为scratch里连/bin/sh都没有，更别说解释器 -
debian镜像默认以root用户运行，但生产要求非 root；而python:slim通常不带useradd命令，RUN useradd可能失败 - 官方镜像标签要带具体版本，比如
python:3.10-slim，避免用latest导致某天构建突然失败（上游镜像更新后行为变更）
最稳妥的做法：先确认应用运行时真正需要什么（Python 解释器？C 库？字体？时区数据？），再反向选镜像。别为了“小”硬上 alpine，兼容性问题比体积更难 debug。
