企业官网建设流程全解析

Docker 不只是"把应用装进盒子"，它重新定义了软件的构建、交付与运行方式。本文从镜像分层、容器隔离、Dockerfile 最佳实践、数据卷与网络、Compose 编排，一路挖到 namespace/cgroup/OverlayFS 与 containerd/runc 运行时链路，最后给出 30 条高频踩坑与性能/安全清单。

1. 背景：为什么容器成了云原生时代的"集装箱"

1.1 软件交付之痛

先看三个每天都在发生的真实场景：

• "在我机器上是好的"：开发环境 CentOS 7，测试环境 Ubuntu 22.04，生产环境 Debian 12，同一个二进制在不同发行版上行为不同（glibc 版本、系统库、时区、locale），排错全靠玄学。
• 依赖地狱：一个项目要 Python 3.11 + Node 20 + PostgreSQL 15 + Redis 7，各自还有传递依赖。装完 A 升级 B 把 C 弄挂了，环境越用越脏。
• 隔离是假的：多个服务共享一台机器，一个进程内存泄漏拖垮整机；一个服务被攻破，同主机的其他服务全部暴露；版本升级"顺带"把别的服务依赖改了。

传统方案是虚拟机：一台物理机上跑多个"完整操作系统"，隔离彻底，但代价高昂——每个 VM 都要完整的 OS 内核、系统库、引导流程，启动分钟级，资源占用 GB 级，镜像交付动辄几个 GB。

1.2 容器的本质：共享内核的轻量隔离

容器（Container）的答案不是"再造一台机器"，而是共享宿主机内核 + 用户态隔离：

• 隔离什么：进程树、文件系统视图、网络栈、主机名、用户、挂载点——通过 Linux Namespace 实现；
• 限制什么：CPU、内存、IO 用量——通过 Linux Cgroup 实现；
• 怎么复用：镜像分层 + 写时复制（Copy-on-Write），同一基础层被成百上千个镜像共享，启动一个容器只需在只读层上加一层可写层。

对比表格：

1.3 Docker 的前世今生

• 2013 年：dotCloud 公司开源内部工具 Docker，用 Go 编写，一举引爆容器热潮；
• 2015 年：Docker 牵头成立 OCI（Open Container Initiative），将容器运行时与镜像格式标准化，避免生态碎片化；
• 2017 年：Docker 将容器运行时捐给 CNCF，演化为 containerd；Docker 自身演变为"工具集"角色，是 Kubernetes 等编排系统的容器运行时前端；
• 现在：Docker 桌面端 + Docker Engine + Docker Hub 仍是开发者使用容器的最短路径，而 Kubernetes/云原生生态全面建立在 OCI 标准之上。

一句话：你用的不是"Docker 技术"，而是 OCI 标准 + Linux 内核机制；Docker 是其中最顺手的那把瑞士军刀。

2. 核心概念速览

2.1 三角关系：镜像 / 容器 / 仓库

• 镜像不可变（immutable），容器可变（可写层写入后，随容器销毁丢失——除非挂数据卷）；
• 同一个镜像可以启动任意多个容器，互不影响；
• 删除镜像不等于删除容器，删除容器不等于删除镜像，删除镜像时若容器还在引用会失败。

2.2 镜像分层与写时复制

镜像由若干**只读层（Layer）**叠加而成，每一层对应 Dockerfile 中的一条指令：

FROM ubuntu:22.04 # 层1：基础层 RUN apt-get update ... # 层2 COPY app /app # 层3 CMD ["./app"] # 元数据层（不产生文件层）

• 层是内容寻址的：每层由内容哈希唯一标识（digest），相同内容只存一份，跨镜像共享；
• 启动容器时在最上层加一个可写层（container layer），所有写操作发生在可写层，对下层文件修改采用Copy-on-Write：首次修改某文件时先把它从下层复制到可写层再改，下层永远不被污染；
• 删除文件也只是在可写层打一个"白洞（whiteout）"标记，镜像本身不变；
• 因此提交（commit）容器可以"冻结"出一个新镜像，但工程上应避免 commit，改用 Dockerfile 可复现构建。

2.3 三大隔离支柱

三者配合：容器进程"看起来"独占一台机器（namespace），"用起来"被关在配额里（cgroup），"文件系统"既有只读底层又有一层可写面（OverlayFS）。

