Docker 面试这件事，我觉得很多人有个认知偏差：以为背熟了docker run、docker build的常用参数，能说出镜像和容器的区别，就算“会 Docker”。但实际上，我在面试里遇到的最多的候选人，恰恰是简历上写着“熟练使用 Docker、熟悉容器化部署”，却在追问到“一条docker run nginx背后到底发生了哪几件事”的时候开始含糊。这不是个例，而是普遍现象：会用命令和真懂原理之间有一道巨大的鸿沟，而面试题考察的恰恰是后者。
这篇文章我打算换一种讲法，不铺开罗列几百道题库，而是把面试中频率最高、也最能拉开差距的几个知识块拆开揉碎：面试官到底在考察什么、镜像容器的底层机制、网络和数据卷该怎么选、Dockerfile 的生产级优化、高频场景题的排查链路，最后再聊几句生产环境相关的进阶追问。整篇内容不是让你背答案，而是帮你建立一套“遇到任何 Docker 问题都能自己推出来”的思路。无论你是准备面试的开发者，还是被临时拉去帮团队做容器化改造的人，都能从这里拿到可以直接用的一手经验。
1. 先想清楚：面试官问 Docker 到底在考什么
1.1 简历上写着“熟练使用 Docker”的人，为什么经常挂在第一问
我先说一个高频画面：候选人自我介绍讲完，我通常会问一句“你平时用 Docker 做什么”。大多数人会回答：本地起中间件、写 Dockerfile 部署服务、用 docker-compose 编排。这些答案没有错，但只能说明你有“使用经验”，还不能证明你“理解 Docker”。于是我换个问法：“你执行docker run -d -p 8080:80 nginx之后，系统大概帮你做了哪些事？”到了这一步，相当一部分人会卡住。
卡住的原因不是笨，而是很多人把 Docker 当成了黑盒。黑盒使用者在日常工作中也能解决 90% 的问题，因为 Docker 的抽象层面做得确实好：一条命令就能把一个服务拉起来，出问题了大不了删掉重建。但面试本质上是在考察你对“黑盒内部”的建模能力。你不需要能写出一套容器运行时，但你必须清楚：镜像和容器的关系、分层存储怎么工作、网络怎么打通、数据存到哪去了、进程是怎么被隔离和限制的。这些才是面试官真正想听到的东西。
所以我给准备面试的同学的第一个建议是：别按“题目-答案”的方式背诵，而是把 Docker 当成一个“操作系统级别的进程管理工具”去理解。Docker 并没有发明新的内核机制，它只是把命名空间、控制组、联合文件系统这几件 Linux 老技术组合成了好用的产品。你的知识体系一旦从这个维度建立起来，很多面试题不需要背也能现场推出来。
1.2 一条主线、三个层次：原理、实践、排错
我把 Docker 相关的面试考察点归纳成一条主线、三个层次。主线是“容器是一个进程，不是一个虚拟机”，后面所有问题都可以回到这句话来解释。三个层次分别是：第一层，镜像与容器的生命周期和存储机制；第二层，网络、数据卷、资源限制这些运行时配置的选型逻辑；第三层，排错能力和生产环境意识，比如容器退出码怎么看、日志怎么收集、镜像安全怎么保障。
为了让你更直观地理解面试官的出题意图，我用下面这个表格梳理了常见的问法、考察点以及加分回答的方向：
| 问题类型 | 表面问法 | 实际考察点 | 加分回答方向 |
|---|---|---|---|
| 基础原理 | 镜像和容器有什么区别 | 是否理解镜像只读、容器可写的分层机制 | 提到写时复制、容器层在删除后消失 |
| 网络 | bridge 和 host 模式有什么不同 | 是否理解网络隔离和端口映射的本质 | 结合 iptables、NAT、DNS 解析说明 |
| 数据 | 容器删除后数据会丢吗 | 是否理解容器层生命周期 | 区分容器层和 volume/bind mount |
| 实践 | 怎么让 Dockerfile 构建更快 | 是否理解构建缓存机制 | 指令顺序、.dockerignore、多阶段构建 |
| 排错 | 容器状态一直 Restarting 怎么办 | 是否具备排查链路 | 按 logs -> inspect -> exec 的顺序排查 |
| 进阶 | 为什么容器里不建议跑多个进程 | 是否理解 PID 1 和信号处理 | 提到僵尸进程、信号转发、进程管理 |
这个表格不是要你按图索骥，而是提醒你：每一道面试题背后都有一个“为什么”。你回答的时候如果能说清楚背后的机制，就比单纯报出正确答案高一个段位。
2. 镜像与容器的底层逻辑：分层存储和写时复制的完整真相
2.1 从 pull 到 run：一条命令背后的完整链路
我建议每个准备面试的人都把这条链路在脑子里过一遍，它是很多后续问题的基石。这里我先拆解docker run nginx这个最简单的命令，完整描述应该是这样：
第一步，客户端检查本地是否存在nginx:latest镜像。如果不存在，就会向远端仓库发起拉取请求。拉取的时候 Docker 不是下载一个文件完事，而是根据镜像清单拉取配置中声明的各个层。每层下载完成后都要做摘要校验，确保内容和构建时一致。这也是为什么你在公司内网自建仓库时，镜像仓库协议配置出错会直接导致拉取失败。
第二步，镜像层就绪之后，Docker 会创建容器层。容器层本质是一个可写层，所有对文件系统的修改都先写在这里。与此同时，运行时会在镜像的每个层之上叠加挂载，最终呈现出一个合并后的完整根文件系统。这就是 OverlayFS 做的事情：多个只读的 lowerdir 加上一个可写的 upperdir，最终 merge 成一个视图。
第三步，Docker 会为容器创建一套隔离环境。这里面包含名称空间层面的隔离，例如进程树、网络栈、挂载点、用户 ID 等各自独立的视图；还包含控制组层面的资源限制，例如 CPU、内存、磁盘 IO 的配额。这一步做完之后，才会真正启动容器里配置的进程。
第四步，如果命令里带了-p 8080:80，Docker 还会通过 iptables 规则把宿主机 8080 端口上的流量转发到容器的 80 端。这里一定要记住，Docker 的端口映射不是在容器进程里做的，而是宿主机网络栈层面的转发。
我面试中比较喜欢追问的是第三步里的一个小细节：容器里的 1 号进程是谁？很多人会下意识认为是某个 shell 或者服务进程，但其实是你指定的入口进程，比如 Nginx 的 master 进程。这个细节直接关联到后面要讲的 PID 1 与信号处理问题，能答到这里会让面试官觉得你真的操作过容器，而不只是看过文档。
2.2 写时复制和分层复用：为什么容器删除不一定会丢数据
镜像层是只读的，这个特性带来两个非常重要的推论。第一个推论是同一台机器上的多个镜像可以共享底层数据。比如你同时跑了几个基于同一个基础镜像的容器，底层那些基础镜像层在磁盘上只有一份。这也是为什么docker pull某个镜像时，如果本地已经有相同 ID 的层，会显示Already exists。第二个推论是写时复制。容器需要修改某个文件时，会先把文件从只读层复制到容器可写层，再在可写层上修改，原始层保持不动。这是一个典型的时间换空间策略，代价是第一次写入某个大文件时会有一点 IO 开销。
由此引出一个高频面试题：容器删除后数据会丢吗？正确答案需要分情况。如果数据写在容器可写层里，那么容器删除后，这一层随着容器对象一起销毁，数据确实丢了。但如果你把数据挂载到了 volume 或者 bind mount，数据保存在容器生命周期之外，容器删除后数据还在。这个区分很重要，我见过不少生产事故就是因为有人在容器可写层里积累了重要日志，最后容器一删全没了。
这里顺带补充一个容易忽略的知识点：docker commit可以把容器当前状态打包成新镜像。它的原理就是把你现在的容器可写层转换成一个新的镜像层，叠加在原有镜像层之上。面试如果你提到这个命令，一定要说明它的适用场景相当有限。因为它会引入不可复现的状态，生产环境里应该用 Dockerfile 而不是 commit 来生成镜像。这句话接上去，面试官就知道你懂什么叫可复现构建。
提示：关于分层存储，面试时最重要的一个总结句是——镜像层是只读的、共享的；容器层是可写的、临时的。把这两句话说对，比背十个命令都管用。
3. 网络与数据：网络模式选型和数据卷挂载的边界条件
3.1 四种网络模式的适用场景和隐藏坑点
网络是面试题的重灾区，因为它抽象程度高，日常开发中大家只是用-p做端口映射，很少去关心背后的网络拓扑。我建议先把四种内置网络模式的主次特点搞清楚，它们的对比可以用一张表概括。
| 网络模式 | Linux 层面实现 | 典型适用场景 | 需要注意的坑 |
|---|---|---|---|
| bridge | 通过 docker0 网桥和 NAT 访问外网 | 单机多个容器互相通信、端口映射 | 端口映射依赖 iptables，防火墙规则被清会导致无法访问 |
| host | 容器直接使用宿主机网络栈 | 对网络性能要求极高、需要监听宿主机特定端口 | 端口隔离失效，多个容器不能监听同一端口 |
| none | 只有回环接口 | 纯计算任务、对网络安全要求极高的场景 | 需要完全不希望容器对外通信时使用 |
| overlay | 跨主机隧道网络 | Docker Swarm 或 Kubernetes 等跨主机场景 | 一般由编排层管理，单机环境用不到 |
这里我想特别展开两个高频追问。第一个是 bridge 模式下容器和宿主机、容器和容器之间的通信路径。面试时你可以这样回答：默认 bridge 网络下，所有容器都通过 docker0 网桥互通，它们可以用 IP 直接访问彼此；但从容器访问宿主机服务时，需要走网关地址而不是 localhost；从容器访问外部网络则要经过 NAT 和路由转发。这个回答把三层通信关系全部点到了，基本满足考察。
第二个高频追问是容器之间的服务发现。默认 bridge 网络下，容器之间可以通过 IP 通信，但容器重建后 IP 会变化，所以更可靠的方式是使用用户自定义 bridge 网络。自定义网络里，Docker 内置了 DNS 解析，容器可以通过名字直接访问另一个容器，比如在 compose 文件里写的服务名就是干这个用的。这个特性是很多人没用过的，能准确说出来的候选人很少，属于明显的加分项。
3.2 数据卷选择的三个判断标准：生命周期、性能、权限
关于数据卷，面试最常见的问题倒不是“怎么用”，而是“volume 和 bind mount 有什么区别”“我把数据库跑在容器里，数据放哪”这两类。我的建议是遇到容器数据问题，先用三个标准做筛选：第一是数据的生命周期要求，第二是目录是否需要和宿主机共享，第三是权限和性能约束。
volume 由 Docker 管理，存放在 Docker 数据目录下，生命周期独立于容器，是存放数据库文件、应用持久化数据的首选。bind mount 直接把宿主机目录挂进容器，适合需要实时共享配置、日志目录或代码目录的场景，但代价是宿主机的目录结构和权限会直接介入容器，容易出现 uid 不匹配的问题。举一个实际案例：你以 root 身份运行容器，写入 bind mount 的文件在宿主机上也是 root 属主，后续宿主机上的普通用户想清理这个目录就会没有权限。
关于数据库容器化，我给的思路是：数据库本身不适合用 Docker 跑生产，最大的原因不是性能，而是运维复杂度——存储卷的管理、故障恢复、备份机制都会比裸机部署多一层抽象。但如果团队已经决定要用，那务必把数据目录挂载到 volume，并且每天做备份验证。我在面试中听过的错误答案是把数据库数据目录留在容器层，容器一删数据全没了，这就是典型的选型失误。
提示：判断数据放哪里的一个简单经验——配置文件用 bind mount 或环境变量注入，持久化数据用 volume，临时数据用 tmpfs 或直接放容器层。
4. Dockerfile 生产级优化：构建缓存、多阶段构建与基础镜像取舍
4.1 指令顺序决定了缓存命中率
Dockerfile 的面试题通常不是让你“背出语法”，而是给你一个构建太慢的 Dockerfile 让你优化，或者干脆让你手写一个生产可用的 Dockerfile。这两种题目考察的是同一个能力：对构建缓存机制的理解。
Docker 构建时，每条指令都会生成一个中间镜像层，如果某条指令没有变化，后续构建会直接复用，这个过程叫做缓存命中。问题在于，一旦前一条指令的上下文发生了变化，后面的所有缓存都会失效。最常见的反例是把COPY . .放在前面，后面才执行RUN go mod download之类的依赖下载指令。含义是：你每次改一行代码，整个项目目录的校验都会变化，依赖下载这一层缓存就全部失效了，构建时间直接翻几倍。
正确顺序应该是：先复制依赖清单文件，完整下载依赖并生成缓存层，最后才复制源代码。比如用 Go 写的服务，Dockerfile 开头应该是这样的：
FROM golang:1.22-alpine AS builder WORKDIR /src # 先拷贝依赖声明，利用缓存 COPY go.mod go.sum ./ RUN go mod download # 最后再拷贝源码 COPY . . RUN CGO_ENABLED=0 GOOS=linux go build -o /out/app ./cmd/app这样改完之后，只要 go.mod 和 go.sum 没变化，RUN go mod download这层就不会重建，改代码带来的构建时间损耗会被压到最低。这个优化动作在面试里说出来，再配合解释“为什么顺序会影响缓存”，基本能拿到一个很不错的印象分。
另外一个常被忽视的缓存优化是.dockerignore。你在项目根目录执行构建时，如果构建上下文里塞了 node_modules、.git、日志目录这些内容，Docker 需要先把整个上下文打包发送给守护进程，再参与每一条 COPY 指令的校验。臃肿的上下文不仅让首层构建变慢，还可能在配合 CI 时吃满带宽。所以在项目里维护一份精简的.dockerignore是性价比很高的投资。
4.2 多阶段构建：把一个镜像瘦身到三分之一
接下来是多阶段构建，这是 Dockerfile 优化问题里最有技术含量的一环。它的核心目的是将“构建环境”和“运行环境”分离：第一阶段使用带完整工具链的基础镜像完成源码编译，第二阶段使用精简的运行镜像，只把编译产物复制过去。
我举一个实际的改造例子。假设你原来写了这样一个单阶段 Dockerfile：
FROM golang:1.22-alpine WORKDIR /src COPY . . RUN go build -o /app . CMD ["/app"]这个镜像看起来没什么问题，实际构建出来体积会非常大，因为它包含了 Go 编译器、完整的系统工具链和源码文件。而且更隐蔽的问题在安全层面：生产容器里存放了编译器和源码，一旦被攻破，攻击者可以现场编译工具进行横向渗透。
改成多阶段构建之后：
FROM golang:1.22-alpine AS builder WORKDIR /src COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 GOOS=linux go build -o /out/app ./cmd/app FROM alpine:3.20 RUN addgroup -S app && adduser -S app -G app COPY --from=builder /out/app /usr/local/bin/app USER app EXPOSE 8080 ENTRYPOINT ["app"]第二阶段只拷贝了编译产物，基础镜像从 golang 换成了 alpine 运行镜像，体积通常可以从几百 MB 降到几十 MB。顺带我在基础镜像里创建了一个无特权用户并切换过去，这是为了容器安全，后面会专门讲。这套写法在生产环境里非常通用，面试时如果能讲清楚--from=builder的复制逻辑，再解释一下为什么运行阶段不需要编译器，面试官就能判断你不是背的模板。
4.3 基础镜像到底怎么选：alpine、slim 还是 distroless
关于基础镜像的选型，我见过很多候选人直接回答“用 alpine，小”。这个答案方向正确但不够完整。alpine 确实体积小，但它使用的 musl libc 和主流发行版的 glibc 存在兼容性差异，某些编译型语言的二进制或依赖了特定动态库的程序可能在 alpine 里报not found之类的错误。所以更稳妥的选型思路是：能用 distroless 就用 distroless，不能用就优先考虑 debian slim 或 alpine，但必须做完整测试。
这里我补充一个实用的判断流程：先确认你的编译产物是动态链接还是静态链接，如果是静态链接，可以直接上 scratch 或 distroless；如果是动态链接，需要带上目标 libc 对应的运行库。这也是为什么我在多阶段构建的例子里用了CGO_ENABLED=0，这是为了生成一个不依赖 CGO 的纯静态可执行文件，从而让运行镜像可以尽量精简。面试中把这个逻辑链讲清楚，比单纯说 alpine 体积小要高级得多。
5. 高频场景题拆解：容器异常退出、资源耗尽、拉取失败怎么答
5.1 从退出码看容器状态：一张表对应一套排查链路
场景题是面试里最能拉开差距的部分，因为它考察的是你“遇到问题之后会怎么动手”，而不是“记没记住结论”。先看一个最常见的场景：部署完容器，发现它一直重启，状态始终是Restarting。这时候标准排查链路是什么？我建议按下面三步走：
第一步，看日志。执行docker logs 容器名，绝大多数启动失败的原因都在这里，比如端口被占用、配置文件缺失、数据库连不上。第二步，看容器详情。执行docker inspect查看退出码、挂载情况、环境变量、健康检查结果，这一步能补充日志里看不到的元信息。第三步，必要的时候进入容器或者用docker exec执行诊断命令，比如查看进程是否存在、配置文件内容是否正确、依赖的服务是否可达。
排查时有一个关键线索是退出码。很多候选人只凭感觉说“容器挂了”，但如果能结合退出码分析，定位效率会高很多。我整理了一份高频退出码表，你可以直接作为排查参考：
| 退出码 | 信号/含义 | 常见触发场景 |
|---|---|---|
| 0 | 正常退出 | 一次性任务执行完成 |
| 1 | 应用程序错误 | 参数错误、运行时异常、初始化失败 |
| 125 | Docker 守护进程层面错误 | 启动容器失败，比如无法解析镜像名 |
| 126 | 命令无法执行 | 二进制缺少执行权限 |
| 127 | 命令未找到 | 镜像里不存在指定的启动命令 |
| 137 | SIGKILL（128+9） | 内存超限被强制终止、手动 kill -9 |
| 139 | SIGSEGV | 段错误，常见于内存访问越界 |
| 143 | SIGTERM（128+15） | 优雅停机超时后被终止 |
表格里有一行特别值得展开，就是 137。这个退出码在面试里经常和“资源限制”一起出现。如果你给容器设置了--memory限制，容器内进程一旦触顶，控制组就会由内核直接发送 SIGKILL 终止进程，最终表现为退出码 137。很多人第一反应是去看应用日志，但应用根本来不及处理这个信号，日志里往往一片空白。这种时候正确的做法是看docker inspect里的OOMKilled字段是否变成 true，再看docker stats确认实时的内存占用趋势。
5.2 资源限制和 OOM：从参数配置到 cgroup 原理
资源限制题目的标准答法分成两层。第一层是参数层面，你需要能说出常用的限制参数：--memory限制内存上限，--cpus限制 CPU 配额，--pids-limit限制进程数量上限，--ulimit限制文件描述符数量。举个例子，生产环境里启动一个 Java 服务常用的限制组合是：
docker run -d \ --name app \ --memory=2g \ --memory-swap=2g \ --cpus=1.5 \ --restart=unless-stopped \ myapp:1.0.0这里有一个细节值得强调：--memory-swap要显式设成和内存一致，否则容器可能会在内存紧张时使用 swap，导致真实内存占用情况变得不可控。这是 Java 类应用经常遇到的坑，很多线上 OOM 都是因为 swap 掩盖了实际内存压力。
第二层是原理层面，你需要提到 cgroup。Docker 的资源限制本质上是 Linux 控制组的应用：把容器里的进程放进独立的控制组，在控制组上设置资源阈值。控制组约束的是“一组进程”的整体资源使用，而不是单个进程。所以即使容器里只有一个进程，它也不能超过整个控制组的配额。这句话能讲出来，面试官就能确认你对底层机制是有认知的，而不是只会抄参数。
5.3 镜像拉取失败：从网络到认证的逐层定位
镜像拉取失败也是出现频率极高的场景题。常见的现象包括manifest unknown、unauthorized、connection refused、no space left on device等几种。我给的排查路径是从外向里：先确认网络可达性，再确认认证信息，最后检查磁盘与仓库配置。
网络可达性上，最容易踩的坑是公司内网自建了镜像仓库，但 Docker 客户端默认走的是官方源。你在客户端配置里加一行registry-mirrors或直接把自建仓库地址写进daemon.json就能解决。认证问题上，私有仓库通常需要先执行docker login拉取凭证，拉取失败时优先检查登录状态，以及密钥是否过期。磁盘方面比较隐蔽：镜像拉取先解压再写入，所以即使你觉得自己磁盘还剩好几个 GB，如果同时拉取几个大镜像，也可能在解压过程中触发no space left错误。排查时别只看剩余空间，还要检查 Docker 数据目录所在分区的 inode 是否耗尽。
提示：面试里答场景题，关键是展示“先定位问题，再动手解决”的思路。一个完整但顺序正确的排查链路，比直接说出最终结论更能打动面试官。
6. 生产环境相关：安全、日志、编排的进阶追问方向
6.1 非 root 运行与只读根文件系统：两个最容易被追问的安全话题
到了这个阶段，面试官一般会开始考察你有没有“生产环境意识”。安全话题是最好用的切入口，因为它既抽象又和实际部署强相关。第一个高频问题是：容器里能不能跑 root？答案是可以，但不建议。原因不在于 root 本身，而在于容器内的 root 和宿主机 root 之间，权限隔离并不绝对。如果容器使用了默认配置，又没有做额外的能力限制，一旦容器被攻破，攻击者很可能借助系统调用的漏洞直接影响到宿主机内核。
面试中比较加分的建议是三件事组合使用：第一，在 Dockerfile 里创建专用用户并切换，比如用adduser创建后通过USER指定；第二，在docker run时加--cap-drop=ALL，然后按需添加能力，比如--cap-add=NET_BIND_SERVICE；第三，把根文件系统挂载成只读，比如docker run --read-only，这样应用即使被入侵也无法在容器文件系统里写东西。这三步组合起来能把容器的爆炸半径压到很小，体现的明显是实战积累而不是文档阅读量。
6.2 日志收集与 stdout 的取舍
日志方向的追问，我最常听到的回答是“把日志挂载到宿主机目录”。这个答案在生产环境不算最优。正确的设计哲学是：应用把日志写到标准输出，由 Docker 的日志驱动统一收集，再转发给集中式日志平台。这样做的好处是容器本身无状态，日志采集和容器生命周期解耦，扩容缩容时不需要担心日志文件丢失。
如果你在面试中被追问到日志配置，可以补充两个细节。一是日志驱动默认是 json-file，可以在daemon.json里配置max-size和max-file做轮转，避免单个日志文件把分区写满。二是如果业务日志量特别大，可以使用专门的文件日志采集方案，比如把日志写到 volume 再由采集器抓取。这两种方案各有利弊，你只要能说出“容器无状态优先，特殊情况特殊处理”的取舍原则，回答就已经合格了。
6.3 从单机到编排：Kubernetes 问题如何体现 Docker 功底
最后一个进阶方向是编排。很多候选人其实没有深度用过 Kubernetes，但面试官依然会追问几层：你自己写的 Dockerfile 到 Kubernetes 里跑，哪些配置要变？容器里的运行时资源、健康检查、存储卷怎么描述？这些问题的内核其实还是 Docker 本身的概念，只是换了一层声明式语法。
我建议你抓住一个关键映射关系去回答：Docker 的docker run参数对应用户在 Kubernetes 里的 Pod 描述字段，比如--memory对应资源请求和限制，-v对应卷挂载，-p对应服务的暴露方式，--restart对应用户里配置的重启策略。这个映射关系只要理清了，即使你对 Kubernetes 的具体语法记忆不深，也能沿着 Docker 的语义推导出答案。面试官想听的并不是你背了多少个 Kubernetes 资源对象，而是你能不能从容器运行时的角度理解编排系统为什么要这样设计。
关于这块我还有个实在的建议：没必要为了面试把所有 Kubernetes 内容背一遍。把 Docker 本身的原理吃透，学会在docker inspect和docker stats里阅读一手信息，遇到任何编排问题都能用容器思维推出一套合理的答案。我自己在实际操作中的体会是，那些能在面试里把 Docker 讲得头头是道的人，往往不是背题最多的，而是真的在服务器上把容器拆开看过、重建过、排错过。最后再分享一个小技巧：准备面试前，把你平时用的每个镜像用docker inspect看一遍，把里面的网络模式、挂载点、环境变量、健康检查逐行读一次，这比刷一百道题都管用。
