企业官网建设流程全解析

平时排查问题、部署服务，我最依赖的工具里，Docker 绝对排前三。它把应用、环境、配置全部打包成标准单元，终于让“在我机器上好好的”这类老问题有了统一的解法。今天不聊 Dockerfile 怎么写高大上，也不聊集群编排平台，只把日常摸爬滚打里最常用的 Docker 常用指令完整过一遍，从容器生命周期、镜像管理到网络数据卷和 Compose 编排，每一组都带上我的使用习惯和踩坑记录，方便你随时查、抄、改。

内容会偏实战，默认你已经装好了 Docker 环境。如果你正在学习或维护云主机，这套指令绝对是最高频的骨架。遇到命令记不清，直接看对应小节；遇到容器退不出、镜像删不掉、磁盘被日志打满，跳到最后那节排查清单就行。

1. 啃指令之前，先把基础视图搭起来

1.1 确认版本和环境健康度

很多奇怪的问题，第一章其实是版本不对。Docker 分为客户端和服务端两部分，平时敲docker version两条信息会一起显示，但经常被人忽略：如果你本地 Docker 命令是新版，而远端服务端还是老版本，某些参数就可能不支持，表现出的症状往往是“同样的命令别人能用，我这报错”，或者“参数没反应”。

我每次接手新环境，第一件事就是跑三条命令：

docker version # 查看客户端和服务端版本 docker info # 查看系统、存储驱动、运行容器数等环境信息 docker system df # 查看镜像、容器、数据卷、构建缓存占了多少磁盘

docker info里有两个关键信息要看：一个是 Storage Driver，现在绝大多数是 overlay2；另一个是 Server Version。这两个和故障排查直接相关。比如容器读写性能异常，或者镜像层合并行为不符合预期，基本都会先怀疑存储驱动。

docker system df很多人不爱敲，但它是磁盘爆炸前的预警器。它会告诉你多少空间被镜像占用，多少被可写层占用，多少是被停止的容器占着，还有多少是 Build Cache。在连续构建很多次镜像之后，Build Cache 膨胀起来非常夸张，有时候比镜像本身还大。养成每周看一眼的习惯，比等到服务器告警再救急舒服得多。

1.2 先把命令行语法框架装进脑子

Docker 命令的通用结构是：

docker [全局选项] 子命令 [子命令选项] [参数]

全局选项常用的有-H指定服务端地址、--tlsverify启用 TLS 认证，单机场景很少用到。真正高频的是各个子命令的参数，例如docker run -d --name nginx nginx:1.26中，run是子命令，-d、--name是子命令选项，nginx是镜像名。

理解这个框架后，你会发现 Docker 的指令设计很有规律。很多子命令之间是互补关系：镜像是模板，容器是运行实例；pull负责拉取，build负责制作，run负责启动，commit负责从容器生成新镜像；save/load用于离线迁移，export/import用于平铺打包。把它们按场景分组，而不是单个单个死记，效率会高很多。

我个人的记忆线索是四组：

• 处理容器：run、start、stop、restart、rm、pause
• 处理镜像：pull、images、build、tag、push、rmi
• 处理网络和卷：network、volume、port、cp
• 组合管理：compose、stack

后面每个章节就按这套分组展开，遇到不会的随时回来翻。

2. 容器生命周期：最高频的一组指令

2.1 容器创建与启动：run里的隐藏学问

docker run是绕不过去的第一条指令。它本质上做了好几步：先检查本地有没有对应的镜像，没有就走pull；然后基于镜像创建一个可写容器层；再启动这个容器，最后默认把终端接到容器的标准输入输出上。

所以这条命令的参数非常密集。给你看一条我常用的相对完整版本：

docker run -d \ --name nginx-web \ -p 8080:80 \ -v /home/data:/usr/share/nginx/html \ -e TZ=Asia/Shanghai \ --restart unless-stopped \ --network my-net \ nginx:1.26

逐个拆解一下：

