作为一个几乎每天都在跟 Docker 打交道的人，我越来越觉得，真正的工作流核心其实就那么二三十个命令。网上教程一搜一大把，但大多是把docker --help翻译一遍，看完记不住，用起来还是懵。这篇文章不搞那种词典式的罗列，我把日常用得最狠、频次最高、以及最容易踩坑的命令重新梳理一遍，按使用场景组织，每个命令都说说它解决什么问题，以及为什么用这个参数而不用别的。内容基于我在实际项目里的操作经验，适合刚上手 Docker 不久、想从“会用”进阶到“用得顺手”的朋友，也适合已经写了一阵子 Dockerfile 但总感觉命令体系有点散的人。看完你可以直接照着敲，把这一套固化下来，日常开发部署基本够了。
1. 镜像与容器的“生命周期”：先把命令体系和底层关系理顺
很多人头疼记不住命令，本质上是没把 Docker 的几个核心对象的关系理清楚。镜像（Image）、容器（Container）、数据卷（Volume）、网络（Network），这四样东西构成了日常操作的全部对象。镜像是一个只读模板，容器是镜像运行后生成的实例，数据卷负责数据独立存储，网络解决容器间通信。这个逻辑理顺了，命令就成体系了。
镜像层面，日常最高频的就是docker pull、docker images、docker rmi和docker build。容器层面，就是docker run、docker ps、docker start/stop/restart、docker rm、docker exec、docker logs。这套组合拳能覆盖 80% 的日常工作。
实际操作里有一个特别容易绕晕的点：docker run和docker start到底什么区别。我用一句话总结：run = create + start，是新建容器并启动；start是启动一个已经存在的容器，这个容器要么是之前停了，要么是利用docker create单独创建的。后者极少用，但要理解两件事是分开的。另外，docker ps默认只显示运行中的容器，想看到所有容器（包括已经退出的）必须加-a，这也是初学者第一个容易栽的坑。
docker rm只能删已经停止的容器，运行中的要用docker rm -f强制删，但生产环境我建议养成“先 stop 再 rm”的习惯，直接-f省事，可是会给业务一个不优雅的收尾。之前维护一个支付回调服务，某次线上操作图省事直接rm -f，数据库连接池里的连接瞬间全断，对端重试机制又不完善，造成了几分钟的事务超时。从那以后，凡是涉及有状态服务的容器，我从来不用-f，一定先stop，等个几秒，再rm。这个习惯建议你也有。
再说一个高层级的概念：容器生命周期内数据默认无法持久化。容器没了，它内部文件系统里写入的东西（日志、临时文件、数据库数据）也一起没了。这就自然引出了数据卷的需求，后面专门展开。
2. 镜像操作：从拉取到构建的完整实操命令
镜像这块，日常的“增删查改”也有自己的完整链路。docker pull是入口，docker images查本地列表，docker rmi清理，docker build是自制镜像的核心手段。这几个命令单独看都很简单，但放在一起用的时候，有些细节需要有意训练手感。
先把最常用的几个列出来，配合真实场景说明：
docker pull nginx:1.24-alpine，拉取指定标签的镜像。alpine版本体积小、依赖少，适合作为运行环境。能用alpine就不要用默认的latest，否则本地镜像会膨胀得很厉害。我之前一个服务器上光node镜像就占了十几个G，全部换成alpine系列之后，直接瘦身到不到四个G。docker images查看本地镜像列表。这个命令建议和--digests搭配用，能显示镜像摘要，确认线上跑的到底是哪次构建的产物。多环境发布时，如果镜像 tag 不唯一，靠 digest 是最可靠的办法。docker rmi删除镜像。如果镜像被容器引用，会直接报错，提示你先删容器。这个设计是保护机制，防止你删了镜像之后容器启动不了。还有一种“悬空镜像”（就是<none>:<none>），那是重复构建时老镜像失去 tag 的产物，可以用docker image prune一把清掉。我有个习惯，每次连续构建完一组镜像后，会顺手跑一次docker image prune -f，释放掉中间层产生的悬空镜像，服务器磁盘压力会小很多。
构建相关的命令放一块说，因为build是最想让人吐槽的环节，但日常用法有固定的套路。
先看一个最常见的场景：你在项目目录下写好 Dockerfile，执行：
docker build -t myapp:1.0.2 .-t指定镜像名和 tag，.表示使用当前目录作为构建上下文。很多新手在这理容易误会：docker build不是只照着 Dockerfile 干活，它会先把整个目录打包发送给 Docker 守护进程，然后由守护进程在本地构建引擎中执行 Dockerfile 指令。如果目录里有node_modules这种巨型目录，就算 Dockerfile 里没用它，也一样会被完整发送一遍，构建过程就会变得异常慢。
遇到这种问题有两个方案。第一，在项目根目录放一个.dockerignore文件，把node_modules、build、dist、.git这种不需要进入上下文的目录统统忽略掉：
node_modules dist build .git *.log .DS_Store第二，老版本的构建方式docker build是默认引擎，新版本推荐用docker buildx build加 BuildKit 引擎，提速效果明显，尤其是并行处理多个构建阶段时。Docker Desktop 和较新版本的 Docker Engine 已经默认启用 BuildKit 了，所以直接写docker buildx一般没问题。
实际项目里，如果有多阶段构建需求，Dockerfile 里会频繁使用FROM xxx AS builder这种层级的写法，这时候构建缓存的作用会非常明显。日常操作上，养成一个习惯：除非 Dockerfile 有根本性变更，只改源代码重新构建，用docker build --cache-from或者直接利用默认缓存，构建速度会快一个量级。甚至在你确定依赖没有变更时，可以考虑docker build --no-cache强制跳过缓存做一次“干净构建”，但这会比较慢，通常只在 Dockerfile 或依赖版本出现异常时才用。
镜像的导入导出也是一个冷门但关键的命令对：
docker save -o myapp.tar myapp:1.0.2 docker load -i myapp.tar内网部署、离线环境、或者要把镜像完整迁移到另一台服务器时，靠这两条命令。save是打包，load是导入。需要注意，docker save打包的是整个镜像（含全部分层和元数据），而docker export导出的是容器根文件系统，二者不要混。迁移镜像只认save/load这套组合。
3. 容器操作：run、ps、exec、logs 的高频用法与参数详细拆解
容器层面的命令是日常最高频的基石。先把docker run的参数组合讲透，因为它一个命令承载了镜像运行的全部配置：端口映射、数据卷挂载、环境变量、网络模式、重启策略。这些参数混合在一起，只有拆开逐个理解，才能不看--help情况下直接写出可用命令。
一个最常见的运行命令长这样：
docker run -d --name nginx-app \ -p 8080:80 \ -v /data/html:/usr/share/nginx/html:ro \ -e TZ=Asia/Shanghai \ --restart=always \ nginx:1.24-alpine逐项拆开讲：
-d：后台运行容器，不占用当前终端。调试阶段不要用-d，直接用-it前台运行，日志直接打在终端上，方便观察。--name：给容器起名，比如nginx-app。起名很重要，后面exec、logs、stop、rm都可以直接用名字，不用查容器 ID，效率高很多。-p 8080:80：端口映射，宿主机端口:容器端口。注意顺序，左边是宿主机，右边是容器内端口，方向搞反了就会发生请求找不到端口的问题。同一个宿主机端口不能同时映射给两个容器。-v /data/html:/usr/share/nginx/html:ro：目录挂载，把宿主机目录映射到容器目录。:ro表示只读，防止容器内进程篡改宿主机文件。这个设计在生产环境非常实用，一份静态资源同时挂给多个容器时，只读权限能防误操作。-e TZ=Asia/Shanghai：环境变量。时区问题是最常见的一种坑，基础镜像默认多是 UTC 时区，容器内时间跟北京时间差八小时。只要不是对时区有特殊要求的场景，启动时一律带上这个变量。--restart=always：容器退出后自动重启，顺势覆盖了服务器重启后容器自动拉起的需求。这是生产环境的基础设定。灵活度高一点用unless-stopped，它的区别是：你自己手动 stop 过的容器，下次服务器重启时不会自动拉起，而always会。我个人偏向unless-stopped，避免杀了一个维护中的容器，重启机器后又自己跑起来。
容器列表查询也有讲究：
docker ps显示运行中的容器；docker ps -a显示所有容器，包括已停止的。这个-a参数非常常用。调试时，容器因为错误退出，docker ps里看不到，会让人困惑为什么服务没起来。这时候第一反应就是docker ps -a，找到那个 Exited 状态的容器，再结合docker logs排查。
给ps加--format可以定制输出列，我习惯用一行精简格式：
docker ps -a --format "table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}"这样输出更紧凑，容器状态和端口映射一览无余。脚本里要拿容器 ID 或状态时，这种格式配合awk是最顺手的方案，比如：
docker ps -a --format "{{.ID}} {{.Names}}" | grep nginx容器运行时进入内部排查问题，靠docker exec：
docker exec -it nginx-app /bin/sh-i保持标准输入打开，-t分配一个伪终端。两个参数组合使用才能得到一个可交互的 shell。如果是 Alpine 基础镜像，只有/bin/sh，没有 bash，直接写/bin/bash会报错找不到文件。这是新手常踩的坑，看到 bash 报错先别慌，换成 sh 就好。
docker logs是排查容器日志的入口，最常用的几种用法：
docker logs nginx-app # 查看全部日志 docker logs --tail 100 nginx-app # 看最近100行 docker logs -f nginx-app # 实时跟踪日志，类似 tail -f docker logs --since 30m nginx-app # 看过去30分钟的日志docker logs看不到日志，通常不是命令的问题，而是应用把日志写到了容器内的文件里而没有输出到 stdout。容器里跑 Node 或者 Python 应用，要把日志用 console 方式输出到标准输出，Docker 日志机制才能采集到。如果应用已经写进了文件，硬要看的话只能exec进去，用tail看容器内文件。
容器清理是很容易被忽略但必须做的一件事：docker rm只能删停止的容器，docker rm -f能强删运行中的容器。批量清理停止的容器：
docker container prune -f这个命令会删除所有处于停止状态的容器。如果只想删一条，docker rm 容器名。批量删除指定名称匹配的容器，可以配合 filter：
docker rm $(docker ps -aq --filter "status=exited")注意$(...)内层列出所有 Exited 状态的容器 ID，外层依次删除。这个组合在清理积压容器时非常好使，我几乎每周都会跑一次。
4. 数据卷与网络管理：容器持久化和互通的关键操作
容器销毁后数据不丢的秘密全在数据卷。Docker 提供了三种挂载方式：bind mount、named volume、tmpfs。日常里最常见的两种操作是 bind mount 和 named volume，这两个的区别和适用场景需要真正理解。
bind mount 就是上面run命令里的-v /宿主机路径:/容器路径，比较适合开发阶段实时同步代码、配置文件，或者把日志写到宿主机指定目录。但生产环境有个问题：宿主机目录依赖具体机器路径，迁移、备份都要额外处理。
named volume 的做法是让 Docker 管理数据目录：
docker volume create appdata docker run -d --name pg-db -v appdata:/var/lib/postgresql/data postgres:15这里appdata是卷名，Docker 会自动在它的数据目录下创建对应路径，保存到/var/lib/docker/volumes/appdata/_data。但注意，数据卷在容器删除后默认不会自动删除，这让数据可以在容器重建后继续保留，也正是我们要的持久化效果。
管理数据卷有三个高频命令：
docker volume ls：查看所有卷。docker volume rm <卷名>：删除卷，但会拒绝删除被容器引用的卷。docker volume prune：删除所有未被任何容器引用的卷，这个命令会释放磁盘空间，但加-f前先确认没有需要保留的卷。我处理过一次prune把旧版本遗留的 PostgreSQL 数据卷清掉的场景，那次直接导致恢复困难，教训非常深刻。
备份数据卷的正确思路：容器还在跑没关系，直接用 tar 打包卷目录。比如备份 appdata 卷：
docker run --rm -v appdata:/data -v $(pwd):/backup alpine tar czf /backup/appdata.tar.gz -C /data .这个命令临时创建了一个 Alpine 容器，把卷挂载到/data，把当前目录挂载到/backup，然后在容器内执行tar打包。执行完容器自动删除（--rm），宿主机当前目录下就生成了备份文件。这个方法不需要停业务，是我用过最顺手的卷备份姿势。
网络部分，Docker 的网络模型日常接触最多的是 bridge 网络。默认情况下，所有容器跑在名为bridge的默认桥接网络中。容器之间可以通过 IP 互通，但 IP 会漂移，靠 IP 不好使，最可靠的方式是自定义网络，然后用容器名当作主机名解析。
自定义网络的操作步骤：
docker network create app-network启动容器时指定网络：
docker run -d --name nginx-app --network app-network nginx:1.24-alpine docker run -d --name api-server --network app-network myapp:1.0.2这样配置之后，api-server容器内直接用http://nginx-app:80就能访问到nginx-app容器。这个机制是 Docker 内置的 DNS 解析，在自定义网络下自动生效，不用额外配置。我日常拉一个多服务项目时，一定会把所有服务全部放进同一个自定义网络，避免用--link这种老掉牙的关联方式。
端口映射与网络的配合也需要注意。如果一个容器只在自定义网络里服务其他容器，其实没有必要做-p端口映射。比如上面api-server只需要被 nginx 反向代理访问，它本身不需要对外暴露端口，只要两个容器在同一个网络里就够了。反过来，如果你忘了把容器加入同一网络，却在排查为什么从 A 容器访问 B 容器失败，这时候八成是网络隔离造成的。
还有一个常用命令是查看容器的 IP 和网络信息：
docker inspect nginx-app | grep IPAddressdocker inspect --format '{{.NetworkSettings.Networks.app-network.IPAddress}}' nginx-appinspect是万能信息查询工具，容器配置、挂载、网络、环境变量、状态都能查。调试时可以多用，但别依赖 grep 大海捞针，用--format直接提取才高效。
5. 清理、监控与调试：docker stats、system df 等容器日常维护命令
服务器跑得久了，Docker 占磁盘空间的问题总是会冒出来。Docker 的磁盘占用大头主要是镜像、容器可写层、日志文件、数据卷，以及构建缓存。这里有一套日常巡检的组合命令。
先看空间用量：
docker system df这个命令一跑出来，镜像、容器、本地卷、构建缓存的大小一目了然。它比df -h更精确，直接展示了 Docker 自己管理的那些目录占了多大空间。最底下那行Reclaimable显示可回收的空间有多大，配合下一步清理动作。
清理空间的标准操作：
docker system prune默认只清理停止的容器、无用的网络、悬空镜像和构建缓存。想连未被引用的数据卷也清理掉，加-a：
docker system prune -a但这里我要重点提醒：-a会顺带把所有未被容器引用的镜像全删了，包括那些你曾经构建但当前没有容器运行的版本。如果生产环境没有成熟的镜像仓库做缓冲，本地只剩一份镜像版本，千万慎用-a。实际操作里我通常只用不带-a的system prune，再单独用docker image prune和docker volume prune分目标清理，每一步都确认过目标再执行。
容器资源占用监控这块，docker stats是我每天必敲的命令：
docker stats [容器名]它会实时展示容器的 CPU 使用率、内存占用、网络 I/O、磁盘 I/O 和进程数。像看任务管理器一样直观。部署完成后，我会先连着跑几分钟docker stats，确认资源占用没有异常毛刺再收工。
还有一个调试场景很常见：某个容器一直重启，或者启动几秒就退出，这种情况怎么排查？我的固定套路：
docker ps -a找到容器名和退出状态。docker logs 容器名看应用崩溃日志。docker inspect 容器名看退出码和错误信息，重点看State字段里的ExitCode和Error字段。
比如ExitCode 1通常是应用启动时报错；ExitCode 137多半是容器被 OOM Killer 杀了，内存配置不够；ExitCode 139是段错误，常和底层库兼容性问题有关。这些退出码对应的含义是排查的第一线索，我踩过一次非常郁闷的坑：服务莫名其妙退出且无任何日志，最后docker inspect一看是OOMKilled为 true，才知道是内存上限设得不够。
实时查看容器内进程也能辅助排查：
docker top 容器名类似宿主机top命令，显示容器内的进程列表。当你怀疑容器里是不是起了一个异常进程，或者应用进程莫名退出时，先用这个命令确认内部状态。
容器内文件拷进拷出也是运维环节的高频操作：
docker cp ./local-file.txt 容器名:/data/ docker cp 容器名:/data/log.txt ./local-backup/docker cp的好处是不需要进入容器，直接宿主机操作文件。传配置文件、导出日志、备份小文件都很好用。但不建议把docker cp当成文件同步工具用，大文件和目录结构建议走数据卷挂载，效率更高。
6. 高效进阶：run 命令的隐藏参数与日常脚本化的操作习惯
看到这里，常规操作基本覆盖完了。但日常操作能不能再高效一点，完全取决于能不能把 Docker 命令和真实工作流结合起来。我个人靠三件套提升效率：尽可能给容器都打上--name、为命令写简短的 shell 脚本、把一键启动脚本化。
先讲--name。很多人用 Docker 图省事，启动时不写名字，后面查找全靠docker ps里的 Container ID 前几位。容器数量一多，这种操作会让人抓狂。跑容器务必定名：
docker run -d --name myapp-2024.11 ...名字起得有规律，后面exec、logs、restart全部用名操作，等于给每个容器一个好记的句柄。配合docker rename可以随时改名，但其实起名时想好最省事。
再说一个高频参数--env-file。如果是运行配置项特别多的容器，不要在一个超长的命令行里塞十几个-e，写成 env 文件：
docker run -d --name api-server --env-file .env.prod myapp:1.0.2.env.prod文件里一行一个KEY=VALUE：
DB_HOST=pg-db DB_PORT=5432 DB_NAME=appdb TZ=Asia/Shanghai这样生成的 run 命令非常短，易维护，换环境部署时只要换 env 文件。我从这个习惯里受益最多的一次是在某客户现场，批量部署了三个环境配置各不相同的同业务容器，全靠 env 文件切换，效率提升了一个量级。
最后说下日常脚本化。我在本地维护了一个docker-helper.sh脚本，把最常用的一套操作封装成短命令，起来大概是这个感觉：
#!/bin/bash # docker-helper.sh alias dps='docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"' alias dlogs='docker logs --tail 100 -f' alias dstopall='docker stop $(docker ps -q)' alias dclean='docker system prune -f'dlog直接跟进最近 100 行日志，dstopall一键停止所有容器，dclean快速清理无用资源。这套脚本不复杂，但确确实实降低了日常操作的心智负担。
还有一个容易忘但生命周期很短的高频操作，叫“临时一次性容器”。比如临时想看某个目录的文件结构，或者临时连数据库却没装客户端：
docker run --rm -it -v $(pwd):/work alpine sh--rm让容器退出后自动删除，不会留下垃圾容器；-v $(pwd):/work把当前目录带进容器。用完退出自动清理，不污染环境。这个命令是我做临时调试的万能钥匙，什么场景都适用。
7. 日常必踩的坑：换镜像仓库、时区、存储、权限等高频问题实录
这节把我在实际运维和日常开发里反复踩过、且新手最容易中招的坑汇总在一起，做成一个快速排查清单。这些问题我几乎每个月都会在社区里看到有人在问，用一篇的篇幅集中讲透。
先说镜像拉取相关的问题。docker pull在某些网络环境里慢得无法忍受，或者直接超时，最直接的办法是给 Docker 配置镜像加速器。但这个得看运行环境，建议把官方配置和第三方加速源对比后再选。配置不复杂，关键在于确认镜像加速器可用，然后重启 Docker 服务生效。如果加速后还是慢，需要检查是不是在构建阶段而不是 pull 阶段慢的，区别就在于构建时如果有apt-get install这类指令，瓶颈可能是系统包源，而不是 Docker。用基础镜像自带国内源的过程，往往比单纯调 Docker 配置更能解决问题。
第二个重灾区是容器内时区。默认基础镜像时区是 UTC，导致日志时间和业务时间差八个小时。解决方案有两个：启动时用-e TZ=Asia/Shanghai设置环境变量，或者进入容器后手动改/etc/localtime。但后一种方式在容器重建后失效，所以规规矩矩在启动命令里加环境变量才是正解。有些基础镜像需要安装tzdata包才能正确识别时区，这种属于基础镜像本身精简的问题，遇到就在 Dockerfile 里补上：
RUN apk add --no-cache tzdata && cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime第三个坑是存储驱动和磁盘爆满。容器运行期间会产生大量日志，Docker 默认的 json-file 日志驱动会持续累积日志文件，且不自动轮转。一个高并发服务跑一个月，日志文件撑到几十 G 是常事。最省事的规避办法是在/etc/docker/daemon.json里配置日志轮转：
{ "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" } }这样单份日志最大 10M，保留 3 份，超了自动滚动清理。修改完要重启 Docker 服务。但注意，这只对新创建的容器生效，已存在的容器需要重建才能应用新的日志轮转设置。日常巡检时可以定期用du -sh /var/lib/docker/containers/*看看哪些容器的日志目录特别大，主动清理异常容器。
第四个坑是 Docker 守护进程的权限问题。Linux 环境下，普通用户直接敲docker ps会提示没有权限访问/var/run/docker.sock。解决办法分两种：要么把用户加入 docker 用户组（sudo usermod -aG docker $USER），要么每条命令加sudo。我建议用用户组的方式，但需要知道一个安全代价：加入 docker 用户组等价于拿到宿主机的 root 级权限，因为容器可以挂载宿主机任意目录。所以生产服务器上我依然坚持用sudo，个人开发机才用用户组方案。
第五个绕不开的是容器内文件权限问题。数据卷挂载后，容器内进程对挂载目录的读写权限经常和宿主机不一致，表现就是报Permission denied。需要知道容器进程的身份：很多基础镜像默认以 root 运行，但一些官方镜像会切换到低权限用户。遇到权限问题先确认容器内 uid，用docker exec 容器名 id查看，然后处理宿主机目录权限，或者通过参数指定用户方式让容器以相同 uid 运行。这里要特别注意，完全没有必要看到权限问题就直接 chmod 777，那是把安全隐患挡在门外的方式。
8. 最后的实操心得
这些年用 Docker，最大的感悟不是背下多少命令，而是建立一套自己的操作直觉。看到一个新服务，第一反应是：它是无状态的还是需要持久化？需要暴露端口给外部吗？是不是要在内网和其他容器互联？日志是打到标准输出还是文件？把这些想清楚了，docker run的参数组合自然就出来了。
我个人的习惯是每次搭建环境都优先加上--name，统一时间-e TZ=Asia/Shanghai，日志量大的服务提前配好 json-file 轮转，凡是数据库和文件存储类的目录全部走 named volume。这套组合在日常项目里几乎不变式使用，既稳定又省心。如果非要选一个“最有用的小习惯”，我会选“容器停用后，过段时间用docker system df看一遍空间”，这能避免绝大多数磁盘爆满的意外。这招救过我太多次了。