2.4 OCI 标准

• image-spec：镜像格式、层压缩格式、Manifest、索引（Multi-Arch）标准；
• runtime-spec：容器运行时配置（rootfs、namespace、cgroup、进程属性）标准；
• distribution-spec：镜像分发 API 标准。

有了 OCI，任意满足标准的运行时（runc、crun、gVisor、Kata）都能运行任意满足标准的镜像——这就是"标准打败碎片化"的经典案例。

3. API 说明：CLI / Engine API / Dockerfile / Compose

3.1 Docker CLI 命令族速查表

高频 run 参数速查：

3.2 Docker Engine API（REST / SDK）

Docker Engine 暴露 RESTful API（默认 /var/run/docker.sock，版本 /v1.xx），CLI 本质就是该 API 的客户端：

• 核心端点：GET /containers/json、POST /containers/create、POST /containers/{id}/start、GET /containers/{id}/logs、POST /images/create、POST /build、GET /events（事件流）等；
• 官方 SDK：Go github.com/docker/docker/client、Python docker 包、Node dockerode；
• 典型用途：CI 里动态起容器、自研管理平台、测试环境一键编排。

Python 示例（创建并启动一个容器）：

import docker client = docker.from_env() # 从环境读取 DOCKER_HOST / docker.sock container = client.containers.run( "alpine:3.19", command="echo hello from python sdk", detach=True, remove=True, ) print(container.logs().decode())

3.3 Dockerfile 指令速查表

exec 形式 vs shell 形式（最高频考点）：

# exec 形式（推荐）：不经过 shell，PID 1 就是程序本身 CMD ["python", "app.py"] ENTRYPOINT ["docker-entrypoint.sh"] # shell 形式：经过 /bin/sh -c，信号转发到 shell 而非程序 CMD python app.py

exec 形式保证容器 PID 1 就是你的程序，docker stop 发出的 SIGTERM 能直接送达程序实现优雅退出；shell 形式下信号被 sh 吞掉，程序收不到，容易"停不掉"。

3.4 docker compose 文件结构（Compose v2 / compose.yaml）

services: web: build: . ports: - "8080:80" depends_on: - db environment: - APP_ENV=prod healthcheck: test: ["CMD", "curl", "-f", "http://localhost/health"] interval: 10s timeout: 3s retries: 5 db: image: postgres:16 volumes: - db_data:/var/lib/postgresql/data environment: POSTGRES_PASSWORD: "${DB_PASSWORD}" volumes: db_data:

核心字段：services（服务定义）、networks（自定义网络）、volumes（命名卷）、configs/secrets（配置与机密）、profiles（按需启用）。Compose 的价值是"一条命令拉起多容器应用 + 编排依赖顺序 + 服务间自动 DNS 解析"。

4. 详细使用说明（可运行示例）

4.1 安装与 Hello World

• Linux：curl -fsSL https://get.docker.com | sh 或发行版包管理器安装 docker-ce、docker-compose-plugin、docker-buildx-plugin；
• Windows/macOS：Docker Desktop（Windows 需开启 WSL2 后端）；
• 验证：

docker version docker run --rm hello-world

hello-world 会演示一次完整的镜像拉取 → 运行 → 退出流程。

4.2 镜像全流程：拉取 / 运行 / 构建 / 推送

# 拉取 docker pull nginx:1.27-alpine # 运行（前台，Ctrl+C 退出） docker run --rm -p 8080:80 nginx:1.27-alpine # 后台运行 docker run -d --name web -p 8080:80 nginx:1.27-alpine # 查看 docker ps # 运行中 docker ps -a # 全部 docker logs -f web # 跟随日志 docker exec -it web sh # 进入容器 # 构建与推送 docker build -t myapp:1.0 . docker tag myapp:1.0 registry.example.com/team/myapp:1.0 docker push registry.example.com/team/myapp:1.0 # 清理 docker system prune -af # 慎用：删除所有未使用镜像/容器/网络/构建缓存

4.3 Dockerfile 多阶段构建（以 Go 程序为例）

多阶段构建解决"构建环境大、运行环境瘦"的矛盾：第一阶段装全量工具链编译，第二阶段只拷贝产物进精简运行时。