• -d：后台运行，终端不用一直挂着。不加的话前台运行，Ctrl-C 或退出终端，容器就会被终止（除非配置了其他策略）。
• --name：给容器起名字。不指定的情况下 Docker 会随机生成一个名字，排查问题时不好认，能起名尽量起名。
• -p 8080:80：把宿主机的 8080 端口映射到容器的 80 端口。这个参数可以写多组，例如-p 3000:3000 -p 8080:80。
• -v /home/data:/usr/share/nginx/html：目录挂载。宿主机目录和容器目录一一对应，容器里的文件修改会直接写回宿主机，这是数据持久化的核心手段。
• -e TZ=Asia/Shanghai：注入环境变量。很多镜像都需要通过环境变量配置初始密码、时区、运行模式。
• --restart unless-stopped：自动重启策略。这个参数比我预想的重要得多，生产环境里我几乎每台容器都会带上。它的语义是：容器异常退出时自动拉起，但如果是被手动stop的，则不会再拉起来。
• --network my-net：加入指定网络。容器默认在 bridge 网络里，独立网络可以方便容器间用名字互访。

还有一个好用参数是--rm，表示容器停止后自动删除。临时跑一条命令、调试一个脚本时特别合适，比如：

docker run --rm -it ubuntu:22.04 bash

退出 shell 后容器立刻消失，不会留一堆垃圾容器。但注意，如果你同时用了-d和--rm，容器后台运行，停止时同样会触发自动删除，千万别把它和经济型-d搞混。

2.2 查看、进入容器内与日志追踪

容器起来了，接下来要看状态、看日志、进容器内部操作。docker ps是最常用的查询指令：

docker ps # 只看运行中的容器 docker ps -a # 查看所有容器，包含已停止的 docker ps -q # 只输出容器 ID docker ps -a --filter "name=nginx-web" # 按名字过滤 docker ps --filter "status=exited" # 只看已退出的容器

我实际使用中，-q和--filter的搭配很强。清理资源时可以快速拿到一批容器 ID，直接传给删除指令：

docker rm $(docker ps -aq --filter "status=exited")

连贯操作比一条条点确认舒服得多。查看日志用docker logs：

docker logs nginx-web # 查看全部日志 docker logs -f nginx-web # 实时跟踪，类似 tail -f docker logs -f --tail 200 nginx-web # 只跟踪最近 200 行 docker logs -t nginx-web # 每行带时间戳

容器启动失败时，第一时间看日志几乎能定位 80% 的问题。先确认容器是否真的起来了，再确认日志内容，不要一上来就重构或改文件。

进入运行中容器内部，最常用的是：

docker exec -it nginx-web bash

-i表示保持标准输入打开，-t分配一个伪终端，合在一起才能进入交互式 shell。如果容器镜像比较精简，没有 bash，就换成sh。还有docker attach，它会把终端挂到容器的主进程上，但一旦你按 Ctrl-C，容器主进程可能会收到 SIGINT 而退出。生产环境我基本不用 attach，需要交互和调试时一律走exec。

另外几个实用指令顺手提一下：

docker top nginx-web # 查看容器内的运行进程 docker port nginx-web # 查看端口映射关系 docker diff nginx-web # 查看容器内文件系统的新增、修改和删除 docker cp 宿主机文件 nginx-web:/容器路径 # 拷贝文件进出容器

docker diff容易被忽略，但它对排查“容器运行后到底改了哪些系统文件”非常有用。某个镜像被篡改、或者你在容器里手滑改了配置文件，都能通过它快速定位差异。

2.3 停止、删除与批量清理的安全操作

停容器有讲究。docker stop给容器主进程发送 SIGTERM，让它优雅退出，等待默认 10 秒后再发送 SIGKILL 强制杀死。如果应用有收尾逻辑，比如写缓存、保存状态，它会在这 10 秒内完成。docker restart同理，只是多一步重启。

docker stop nginx-web docker start nginx-web docker restart nginx-web docker pause nginx-web # 暂停容器中所有进程，但容器仍在运行 docker unpause nginx-web # 恢复 docker rm nginx-web # 删除容器，删除前最好先 stop docker rm -f nginx-web # 强制停止并删除

pause和stop很多人分不清。pause 只是冻结进程，容器状态依然显示 Up（Paused），内存和文件系统都保留，适合暂时挂起，比如做备份、做一致性检查。stop 是真正把主进程结束，再启动时会以原状态重新开跑。

清理容器时我最常用的批量命令是：

docker container prune # 清理所有已停止的容器

它会提示你要删除的容器列表，确认后才动手。如果想一次性连确认都不打，加-f。批量删所有容器（包括运行中的）比较危险：

docker rm -f $(docker ps -aq)

这条命令一定要想清楚再执行。它会把机器上所有容器全部干掉，常用于清场重来。在测试机无所谓，在生产线就要慎重，我习惯先跑docker ps -a看一遍再执行。

