想象你是一位刚进后厨的 AI 工程师，大厨老周递给你一个真空料理包：“这是我们店的招牌红烧肉——算法、依赖、运行环境全都封装好了，无论在哪家分店，撕开加热就是同一道菜。”你问：“那容器呢？”老周掀开锅盖：“这就是容器——料理包按标准做法加热，实实在在端上桌的那盘菜。”Docker 镜像正是这个“标准料理包”，而 Dockerfile 就是它的菜谱：原料清单、处理步骤、上桌要求，一应俱全。本文用一道道“做菜”的故事，带你走完镜像构建的完整链路：从写菜谱（编写 Dockerfile）、理解分层封装（镜像层原理），到巧用冰箱存货（构建缓存）、给料理包瘦身（多阶段构建），再到适配不同灶台（多架构构建）、把控食材安全（构建安全），最后让后厨流水线并行高效运转（性能调优）。读完后，你就能亲手做出一份“干净、轻量、可复现”的标准镜像。
镜像构建是容器化部署的地基。掌握 Dockerfile 编写与层、缓存、瘦身、安全等方法，你就能在 AI 工程化中高效交付可移植、可复现的部署产物，成为团队里最会“做菜”的人。
可视化演示
本节配有交互动效（进入视口后自动加载，约 3KB）。
镜像基础概念
小红第一天到后厨当帮厨，大厨老周递给她一个真空包装袋：“这是我们店的招牌红烧肉料理包。算法、依赖、环境全封在里面，不管在总店还是分店，撕开加热都是同一道菜。”小红追问：“那容器呢？”老周掀开锅盖：“这就是容器——料理包按标准做法实时加热，实实在在端上桌的那盘菜。”这个比喻直接点出 Docker 最核心的一对概念：镜像（Image）是静态的模板，容器（Container）是模板创建的运行实例。镜像可以无限复制、分发、保存，容器则是它的一次“开火”。
从技术上看，镜像不是一个单一的大文件，而是由多层只读文件系统组成的“千层蛋糕”。执行 docker images 看到的总大小，是所有层大小按展开方式求和的结果。镜像存放在镜像仓库（Registry）中，通过“仓库名：标签（tag）”来定位版本，比如 python:3.10-slim、registry.cn-hangzhou.aliyuncs.com/ai/base:1.2。Docker 会为每一层计算内容寻址的 ID，相同内容的层在不同镜像之间可以复用，这也是后续一切优化和共享的基础。
理解镜像与容器的关系后，后面所有构建技巧都围绕一个目标：把“料理包”做得又小、又快、又稳。就像老周常说的：“料理包做得好，分店才能开得远。”镜像的质量，直接决定了应用能否在任意环境里可靠、高效地跑起来。
- 镜像层$L_i$ 代表第 $i$ 层文件系统快照，每一层只保存与上一层的差异。类似菜谱中“焯好水的五花肉”是独立存在的半成品，不是整锅汤重新熬。
- 层序号$i$ 从 1 到 $n$，$n$ 是镜像的总层数。层数由 Dockerfile 中改变文件系统的指令条数决定，指令越多层越多。
- 求和运算$\sum$ 表示把每一层的大小累加起来，得到镜像按层展开的理论总大小。如果两个镜像共享了中间层，实际存储时这一层只算一次。
Dockerfile基础
老周递给小红一张塑封卡片：“这是红烧肉的菜谱。FROM 写'用什么底汤'，RUN 写'每步怎么烧'，COPY 写'从备菜筐里取什么料'，CMD 写'上桌前最后撒什么葱花'。照这个菜谱做，谁出锅都是同一个味儿。”Dockerfile 就是构建镜像的“自动化菜谱”：它是一份纯文本，逐行声明“在这一步之后，文件系统应该变成什么样”，Docker 引擎照着它一步步执行，最终产出一个镜像。
Dockerfile 的核心指令并不多。FROM 指定基础镜像，相当于“选用哪锅底汤”；RUN 执行命令并提交新的层，相当于“翻炒、炖煮”；COPY 和 ADD 把构建上下文里的文件拷进镜像，相当于“从备菜筐取料入锅”；ENV 设置环境变量；WORKDIR 切换工作目录；EXPOSE 声明容器要监听的端口；CMD 与 ENTRYPOINT 定义容器启动后运行什么命令。构建时，执行 docker build -t myapp:1.0 .，最后的 . 表示构建上下文——Docker 会把当前目录（以及子目录）打包发给构建引擎。上下文里的文件才能被 COPY 使用；而 .dockerignore 则像厨房门口的“禁入清单”，告诉 Docker 哪些垃圾文件（.git、.venv、数据集）不必带进来。
写菜谱要讲究“先备料、后下锅”，写 Dockerfile 也一样。把变化慢的步骤放在前面（基础镜像、依赖安装），变化快的放在后面（业务代码），构建时才能最大化利用缓存。这个“顺序即性能”的思想，是入门 Dockerfile 后要记住的第一条实战心法。
- 新层$L_i$ 表示执行第 $i$ 条指令后产生的新镜像层，是文件系统的一次增量快照。
- 转换函数$f$ 是 Docker 执行指令的确定性过程。给定当前文件系统状态和指令内容，结果永远一致——就像同一道菜谱，同一批食材，出锅口味相同。
- 前序状态$状态_{i-1}$ 代表执行前一条指令后的文件系统状态。它是产生新层的基础，所以 Dockerfile 的指令顺序会直接影响最终镜像的结构。
镜像分层原理
老周从冰箱里拿出一块千层蛋糕：“你看，底层是高汤冻做的蛋糕底，中间是调料层，最上面是肉块层。A 店和 B 店都从同一锅高汤出发，只是各自铺了不同的调料——底下那层高汤冻，两家店就共用同一块。”Docker 镜像的分层（Layer）正是这个结构：每条会改变文件系统的指令（RUN、COPY、ADD）都会生成一个新层，新层叠在旧层之上，构成一个只读的层堆叠。层与层之间是差分关系，上一层只记录“比下一层多了什么、改了哪些文件”。
容器运行时，Docker 会在这些只读层之上叠一个可写的容器层。进程的读操作会自顶向下查找文件，写操作则发生在最顶层的可写层中，底下的镜像层永远不被改动——这就是写时复制（Copy-on-Write）。多个容器从同一个镜像启动时，共享全部只读层，只在各自的容器层记录差异。因此，在宿主机上从同一个镜像启动 100 个容器，并不会占用 100 份镜像空间，这也是容器比虚拟机轻量的根本原因之一。
镜像层共享不仅省存储，还直接带来“拉取加速”：新机器部署时，只要本地已有相同的基础层，就只需要下载差异层。就像老周的分店开张，高汤冻直接从总店冷链调拨，每家分店只需准备自己特有的调料和肉块。
- 共享层大小$S_{共享}$ 是被多个镜像共同引用的层的大小总和。比如两个镜像都基于
python:3.10-slim，这层底汤就算共享层。 - 去重后总存储$S_{去重总存储}$ 是仓库服务器实际落盘的层大小之和。共享层无论被多少镜像引用，只物理存放一份。
- 复用率$\eta_{复用}$ 表示共享层占实际存储的比例。这个值越高，说明团队的基础镜像选型和分层设计越好，存储与带宽越省。
构建缓存优化
老周的厨房里有一台大冰箱，码着一盒盒半成品：焯好水的五花肉、调好的料汁、切好的姜葱。做菜前他会先翻冰箱：“这盒焯肉还在，标签跟菜谱对得上，直接拿出来用，不用重新起锅焯水。”Docker 构建时也有这台“冰箱”——构建缓存。每执行一条指令前，Docker 会计算一个缓存键，如果缓存里已有相同键的结果，就直接复用，跳过执行，构建时间从“分钟级”降到“秒级”。
缓存键由三部分构成：父层 ID、指令内容、以及指令涉及文件的校验和。COPY 和 ADD 指令尤其敏感：只要被复制的文件内容有任何字节变化，这一层以及它之后的所有层缓存全部失效。这解释了为什么在实践中要把 requirements.txt 先复制进去并执行 RUN pip install -r requirements.txt，再复制业务代码——依赖文件变化频率低，放前面能稳定命中缓存；代码变化频繁，放后面就算缓存失效，重建的成本也小得多。docker build --no-cache 可以强制无视缓存全量重建，适合需要严格可复现的发布场景。
这就像老周的小贴士：“费功夫的步骤提前做成半成品冻起来，客人点单再烧，五分钟上菜。”Dockerfile 的指令排序就是后厨的“预制菜哲学”——把昂贵的工作沉淀为缓存层，让每一次构建都站在上一次的肩上。
- 总耗时$T_{构建}$ 是一次镜像构建从开始到结束的总时间，是 CI 流水线里最直观的性能指标。
- 缓存命中耗时$T_{命中}$ 是复用已有缓存层所花的时间。命中层不需要真正执行指令，只需下载/引用已有层，通常只有秒级甚至毫秒级。
- 重新构建耗时$T_{重建}$ 是未命中层真正执行指令的时间，往往包含
pip install、apt install、代码编译等大头开销。所以减少重建层数、把重建层范围控制在最小，是优化构建时间的核心思路。
镜像瘦身策略
小红拎着大包小包来出摊，老周哭笑不得：“你是来出摊，不是搬家！菜刀、砧板、炒锅、蒸锅全带上干嘛？就带一把刀一口锅，一样出菜。”镜像瘦身的精髓就是这句：把“备菜的大厨房”和“上菜的出餐台”分开。多阶段构建（Multi-stage Build）允许在一个 Dockerfile 里写多个 FROM：第一阶段使用“大而全”的环境完成编译、安装依赖；第二阶段只把产物复制到一个“小而净”的镜像里，脏活累活全留在第一阶段。
以 Python 服务为例：第一阶段基于 python:3.10-slim，执行 pip install 安装依赖、编译扩展模块；第二阶段从第一阶段 COPY --from=0 /usr/local/lib/python3.10/site-packages 和业务代码过来，基础镜像换成更小的 python:3.10-slim，但不带 gcc、build-essential 等编译工具。除了多阶段构建，瘦身还可以组合多种手段：选择 Alpine 等精简基础镜像（注意 musl 兼容性问题）、合并 RUN 并用 && 串联后清理 apt/pip 缓存、删除临时文件、把大模型权重等静态资源用单独层挂载而不是打进镜像。
吃完这顿饭，小红终于明白：出摊带一口锅就够了。多阶段构建就是后厨的“出餐台思维”——备菜区的油污和脏砧板永远留在后厨，端到客人面前的只有干净、够用的成品。镜像瘦身不仅省存储和带宽，还减少了攻击面：不留编译器、不留调试器，黑客进了容器也无从下手。
- 原始大小$S_{原始}$ 是优化前镜像的总大小，通常包含编译工具链、缓存文件、中间产物等冗余。
- 优化后大小$S_{优化}$ 是同一应用经过瘦身后的镜像大小。多阶段构建后只保留运行所需的最小文件集。
- 瘦身率$r$ 表示镜像体积缩减的比例。$r$ 越接近 100%，说明去掉的冗余越多；$r$ 为 0 则说明完全没有优化效果。
多架构构建
老周的菜谱火遍全国，可各地的灶台不一样：总店是燃气灶，分店是电磁炉，还有一家柴火灶。同样一道红烧肉，火候必须按灶台调整。Docker 镜像也面临同样的“灶台差异”：Intel/AMD 的 x86_64（amd64）服务器和 Apple Silicon 的 ARM64（arm64）机器，CPU 指令集不同，不能直接运行同一个二进制。如果不做多架构处理，就会出现“在 Mac 上构建的镜像，推到云服务器上报 exec format error”的经典翻车现场。
多架构构建（Multi-Arch）的解决方案是“一张菜谱，多个灶台版本”。用 docker buildx build --platform linux/amd64,linux/arm64 可以一次构建多个平台的镜像：在 x86 开发机上通过 QEMU 模拟器执行 arm64 指令，实现交叉构建。构建完成后，推送仓库时 Docker 会生成一个 manifest list（索引清单），把各个平台的镜像捆在同一个“镜像名：tag”下。用户 docker pull 时，客户端自动读取清单，选择与自身架构匹配的那一份，无需任何手动操作。
老周最后在厨房贴了一张总表：“燃气灶用 500W 小火 40 分钟，电磁炉用 900W 35 分钟。”多架构镜像就是这张总表——一次构建、多处部署、自动匹配。对于要部署到混合架构集群的 AI 服务，这是现代镜像构建的标准姿势。
- 索引清单$\mathcal{M}_{多架构}$ 是 manifest list，它本身不包含文件数据，只记录“这个 tag 下有哪些平台的镜像”。
- 平台镜像$镜像_{amd64}$ 与 $镜像_{arm64}$ 是同一应用在不同 CPU 架构下真正的镜像包，各自包含对应架构的二进制和库文件。
- 集合关系$\{ \cdot \}$ 表示这是一个按平台检索的分支集合。Docker 客户端按自身架构从集合中选取对应项，透明完成“菜单点菜”。
构建安全实践
后厨有条铁律：不认识的肉不进冰箱，过期调料当天扔。老周还每季度请食品安全局拿放大镜来扫库存，所有食材按批次贴溯源码。镜像构建的安全实践，和这套后厨规矩一一对应：基础镜像来源要可信，容器内进程别拿 root 身份乱跑，依赖库要定期扫漏洞，镜像要签名防篡改。
具体落地时，首先把 FROM 固定到官方仓库并锁定版本甚至 digest，而不要用 latest 这种移动标签——否则今天构建和三个月后构建可能得到完全不同的底料。其次在 Dockerfile 里创建非 root 用户并切换：RUN useradd -m appuser 加 USER appuser，让进程以最小权限运行。第三，在 CI 中集成 Trivy、Grype 等扫描工具，对镜像做漏洞扫描，高危漏洞不通过就不发布。最后用 Cosign 给镜像签名，部署平台校验签名后才允许拉取运行，防止镜像被篡改。构建时的密钥（SSH key、pip token）要用 BuildKit 的 RUN --mount=type=secret 传递，绝不能写死在镜像层里——写死等于把钥匙贴在保险柜门上。
老周的“食品安全审计”对应镜像漏洞扫描，“溯源码”对应镜像签名。安全不是一次性的，而是每次构建都要走一遍的流程——就像后厨每天的进货检查，缺一天都可能让整条流水线中招。
- 高危漏洞数$N_{高危漏洞}$ 是漏洞扫描器发现的 critical 与 high 级别漏洞个数，比如系统库里已知的远程代码执行漏洞。
- 依赖总数$N_{总依赖}$ 是操作系统软件包与语言依赖（pip/npm 包）的总数。基础镜像越小，暴露面通常越小。
- 风险率$R_{风险}$ 衡量一个镜像的已知危险密度。密度高时应更换基础镜像或升级依赖，而不是带着漏洞上线。
性能调优复用
年夜饭订单爆单，老周安排三个帮厨同时备菜：一个切肉，一个焯水，一个调汁，各干各的互不干扰；熬好的高汤几道菜共用，不用每道菜重新熬。镜像构建的性能优化，本质上就是这三件事：并行、复用、缓存。Docker 的新一代构建引擎 BuildKit，会把 Dockerfile 解析成依赖图，能并行的阶段（尤其是多阶段构建中的独立阶段）并行执行，并跳过没有被依赖的冗余步骤。
在团队协作层面，层复用带来的收益更惊人：统一维护一个“公共基础镜像”（比如 Python 3.10 + CUDA 12.1 + 常用工具），所有 AI 服务镜像都基于它构建。这个基础层只构建、拉取一次，被几十个项目共享。CI 流水线里还可以开启 Docker Layer Caching（DLC），将 pip/npm 缓存目录挂载为持久缓存卷，让每次构建的依赖安装接近秒级。依赖预装则是另一种“高汤复用”：把频繁使用的依赖提前打进基础镜像，业务镜像构建时只需薄薄一层。
高汤共用、分工备菜、冰箱半成品，这三件套就是层复用、并行构建和缓存命中的后厨版。性能调优的终点不是把一条构建压到极致，而是让整个团队的镜像构建体系——从基础镜像到 CI 流水线——都像老周的后厨一样有条不紊。
- 串行构建耗时$T_{串行}$ 是传统构建方式按顺序逐条执行指令的总耗时，任何一步慢，全程跟着慢。
- 并行构建耗时$T_{并行}$ 是 BuildKit 按依赖图把可并行阶段同时执行后的总耗时。多个独立阶段可以“同时下锅”。
- 加速比$Speedup$ 衡量并行化的效果。由于存在不可并行的串行部分（如最初的 FROM 拉取），加速比不会无限增长，但通常也能达到 2-5 倍。
AI 应用场景
AI模型推理服务容器化
阶段：模型部署与推理服务化
解决的问题：传统方式在服务器上手工配置 Python、CUDA、PyTorch 环境，版本冲突、缺少依赖、换机器就崩是常态。AI 推理服务对运行环境一致性要求极高，镜像构建把它变成了“标准料理包”。
具体案例：某算法团队把“文本向量化服务”做成镜像：第一阶段基于 pytorch/pytorch:2.1-cuda12.1 安装依赖并编译自定义算子；第二阶段只复制 site-packages、TorchScript 模型和 FastAPI 应用代码，基础镜像换为精简版。最终镜像从 5.2GB 瘦身到 1.8GB，GPU 节点从拉取到启动只需 40 秒。
CI/CD流水线自动构建镜像
阶段：持续集成与持续部署（CI/CD）
解决的问题：代码一提交就要自动构建镜像、推送到私有仓库。缺少缓存设计的流水线每次全量构建，动辄十几分钟，阻塞迭代速度。通过 Dockerfile 顺序优化和 Docker Layer Caching，可以让依赖层缓存命中率保持在 90% 以上。
具体案例：某公司的 GitLab CI 流水线中，runner 持久化 pip 缓存目录，docker build 使用 --cache-from 拉取上一次构建的镜像作为缓存源。业务代码变更后的构建时间从平均 8 分钟下降到 2 分钟，PR 验证效率提升 4 倍。
开发环境标准化
阶段：研发效能与工程环境治理
解决的问题：新同事入职配置 Python、CUDA、Jupyter 环境要花一整天，且每个人的环境版本不一致，出现大量“我电脑上能跑”的争论。容器化开发环境用统一基础镜像实现“秒级拉起标准环境”。
具体案例：某 AI 实验室将 CUDA、cuDNN、JupyterLab、常用 Python 包打成 base-dev:2024.04 基础镜像，固定 digest 发布。团队成员通过 VS Code Dev Containers 连接容器开发，统一了环境版本，模型训练结果可复现率显著提升。
Python 演示
"""docker_layer_reuse.py模拟分析一组 Docker 镜像的层复用情况，帮助团队评估基础镜像选型与层共享收益。""" from collections import Counter # 模拟镜像 -> [(层ID, 大小MB)]images = { "recommend-api:2.3": [ ("python:3.10-slim/base", 120), ("ray/install", 210), ("app-code", 48), ], "chat-api:1.7": [ ("python:3.10-slim/base", 120), ("torch/install", 780), ("app-code", 95), ], "data-job:0.9": [ ("python:3.10-slim/base", 120), ("ray/install", 210), ("sqlalchemy/install", 60), ("job-code", 32), ],} def analyze_reuse(image_dict): layer_count = Counter() layer_size = {} for layers in image_dict.values(): for lid, size in layers: layer_count[lid] += 1 layer_size[lid] = size unique_total = sum(layer_size.values()) naive_total = sum( cnt * layer_size[lid] for lid, cnt in layer_count.items() ) print("=== 镜像层复用分析 ===") for lid, cnt in layer_count.most_common(): label = "共享" if cnt > 1 else "独有" print(f" {lid:24s} {layer_size[lid]:5d}MB 被{cnt}个镜像引用 [{label}]") save = naive_total - unique_total ratio = save / naive_total * 100 if naive_total else 0 print(f"\n不复用时理论拉取总量: {naive_total} MB") print(f"去重后实际存储量: {unique_total} MB") print(f"层共享节省: {save} MB ({ratio:.1f}%)") if __name__ == "__main__": analyze_reuse(images)
from collections import Counter引入计数器，准备统计每个镜像层被多少个镜像引用。layer_count[lid] += 1每出现一次就加一，求出该层的共享度。layer_size[lid] = size记录每个唯一层的大小；字典按层 ID 去重，天然对应“共享层只存一份”。unique_total = sum(layer_size.values())得到去重后的实际存储总量。naive_total = sum(cnt * layer_size[lid] ...)模拟“完全不共享”时每个镜像各存一份的理论总量。layer_count.most_common()按引用次数从高到低输出，先看到共享收益最大的层。ratio = save / naive_total * 100算出层复用节省的百分比，作为基础镜像选型的量化依据。
常见误区
误区“为了省空间，我把所有 RUN 用 && 串成一条，层数越少镜像肯定越小、构建越快。”
正解层数是结果，不是优化目标。盲目合并层会破坏缓存粒度：依赖文件稍微一改，整条“超级 RUN”全部重建。合理的做法是语义化分层——基础镜像一层、依赖安装一层、业务代码一层，让变化慢的层稳定命中缓存。镜像大小主要由层内内容决定，而不是层数本身。
为何常见：初学者看到层多就直觉觉得“冗余”，又听说“层数影响性能”，于是走向极端合并，忽略了构建缓存才是性能大头。
误区“FROM python:latest 最省事，每次构建都自动用最新版，还能白嫖安全更新。”
正解latest 是移动标签，今天构建和三个月后构建可能拿到完全不同的基础镜像，导致“构建不可复现”——昨天的镜像能跑，今天同样的代码却崩了。生产环境应固定到具体版本号，更严格时锁定 digest（如 python:3.10-slim@sha256:xxxx），保证内容指纹完全一致。
为何常见：本地开发用 latest 确实方便，而且小项目短期内不会暴露问题，但一旦进入团队协作或发布流程，“幽灵变更”就会准时上门。
误区“Alpine 只有几 MB，所有 Python 镜像都改成 Alpine 就好，越小越安全。”
正解Alpine 使用 musl libc，与主流 Linux 发行版的 glibc 存在差异。部分 Python 包（如 pydantic、psycopg2 的某些版本）没有 musl 的预编译 wheel，安装时被迫源码编译，反而更慢、更容易失败；某些二进制依赖在 musl 下行为异常。应结合场景选择：追求极致小体积且依赖兼容时用 Alpine，追求兼容性时用 slim 或 distroless。
为何常见：大量教程和博客渲染 Alpine 的“小”，却很少提及 musl 兼容性成本，导致把它当成万能瘦身药。
误区“我是 Python 开发，没有编译过程，多阶段构建对我没用。”
正解Python 项目同样受益于多阶段构建：第一阶段安装依赖、编译 C 扩展、打包资源；第二阶段只复制 site-packages 和应用代码，连 pip、gcc、build-essential 都不带。这样镜像既小又干净，攻击面也大幅缩小。只要存在“构建时需要但运行时不需要”的东西，多阶段构建就适用。
为何常见：多阶段构建的教程示例几乎都是 Go、Java 等编译型语言，让人误以为“没编译就没必要分阶段”。
误区“项目目录不大，.dockerignore 写了也白写，多此一举。”
正解docker build 会把整个构建上下文（目录及子目录）打包发送给构建引擎。AI 项目里 .git、.venv、node_modules、模型权重、数据集动辄几百 MB 到几 GB，不写 .dockerignore 会导致构建缓慢、内存吃紧，甚至把密钥和敏感数据带进镜像。它同时是性能手段和安全防线，属于“必须写”而非“建议写”。
为何常见：本地构建时目录小、感觉不到差异，一旦上了 CI 或工程规模变大，构建上下文就会成为隐形瓶颈。
面试题
Q1. 关于 Docker 镜像与容器的关系，下列说法正确的是？
- A.容器是模板，镜像是运行实例
- B.两者完全相同，没有区别
- C.镜像是模板，容器是实例← 正确答案
- D.镜像是压缩包，容器是解压后的目录
答案：C。镜像对应“标准料理包”，是静态的只读模板；容器对应“端上桌的菜”，是模板创建的运行实例。A 说反了，B 混淆了二者的静态/动态本质，D 把镜像误认为普通压缩包——镜像的核心是分层文件系统，不是简单解压。
Q2. Dockerfile 中 FROM 指令的作用是什么？
- A.指定基础镜像← 正确答案
- B.复制文件进镜像
- C.设置环境变量
- D.声明容器端口
答案：A。FROM 是 Dockerfile 的第一条有效指令，指定构建所基于的镜像，相当于菜谱里的“用什么底汤”。COPY 负责复制文件，ENV 设置环境变量，EXPOSE 声明端口，都是后续步骤。
Q3. 关于 Docker 镜像分层，以下说法正确的有哪些？
- A.多个镜像可以共享底层← 正确答案
- B.只有 RUN 指令会创建层
- C.容器运行时会增加可写层← 正确答案
- D.修改指令会删掉旧基层
答案：AC。镜像层可被多个镜像引用（A 对），容器运行时在只读镜像层上叠加可写容器层（C 对）。COPY、ADD 等指令也会创建层，不是只有 RUN（B 错）；修改 Dockerfile 只是让旧层不再被索引，并不会删除已构建的底层（D 错）。
Q4. Dockerfile 中，下面哪种改动会使其后所有层缓存失效？
- A.提高容器内存限制
- B.在末尾新增 EXPOSE
- C.修改 Dockerfile 注释
- D.修改 RUN 指令本身← 正确答案
答案：D。缓存键包含指令内容，修改 RUN 指令会改变该层及其后所有层的缓存键，导致全链失效。内存限制是运行参数，不参与镜像构建；末尾新增 EXPOSE 不影响前面层的缓存；注释不构成指令内容，不影响缓存。
Q5. 下列哪些做法能有效瘦身 AI 推理镜像？
- A.多阶段构建分离运行时← 正确答案
- B.使用精简基础镜像← 正确答案
- C.增加 RUN 指令条数
- D.保留所有编译工具链
答案：AB。多阶段构建把编译环境留在第一阶段，运行时镜像只带产物（A 对）；精简基础镜像减小底汤体积（B 对）。增加 RUN 条数反而增加层数和中间产物；保留编译工具链会显著增大镜像并扩大攻击面。
Q6. 一个镜像同时支持 amd64 和 arm64 两种平台，依赖的是什么机制？
- A.在 Dockerfile 中写分支判断
- B.把两种架构塞进同一镜像
- C.通过 manifest 索引清单支持← 正确答案
- D.手动构建两次并改不同标签
答案：C。多架构镜像靠 manifest list 把各平台镜像登记在同一个 tag 下，用户拉取时客户端按自身架构自动选择对应镜像。Dockerfile 没有运行时架构分支；把两套二进制混进一个镜像并不可行；手动改标签无法实现透明自动选择。
Q7. 多阶段构建的主要目的是什么？
- A.让构建过程执行得更快
- B.分离编译与运行环境缩小镜像← 正确答案
- C.支持多个用户同时使用
- D.让所有层都能缓存复用
答案：B。多阶段构建把编译安装过程放在第一阶段，最终只把产物复制到精简的第二阶段，从而去掉编译器与临时文件，大幅缩小镜像。它主要解决“体积与安全”问题，虽然构建速度快是附带收益，但不是核心目的。
Q8. 关于 Docker 构建缓存机制，以下说法正确的有哪些？
- A.COPY 通过文件校验和判断变化← 正确答案
- B.任一层未命中后后续全部重建← 正确答案
- C.使用 --no-cache 强制全部重建← 正确答案
- D.RUN 指令从不参与缓存判断
答案：ABC。COPY 的缓存键基于被复制文件的校验和（A 对）；层缓存链是线性的，任一层失效会导致其后所有层重建（B 对）；--no-cache 强制忽略缓存全量执行（C 对）。RUN 指令也写入缓存键，不是不参与（D 错）。
Q9. 下列哪项是构建安全实践中“最小权限”的正确体现？
- A.使用 root 用户运行容器进程
- B.挂载只读文件系统并保持 root
- C.不设置用户，使用默认 root 配置
- D.USER 指令切换到非 root 用户← 正确答案
答案：D。最小权限要求进程以非 root 身份运行，防止容器被攻破后直接获得宿主机的 root 权限。A、C 都保留了 root 运行；B 虽然只读挂载但仍是 root，进程一旦被利用仍可能通过内核漏洞提权。D 才是标准做法。
Q10. 某团队让多个项目共用同一底层基础镜像，最直接的好处是什么？
- A.容器启动速度变得更快
- B.拉取与存储开销显著降低← 正确答案
- C.构建任务必定命中缓存
- D.镜像安全漏洞自动消失
答案：B。共享底层后，基础层只下载和存储一份，新项目部署时无需重复拉取相同的大层，存储和带宽成本显著下降。容器启动速度主要受运行时初始化影响，与共享层无直接关系；共享层不保证缓存命中；安全漏洞不会因共享而自动消失，仍需扫描和更新。