# ---- 阶段 1：构建 ---- FROM golang:1.22-alpine AS builder WORKDIR /src # 先复制 go.mod/go.sum 以最大化利用层缓存 COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 go build -ldflags="-s -w" -o /out/app . # ---- 阶段 2：运行 ---- FROM alpine:3.19 RUN apk add --no-cache ca-certificates tzdata && \ cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime && \ echo "Asia/Shanghai" > /etc/timezone COPY --from=builder /out/app /usr/local/bin/app USER nobody EXPOSE 8080 ENTRYPOINT ["app"]

要点：

• CGO_ENABLED=0 产出纯静态二进制，运行时连 libc 都不需要；
• COPY --from=builder 跨阶段拷贝；
• USER nobody 非 root 运行；
• 最终镜像通常只有十几 MB，而单阶段 golang 镜像动辄 800MB+。

4.4 数据持久化：volume vs bind mount

容器可写层随容器销毁而消失，持久化数据必须挂载：

# 卷的生命周期 docker volume create pgdata docker run -d --name pg -v pgdata:/var/lib/postgresql/data -e POSTGRES_PASSWORD=secret postgres:16 docker volume inspect pgdata # 查看挂载点 docker run --rm -v pgdata:/data alpine ls /data # 卷间备份/迁移

开发场景热更新：bind mount 源码目录 + 容器内重载服务；生产场景：优先命名卷，避免 host 路径漂移。

4.5 网络：模式与自定义网络

# 自定义网络 + 服务名互访 docker network create mynet docker run -d --network mynet --name api myapi:1.0 docker run -d --network mynet --name worker myworker:1.0 docker exec worker ping api # 直接 ping 服务名，无需查 IP

端口映射语义：-p 8080:80 的 8080 是宿主机端口，80 是容器内端口；容器重启后 IP 会变，但端口映射不变——对外永远用"宿主机 IP + 映射端口"访问。

4.6 Docker Compose 编排（Web + DB + Cache）

services: web: build: . ports: ["8080:8080"] depends_on: db: condition: service_healthy environment: DB_DSN: "postgres://app:${DB_PASSWORD}@db:5432/app" REDIS_ADDR: "cache:6379" db: image: postgres:16 volumes: [db_data:/var/lib/postgresql/data] healthcheck: test: ["CMD-SHELL", "pg_isready -U app"] interval: 5s retries: 10 cache: image: redis:7-alpine volumes: db_data:

docker compose up -d # 启动 docker compose ps # 状态 docker compose logs -f web # 日志 docker compose down -v # 停止并删除卷（-v 慎用） docker compose up -d --build # 重建

depends_on + healthcheck 组合解决"DB 还没就绪 Web 就启动"的经典问题；服务间用服务名（db、cache）即可完成 DNS 解析。

4.7 容器内调试三板斧

docker exec -it <container> sh # 进入容器（alpine 无 bash） docker logs -f --tail 100 <container> # 日志 docker cp <container>:/app/log.txt ./ # 拷贝文件出来 docker stats # 实时资源占用 docker top <container> # 进程列表 docker inspect <container> # 完整元数据（JSON）

4.8 资源限制

docker run -d --name limited \ --memory=512m \ --memory-swap=512m \ # 关闭 swap，防内存击穿 --cpus=1.5 \ --pids-limit=128 \ --ulimit nofile=1024:1024 \ nginx:alpine

• --memory 超限容器会被 OOM kill（状态 OOMKilled），日志里能看到；
• --cpus=1.5 表示最多 1.5 核；
• --pids-limit 防 fork 炸弹。

4.9 健康检查与重启策略

# 运行期定义健康检查 docker run -d \ --health-cmd="wget -qO- http://localhost/health || exit 1" \ --health-interval=10s \ --health-timeout=3s \ --health-retries=3 \ --restart=unless-stopped \ myapp:1.0

重启策略语义：no（默认）< on-failure[:n]（退出码非 0 时重启）< always（任何退出都重启，含手动 stop 后 Docker 重启时拉起）< unless-stopped（手动 stop 的不拉起，推荐常驻服务使用）。

5. 底层实现剖析：namespace / cgroup / OverlayFS / 运行时链路

5.1 Namespace：七大隔离视角

Linux Namespace 让一组进程"只看得见"被隔离的视图。clone() 系统调用创建进程时可指定：

实验观察：docker run -it alpine ps -ef 只会看到容器内的两个进程（PID 1 与 ps 自己）；hostname 是容器 ID 前缀。这些"假象"全部来自 PID/UTS Namespace。