3. 镜像管理：拉取、构建、导出与瘦身

3.1 镜像搜索、拉取与标签规范

镜像就是容器的模板文件系统。docker pull负责从仓库拉取：

docker pull ubuntu:22.04 docker pull nginx:1.26

如果不指定 tag，默认拉latest。latest是个方便但危险的标记，因为它会指向最新版本，每次拉取可能内容都不一样。我个人的线上规则是：所有正式环境镜像必须锁定精确版本号，无论是nginx:1.26还是postgres:16.2，都不允许裸用latest。这样升级可控、回滚也方便。

了解仓库里有哪些镜像可以用：

docker search nginx docker images # 列出本地镜像 docker image ls -a # 包含中间镜像层

docker search用于在 Docker Hub 上搜镜像名，但能看到的信息有限，关键指标是官方源标记（OFFICIAL）和星标数。生产环境优先选择官方源，其次选更新时间近、星标记较大的维护版本。

镜像命名规则看起来简单，却常有人踩坑。完整镜像名格式是：

[仓库地址/命名空间/]镜像名[:标签]

缺省仓库地址时默认 Docker Hub，缺省命名空间时默认library（官方源）。例如nginx:1.26实际就是docker.io/library/nginx:1.26。自建仓库时，镜像名要带上仓库地址，比如my-registry:5000/app/web:1.0。构建和推送时最容易在这块出错。

3.2 构建镜像：build、tag、push的完整链路

本地写好了 Dockerfile，一条docker build就能生成镜像：

docker build -t myapp:1.0 .

-t指定镜像标签，后面的.是构建上下文路径。所谓构建上下文，就是把该目录下所有文件打包发送给 Docker 守护进程，用于解析 Dockerfile 中的COPY和ADD。所以平时别把大型临时文件、node_modules、缓存文件放进构建目录，避免镜像构建变慢、变臃肿。

调试构建时，常用两个参数：

docker build --no-cache -t myapp:1.0 . # 完全重新构建，命令不缓存 docker build --target build-stage -t myapp:1.0 . # 只构建多阶段中某个阶段

--no-cache在依赖更新出问题或 Dockerfile 的缓存策略异常时很好用。--target用于多阶段构建的调试阶段，比如只想编译产物，不想一直完成最终精简阶段。

生成新镜像的另一条指令是docker commit，它会把一个运行中容器的当前文件系统状态保存为新镜像。这个方法能跑，但我强烈不建议作为常规手段，因为它会把容器运行中的脏状态、历史操作全打包进去，镜像内容不可控，也无法复现。我只有在极特殊情况下，比如辅助排障复盘，才会用它做一次性归档。

镜像打标签和上传：

docker tag myapp:1.0 my-registry:5000/library/myapp:1.0 docker push my-registry:5000/library/myapp:1.0

tag不复制镜像内容，只是给镜像增加一个引用。同一个镜像 ID 可以有多个 tag，删除其中一个 tag 不会影响镜像实体；只有所有 tag 都删掉后，镜像才会真正被清理。

离线环境迁移常用：

docker save -o myapp.tar myapp:1.0 # 把镜像打包成 tar 文件 docker load -i myapp.tar # 从 tar 文件导入镜像

save保存的是镜像层完整历史，load后能保留 tag 和构建信息，适合跨机器共享整套镜像。还有一组export/import：

docker export -o container.tar nginx-web # 把容器文件系统导出 docker import container.tar myapp:imported # 导入为镜像

export是把容器当前文件系统全部平铺出来，原有分层信息和历史记录全部丢失，导入后是一个扁平的镜像。前者适合镜像分发，后者适合“截取当前容器状态”做快照，两者不要混用。

3.3 镜像删除、历史审查与空间瘦身

删除镜像用docker rmi：

docker rmi nginx:1.26 docker image rm myapp:1.0

如果发现删不掉，大概率是有容器还在引用这个镜像，哪怕容器已经停止。Docker 的引用关系是：容器存在于镜像之上，只要容器没删除，镜像就无法释放。所以正确的删除顺序是：先删容器，再删镜像。

批量清理悬空镜像（dangling images）非常有用。悬空镜像指没有被任何 tag 引用、只剩\<none\>的镜像层，通常是多次 build 后残留的中间产物：

docker image prune docker image prune -a # 删除所有未被容器使用的镜像，要谨慎

我处理大型磁盘占用时，会先跑docker system df看分布，然后分类型清理。整体一条命令：