5.2 Cgroup：资源配额的控制组

• 控制组以树形层级组织，/sys/fs/cgroup 下每个目录对应一个控制组；
• 内存：memory.max 限制上限，超限触发 OOM；
• CPU：cpu.max（quota/period）限制核数；
• IO：io.max 限制带宽与 IOPS；
• 查看容器 cgroup：docker inspect 的 HostConfig.Memory / NanoCpus 字段，实际路径 /sys/fs/cgroup/system.slice/docker-<id>.scope。

5.3 OverlayFS：镜像分层的实现

OverlayFS 把两个目录叠加成一个合并视图：

lowerdir=/var/lib/docker/overlay2/l/<层1>,<层2>... # 只读镜像层（自底向上） upperdir=.../diff # 容器可写层 merged=.../merged # 容器看到的合并视图

• 读：先查 upper，没有则逐层向下查 lower；
• 写：写 upper；改 lower 文件 → 先复制到 upper（copy-up）再改；
• 删：upper 中放 whiteout 字符设备标记，屏蔽 lower 文件；
• 层共享：相同 digest 的层只存一份，多容器共享同一组 lower 层，这是"百个容器也只占一份基础镜像磁盘"的原因。

5.4 运行时链路：docker → containerd → runc

现代 Docker Engine 的调用链：

• dockerd：用户侧服务，负责构建、网络、卷、CLI 交互；
• containerd：CNCF 项目，标准容器运行时管理，向上兼容 K8s 的 CRI；
• runc：OCI runtime-spec 参考实现，真正"造容器"的底层程序；
• 替代品：crun（C 语言实现，更快）、gVisor（用户态内核，更强隔离）、Kata Containers（轻量 VM 隔离）、podman（无守护进程的 Docker 替代）。

5.5 镜像分发：Digest / Manifest / 拉取流程

1. 客户端请求 docker pull nginx:1.27-alpine；
2. 与 Registry 协商获取Manifest（描述镜像层列表与元数据，含多架构支持：linux/amd64、linux/arm64 等由 Manifest List 选择）；
3. 按层 digest 校验下载各层（已有层跳过——这就是"换机器拉同一镜像秒完成"的原因）；
4. 本地按 digest 存储层数据，构建 OverlayFS 视图。

镜像 tag（:1.27-alpine）是可变指针，digest（sha256:...）才是内容标识——生产环境引用镜像应尽量用 digest 或精确 tag，避免 :latest 漂移。

6. 常错点与坑（30 条）