docker system prune -a --volumes

这条命令会把停止的容器、无用网络、悬空镜像、未使用的构建缓存全清掉，如果加了--volumes，连同未使用的数据卷一起干。除非确认机器上所有数据都不再需要，否则不要带--volumes，我见过有人图省事把重要卷删了，后面再也找不回。

查镜像构建历史和信息：

docker history myapp:1.0 # 查看镜像每一层的构建指令及大小 docker inspect myapp:1.0 # 查看镜像配置、环境变量、入口、卷等详细信息

history是排查镜像体积的关键入口。看到某一行容量特别大，基本就能锁定是哪个 RUN 阶段引入了大量文件，随后可以针对性做清理或多阶段拆分。inspect输出的 JSON 很长，我通常只关心某几个字段：

docker inspect -f '{{.Config.Env}}' myapp:1.0 docker inspect -f '{{.Config.ExposedPorts}}' myapp:1.0

这种格式化输出比整个 JSON 翻找舒服很多，适合写脚本批量提取配置。

4. 网络与数据卷：让容器不再“孤立”

4.1 端口映射与网络模式，到底在映射什么

默认情况下，容器内部是独立的网络命名空间，宿主机访问不到它，外部更访问不到。端口映射-p就是在宿主机和容器之间做一道转发规则。三种写法需要分清楚：

-p 8080:80 # 将宿主机的 8080 映射到容器的 80 -p 8080:80/tcp # 指定 tcp 协议，默认就是 tcp -p 127.0.0.1:8080:80 # 只允许本机访问宿主机的 8080，更安全

如果你用-P（大写），Docker 会把容器内暴露的端口随机映射到宿主机高位端口，适合临时测试。但生产环境我基本不碰大写-P，因为端口不确定性太强，维护困难。

Docker 有多种网络模式。最常见的几个：

• bridge：默认，容器通过虚拟网桥与宿主机通信，容器间默认隔离。
• host：容器直接使用宿主机网络栈，没有端口映射，性能高，但隔离性差。
• none：容器没有网络，只有回环接口，适合跑纯计算任务。
• 自定义网络：使用docker network create创建，支持容器间 DNS 自动解析。

和网络相关的指令组是：

docker network ls # 列出网络 docker network create -d bridge my-net # 创建 bridge 自定义网络 docker network connect my-net nginx-web # 把运行中的容器加入网络 docker network inspect my-net # 查看网络详情 docker network disconnect my-net nginx-web

自定义网络是我强烈建议优先使用的方案。它的最大特点是同一个网络里的容器可以用容器名直接互相访问，而不需要依赖局域网 IP。比如后端容器里访问数据库，可以直接postgres:5432，IP 变了也没事。如果用默认 bridge 网络，容器之间只能通过 IP 互访，而 Docker 容器 IP 重启后会变，维护难度直线上升。

4.2 数据卷和数据挂载：容器可以删，数据不能丢

容器删除后，可写层会跟着被销毁。如果应用把状态写在容器内部，比如数据库文件、上传的图片、日志文件，容器一删这些数据就全部蒸发了。所以数据必须持久化到容器外部。

Docker 提供两种主流方式：

U1. 数据卷（Volume），使用-v 卷名:/容器路径。

docker volume create mydata docker run -d --name app -v mydata:/data app:latest docker volume ls docker volume inspect mydata

数据卷由 Docker 管理，存储在宿主机特定目录下，有统一的文件组织。推荐在需要跨容器共享数据、不需要直接操作宿主文件时使用。

2. 绑定挂载（Bind Mount），使用-v /宿主机路径:/容器路径。

docker run -d --name web -v /home/web/html:/usr/share/nginx/html nginx:1.26

绑定挂载直接把宿主目录映射进容器。好处是在宿主机上就能直接改文件、读日志、备份数据，非常直观。坏处是目录位置一旦移动，容器就得重建，对宿主机目录权限也更敏感。

还有一种更推荐的写法是--mount：

docker run -d \ --name web \ --mount type=bind,source=/home/web/html,target=/usr/share/nginx/html \ nginx:1.26

--mount的键值对清晰，支持readonly等选项，比-v更容易读明白，特别是选项多的时候。

数据卷删除需要格外小心：

docker volume rm mydata docker volume prune # 删除所有没有被任何容器引用的卷 docker volume prune -a

volume prune会清掉没有容器使用的卷。问题是，容器被删除后卷虽然还在，但你根本没有提示说哪些是重要的、哪些是垃圾。所以我每次手工清理卷之前，都会先docker volume ls加docker volume inspect看一遍，确认没有生产数据混在里面。用一句话总结我的习惯：容器可以随时删，镜像可以重新拉，卷里的数据一旦没了，神仙难救。

5. Docker Compose 指令：一套命令管理一组服务

5.1 启动与停止：up、down、restart

单容器用上面的指令就行，但多服务项目（应用、数据库、缓存、队列）再用一长串docker run就太折磨了。Compose 解决的是“一组容器”协同管理的问题。它通过一个 YAML 文件描述服务、网络、卷，然后用一条指令完成整体启停。

最核心的是：

docker compose up -d docker compose down

up -d会根据当前目录下的compose.yaml（或docker-compose.yaml）创建网络、拉取/构建镜像、启动所有服务。-d表示后台运行，不带它时前台运行，日志会直接滚到你终端上，Ctrl-C 会停掉所有服务，适合调试。

down默认会停止并移除由 compose 创建的所有容器，还会删除默认生成的网络。注意，它不会删除数据卷（除非显式带-v）。

docker compose down # 停止并移除容器和网络 docker compose down -v # 额外删除数据卷，数据无，慎用 docker compose down --rmi local # 额外删除本地构建的镜像

如果只是临时停一下服务，又不想拆掉网络和容器，用：

docker compose stop # 停止所有服务，容器和网络都保留 docker compose start # 重新启动已停止的服务 docker compose restart # 重启所有服务

这个组合在日常开发中比down更常用，因为保留容器意味着再次启动速度更快，卷和网络状态也基本保持。

Compose 文件示例不用太长，我给一个能跑通的最小结构：

services: web: image: nginx:1.26 ports: - "8080:80" volumes: - ./html:/usr/share/nginx/html app: build: . environment: - DB_HOST=db db: image: postgres:16 volumes: - dbdata:/var/lib/postgresql/data volumes: dbdata:

在这个结构下，只需两个指令就能完成整套环境的拉起和销毁：

docker compose up -d docker compose down

绝大多数的本地联调场景，这两条指令足够。

5.2 查看、调试与校验：ps、logs、exec、config

Compose 模式下，不推荐再挨个用docker ps、docker logs去查单个容器，虽然能查到，但太麻烦了。有更贴合场景的指令：

docker compose ps # 只显示 compose 管理下的服务状态 docker compose logs -f --tail 100 # 查看整个项目的日志，-f 实时跟踪 docker compose logs web # 只查看某个服务日志 docker compose exec web bash # 进入某个服务容器 docker compose top # 查看各服务容器内进程

这里有一个容易踩坑的点：docker compose logs是按服务名过滤的，不是按容器名。在docker logs -f 容器ID里你要找容器名，但在 Compose 里直接用服务名，写错名字会提示不知道这个服务。

还有一个经常被遗忘但非常实用的指令：

docker compose config

它会把你当前目录的 compose 文件解析并输出最终配置。出现 YAML 缩进错误、字段拼错、环境变量格式不对等问题时，config是最快的检查手段。如果文件有问题，它会直接指出哪一行不合法。

在修改 compose 文件后，完整生效需要重新加载：

docker compose up -d

不要随手就down再up。对于配置变更，直接up -d就足够，它只会重建配置变动的服务，其他服务保持不动。这套“增量更新”逻辑比“全量重启”高效且风险低。

Compose 也支持查看事件流和资源统计：

docker compose events # 流式显示容器生命周期事件 docker compose cp web:/data/log.txt ./log.txt

cp在 Compose 下同样好用，只不过第一参数是“服务名:路径”，不需要记容器 ID。

6. 实际踩坑与排查技巧实录

6.1 容器启动失败，到底该怎么定位

容器一启动就退出，新手常见操作是反复run、反复看日志，但定位效率很低。我给你一套固定排查路径。

第一步，确认容器当前状态：

docker ps -a

如果有个容器状态是 Exited (1)，说明主进程退出并传出了状态码。1 通常代表通用错误，137 是被 SIGKILL 杀了，143 是被 SIGTERM 正常终止。状态码能提供第一层线索。

第二步，看日志：

docker logs --tail 200 --timestamps 容器名

日志里常出现配置文件路径不对、依赖连接不上、权限不足、端口被占用等问题。如果完全没有日志，多半是主进程直接被 signal 杀掉，或者应用在前台模式下没有成功绑定。