1. 时区问题：基础镜像默认 UTC，date 显示与本地差 8 小时。解决：装 tzdata 并设置 /etc/localtime（见 4.3 示例），或 ENV TZ=Asia/Shanghai + 装 tzdata。
2. 中文乱码 / locale 缺失：alpine 缺 locale，printf 中文可能变问号；需要则装 musl-locales 或改用 debian-slim。
3. apt/apk 源慢：国内构建可换清华/阿里源，但注意在 Dockerfile 中保持可复现（固定镜像版本）。
4. COPY 与 ADD 混用：ADD 会自动解压 tar 且支持远程 URL，语义不透明；99% 场景用 COPY。
5. CMD 与 ENTRYPOINT 混用导致信号收不到：shell 形式会让 PID 1 是 sh，docker stop 的 SIGTERM 被 sh 吞掉，程序无法优雅退出。用 exec 形式（数组语法）。
6. PID 1 孤儿进程：容器内 PID 1 必须负责回收僵尸进程（reap orphans）。如果 PID 1 是业务程序且不处理 SIGCHLD，子进程会变僵尸。解决：入口脚本 exec "$@" + 陷阱函数，或引入 tini。
7. docker run 忘 --rm：调试容器堆积，docker ps -a 全是僵尸容器，占磁盘。
8. 镜像体积失控：不用多阶段构建，把编译工具链、缓存、文档全打进最终镜像（GB 级）。用 docker history / dive 检查每层体积。
9. 层缓存失效：COPY . . 放在最前面导致源码一改全链路重构建。把"变化频率低"的指令（go mod download、pip install）放前面。
10. 忘了 .dockerignore：node_modules、.git、dist 全量打进 build context，构建上下文打包慢且泄露源码。
11. alpine 没有 bash：docker exec -it alpine bash 报 exec: "bash": not found。用 sh。
12. glibc vs musl：静态二进制在 alpine（musl）能跑，但依赖 glibc 的动态库程序会报 not found/段错误。要么编译静态，要么用 debian 系基础镜像。
13. 动态链接库缺失：二进制依赖 libssl/libstdc++ 等，运行时镜像没有 → 启动即崩。多阶段构建记得 ldd 检查并拷贝依赖，或直接用带运行库的镜像。
14. 端口映射冲突：-p 8080:80 时宿主机 8080 被占 → 启动报 port is already allocated。换端口或检查占用。
15. bridge 网络下 DNS 解析不了服务名：默认 bridge 容器间只能靠 IP 互通；用自定义网络 + 服务名。
16. 容器内连不上宿主机：bridge 网络下用 host.docker.internal（Docker Desktop / 新版引擎支持）访问宿主机服务。
17. docker logs 无限增长：json-file 日志不轮转可撑爆磁盘。配置 daemon 的 log-driver + max-size/max-file，或上 json-file 轮转。
18. 数据没持久化：数据库容器不带卷重启 → 数据全丢（容器层随容器删除）。任何有状态服务必须挂卷。
19. --rm 与 -d 组合：容器退出即删，但配合 restart 策略会反复拉起，排查时误以为"没删掉"。
20. root 用户运行：容器内 root 默认映射宿主机 root，被攻破即宿主机沦陷。用 USER 非 root + --cap-drop=ALL。
21. 挂载 docker.sock：为"容器内管理容器"把 /var/run/docker.sock 挂进容器 = 把宿主机 root 交给容器。高危，禁止在不可信镜像上使用。
22. 镜像 tag 漂移：:latest 每次可能不同，构建/部署不可复现。固定版本或 digest。
23. 构建上下文过大：docker build . 会把当前目录整个发到 daemon；在空目录构建或用好 .dockerignore。
24. BuildKit 与旧构建器不一致：docker build 默认已切 BuildKit，个别历史 Dockerfile（依赖宿主环境）行为不同。用 docker buildx 显示指定。
25. 多架构镜像问题：在 x86 构建的镜像放到 ARM 机器报 exec format error。用 docker buildx build --platform linux/amd64,linux/arm64 构建 multi-arch。
26. Windows 容器与 Linux 容器混淆：Docker Desktop 可切换引擎，FROM nginx:alpine（Linux 镜像）在 Windows 容器模式下无法运行。
27. docker system df 显示磁盘爆满：镜像/容器/构建缓存堆积。docker system prune -af（慎用）或按需清理。
28. apt-get update 与 install 分两层：中间层缓存污染；应合并 RUN apt-get update && apt-get install -y ... && rm -rf /var/lib/apt/lists/*。
29. 环境变量里写敏感信息：ENV PASSWORD=... 会被 docker history 看到。用 --env-file / Compose secrets / 运行时注入。
30. 容器退出码 137/139：137 = SIGKILL（通常 OOM 或被 kill），139 = SIGSEGV（段错误，多与动态库/架构问题相关）。用 docker inspect 看 State.OOMKilled 与 ExitCode。

7. 性能优化与最佳实践

7.1 镜像瘦身清单

• 多阶段构建，最终镜像只含产物与运行依赖；
• 基础镜像选小：alpine > slim > 完整发行版；但注意 musl/glibc 取舍；
• 合并 RUN 指令减少层数（但别过度，可读性优先）；
• 清理包管理器缓存、pip cache、go build 中间文件；
• 使用 --squash（实验性）或 BuildKit 的 RUN --mount=type=cache 缓存依赖下载而不进层。

7.2 构建缓存利用

• 指令顺序按"变化频率从低到高"排列：依赖清单 → 依赖下载 → 源码 → 构建；
• 复用层缓存：docker build 自动命中未变层，配合 --cache-from 跨 CI 缓存；
• BuildKit 特性：RUN --mount=type=cache,target=/root/.cache 加速包管理器。

7.3 运行时优化

• 设置资源限制（--memory/--cpus/--pids-limit），防单容器拖垮宿主机；
• 日志轮转（daemon 配置或容器 --log-opt max-size=10m --log-opt max-file=3）；
• 根文件系统只读 + 数据卷外置：--read-only + --tmpfs /tmp，兼顾安全与临时写需求；
• 生产常驻服务用 --restart=unless-stopped + HEALTHCHECK。

7.4 安全加固要点

• 非 root 运行（USER + 基础镜像里建好用户）；
• 裁剪能力：--cap-drop=ALL --cap-add=NET_BIND_SERVICE 等最小化；
• 启用 seccomp（默认即开启，可按需 --security-opt seccomp=profile.json）；
• 只读根文件系统、禁用特权模式（--privileged 是最后手段）；
• 镜像来源可信：只从可信仓库拉取，定期用 Trivy/Grype 扫描漏洞；
• 敏感信息走 secret 机制，不写进镜像与历史。

7.5 可观测性

• docker events 订阅容器生命周期事件，对接审计；
• 容器级指标：docker stats 查看，长时监控用 cAdvisor 或节点采集器输出指标；
• 应用层日志统一 stdout，交给日志采集栈（如 Loki/ELK）集中处理——只往 stdout 写，不要写文件，这是容器日志第一原则。

8. 总结

五个要点（十秒速记）：

1. 镜像不可变、分层共享、写时复制：这是 Docker 体积小、启动快、共享省空间的根本原因；
2. 容器 = namespace（隔离视角）+ cgroup（限制资源）+ OverlayFS（分层文件系统）：理解三支柱，一切行为可推理；
3. Dockerfile 决定镜像质量：多阶段构建 + exec 形式 + 非 root + 固定版本，是生产级镜像的底线；
4. 数据与生命周期分离：有状态数据必须挂卷，容器本身可以随时重建；
5. 运行时是标准生态：OCI 标准化后，Docker/containerd/runc/podman/K8s 各司其职，标准才是长期资产。

适用场景速查：

9. FAQ

Q1：Docker 与虚拟机到底差在哪？虚拟机虚拟化硬件、每台完整 OS、隔离强开销大；容器共享宿主机内核、仅隔离用户态视图，启动快密度高。极端安全或异构 OS 需求选 VM，常规应用选容器。

Q2：docker run 与 docker start 有什么区别？run = 创建 + 启动（每次是新容器）；start = 启动已存在但停止的容器（沿用旧状态）。docker restart = 停止再启动。

Q3：为什么 docker stop 有时停不掉容器？stop 先发 SIGTERM（默认 10 秒宽限期），超时才 SIGKILL。若 PID 1 是 shell（shell 形式 CMD/ENTRYPOINT），信号可能被吞。改用 exec 形式并让程序响应 SIGTERM。

Q4：容器里改了文件，重启后还在吗？在可写层（未删除容器）时：docker restart 保留；docker rm 后重建则丢失。要持久化必须挂 volume/bind mount。

Q5：-v 与 --mount 有什么区别？--mount 语法更明确（type=volume/bind/tmpfs、source、target、readonly），新代码推荐；-v 更简洁但解析规则隐晦。

Q6：多个容器如何互相访问？同一自定义网络下用服务名/容器名即可（内置 DNS）；跨网络需 docker network connect；对外统一走宿主机端口映射。

Q7：镜像怎么瘦身？多阶段构建、精简基础镜像、合并 RUN、清理缓存、检查每层体积（docker history、dive）。目标：静态编译应用 1050MB，解释型应用 100300MB。

Q8：为什么我的镜像在另一台机器上跑不了？常见三类：架构不匹配（arm64 vs amd64，报 exec format error）；动态库缺失（glibc/musl 或链接库没拷）；基础镜像 tag 漂移导致运行库版本不一致。

Q9：docker compose down -v 会删什么？停止并删除 Compose 管理的容器、网络；-v 额外删除声明的卷——数据会丢，生产环境慎用。

Q10：需要清理 Docker 占用空间怎么办？docker system df 查看分布；docker container prune、docker image prune -a、docker builder prune 分级清理；docker system prune -af 全清（慎用）。

Q11：容器内如何拿到宿主机 IP / 访问宿主机服务？bridge 网络下用 host.docker.internal；host 网络模式直接用 127.0.0.1；跨主机部署则用服务发现（K8s Service/DNS）。

Q12：Windows 上 Docker 的本质是什么？Docker Desktop 的 WSL2 后端实际是在轻量 Linux VM 里跑 Docker Engine，容器仍是 Linux 容器；Windows 容器（native）需要 Windows Server 容器镜像，两者互不通用。