第三步，用 inspect 看宿主机视角的信息：

docker inspect 容器名 docker inspect -f '{{.State.ExitCode}}' 容器名 docker inspect -f '{{.HostConfig.PortBindings}}' 容器名

重点看State、Error、HostConfig。有时候端口映射已经占了，容器启动后立即拒绝监听，报错反而不会出现在应用日志里。

还有一个非常常见的原因：容器主进程是前台进程，但 Docker 要求容器必须有一个持续运行的前台进程。如果你的镜像里写的是CMD tail -f /dev/null这类占位命令，它没问题；但如果写了后台启动命令，容器可能秒退，因为主进程结束就等于容器结束。排查时先问一句：容器的 PID 1 是什么。

6.2 磁盘被容器日志撑爆，怎么快速止血

运行中的容器会产生大量日志，Docker 默认不限制日志文件大小，时间一长/var/lib/docker/containers/...下面的日志文件会飙到几十 GB。最直观的预判指令是docker system df，如果看到容器可写层和日志占用异常大，就要立刻处理。

常用的手工清理方式：

truncate -s 0 $(docker inspect -f '{{.LogPath}}' 容器名)

这条命令会把指定容器的日志文件直接清空，可以临时止血，但治标不治本。更推荐在创建容器时就限制日志上限：

docker run -d --log-opt max-size=10m --log-opt max-file=3 nginx:1.26

在 Compose 文件里同样可以配置：

services: web: image: nginx:1.26 logging: driver: json-file options: max-size: "10m" max-file: "3"

配置之后每个日志文件最多 10 MB，最多保留 3 个，滚动轮换，不会无限膨胀。这是我认为性价比最高的磁盘保护手段，比事后清理强太多。

6.3 拉取镜像慢或失败时，先别急着反复 pull

拉取镜像超时，最常见的是公共仓库连通性受网络环境影响。很多人第一反应是重试，但重试只能缓解不能根治。除了等待网络恢复，更有效的方法是配置镜像加速器。

在 Docker 配置文件中添加registry-mirrors，把公共仓库请求转发到可用加速地址，可以显著提高pull成功率。配置后记得重启 Docker 服务，然后重新pull测试。

如果配置了镜像加速仍然拉不动，建议检查这几项：

docker info | grep -i registry-mirror # 如果配置成功，会显示加速地址 ping 对应域名 # 检查基础连通性

另外注意架构差异。在 ARM 服务器上拉 x86 镜像，或者反过来，会报错或者运行直接崩。明确指定平台拉取：

docker pull --platform linux/amd64 ubuntu:22.04 docker pull --platform linux/arm64 ubuntu:22.04

这个参数在异构服务器运维时特别重要。如果一个镜像同时支持多种架构，平台不对会干扰判断。

6.4 误删容器和数据卷后，还有救吗

先把最残酷的结论讲在前面：数据卷被删除后，没有常规恢复手段。无论用什么工具，丢失的数据都很难找回来。所以我强烈建议整个团队约定一条规则：关键数据一定要使用绑定挂载，放在宿主机明确目录，而不是藏在一个匿名卷里。这样即使容器全被清理，目录备份、同步、迁移都还在可控范围内。

如果只是误删容器，情况相对乐观。镜像还在的话，重新docker run一个同样配置的容器就能恢复服务。麻烦的是配置参数没了，所以我建议所有重要服务尽量用 Compose 描述，而不是靠一串手打的docker run参数。参数写进 YAML 文件后，容器再删，只要文件还在，原地up -d就能拉起来。

docker cp也可以当作“生命线”来用。我习惯在重要容器运行稳定后，定期从容器里拷贝关键配置出来：

docker cp nginx-web:/etc/nginx/nginx.conf ./backup/nginx.conf

虽然直接用卷挂载更便于管理，但在某些“容器内部动态生成配置”的场景下，这种定期备份的做法能避免很多尴尬。

根据我个人的踩坑经验，最稳妥的组合是：重要数据全部绑定挂载到宿主机目录，所有服务参数写进 Compose 文件，日志配置max-size限制，每周执行一次docker system df检查空间。平时不需要背所有命令，只要知道每组指令解决什么问题，遇到场景能想起来“该去翻哪一章”，就比硬背命令强很多。这组指令是骨架，实际业务往里面填充流程就行，但无论如何，别在数据卷这件事上偷懒，那是 Docker 使用中最贵的学费。