1. 先把容器的“套路”看懂，再谈记命令
做容器运维这几年，我见过太多人拿着一堆Docker容器常用操作命令清单背了又背，真到排查问题的时候还是手忙脚乱。其实问题不在记性，而在于没有理解命令背后的对象模型。Docker的命令看着多，翻来覆去就是围绕两个核心对象转：镜像（image）和容器（container），再加两个辅助对象：数据卷（volume）和网络（network）。你只要搞明白这四个对象之间是什么关系，命令就好记了，而且不光是会敲，还知道什么时候该敲哪条。
先说镜像和容器。镜像是一个只读模板，好比做月饼的模具；容器是模具压制出来的月饼，是真正在跑的东西。同一个镜像可以创建出任意多个容器，每个容器之间相互隔离，互不影响。你改容器里的文件，改的是容器自己的可写层，镜像本身纹丝不动。这就是为什么Nginx镜像可以同时跑出几十个端口不同的容器，而互不冲突。理解这一点之后，你再看所有命令，都会变得非常顺：创建容器是docker create，启动容器是docker start，跑起来的容器是docker ps，不要了是docker rm。
这篇文章适合谁看？刚接触容器、想把命令用明白的开发者，也包括在本地跑实验、在测试环境部署服务时需要临时操作容件的运维同学。我尽量用实际踩坑经验来讲，不会只丢一个命令列表，而是把每条命令什么时候用、为什么这么用、容易错在哪都拆开讲清楚，争取你读完就能直接上手干活。
2. 容器生命周期：从创建到删除的全过程
2.1 核心组合：create 与 run 其实是一件事的两种姿势
docker create和docker run之间的关系经常被误解。docker run等价于docker create加上docker start两个动作合并执行：先基于镜像创建一个新容器，然后立刻把它启动起来。如果你只需要创建、但不想马上启动，就用docker create；如果需要创建并立即启动，就用docker run。
我实际工作中用得最多的一条还是docker run，因为它最直接。这里给一条参考命令：
docker run -d --name nginx-web -p 8080:80 -v /app/html:/usr/share/nginx/html nginx:alpine拆开解释：-d表示后台运行，--name指定容器名称，-p把宿主机的8080端口映射到容器内的80端口，-v做一个目录挂载，最后面是镜像名加标签。这里强烈建议镜像名后面不要省略标签，尤其是maven:3、python:3这类镜像，不写标签默认拉latest，虽然大概率能用，但版本漂移会带来很多后期麻烦，这个习惯要趁早养好。
run命令常配的参数还有几个值得单独说。比如-i和-t，合起来写成-it表示交互式运行，通常和/bin/bash一起用，试验某个镜像内部环境时特别好用。--rm表示容器退出后自动删除，适合短任务容器。--restart=always表示容器挂了自动重启，生产环境的常驻服务基本都要配。--env用来注入环境变量，比如给容器传数据库连接串。这些参数单看都简单，但组合在一起，docker run能玩出的花样就多了。
2.2 start、stop、restart 与容器的退出状态
容器创建并启动之后，日常的管理就靠start、stop、restart这几个命令了。docker stop的机制值得多说一句：它会先向容器内的主进程发送SIGTERM信号，给进程一个缓冲时间去做清理动作，默认等待10秒，如果10秒后进程还没退出，就会强制发送SIGKILL。docker kill则不做任何缓冲，直接SIGKILL。
刚开始用容器的人很容易遇到一个困惑：为什么我用docker run启动一个镜像，它立刻退出？比如你跑ubuntu:latest，执行docker run ubuntu，容器马上停了。这不是故障，而是因为容器不是虚拟机，它没有独立运行的init系统。容器存在的意义就是运行那个前台主进程，主进程一退出，容器就结束。ubuntu镜像默认没有常驻进程，自然秒退。如果你需要一个能长时间活着的测试容器，可以用这条：
docker run -dit --name ubuntu-test ubuntu:latest /bin/bash加了-it之后，再配合一个前台命令，容器就会保持运行。这也是一个很重要的心智模型：容器能否存活，取决于你给的启动命令是不是阻塞型前台进程。
docker restart就没那么复杂了，它会先stop再start，常用来让容器重新加载配置或恢复异常状态。不过我要提醒一句：restart不等于重新创建，容器内的可写层数据还在。如果你改了环境变量、端口映射这类配置，restart是没用的，必须rm之后重新run。这个坑我见人踩过很多次，改完-p参数，敲个restart发现端口没变化，折腾半天才反应过来。
2.3 rm 的正确姿势，以及 --rm 的巧用
删除容器用的是docker rm，命令后面跟容器ID或名称。运行中的容器直接删会报错，需要先docker stop再rm，或者用-f参数强删。强删走了SIGKILL，所以使用要谨慎。批量删除时，可以先列出所有容器的ID，然后一次性交给rm：
docker rm $(docker ps -aq)这里docker ps -aq是列出所有容器的ID，注意-a表示包含已停止的容器，-q表示只输出ID。这个组合在清理环境时非常省事，但务必确认当前环境里的容器是真的不要了再执行。也可以用docker容器清理命令docker container prune一键删除所有已停止的容器。注意prune只删已停止的，运行中的不会动，相对安全。
再聊--rm参数。跑临时任务时我非常推荐加上它，比如用容器执行一次性脚本、编译小项目、跑测试用例。容器退出后自动清理，不留垃圾容器，不用手动rm，减少很多操作步骤。但是生产环境的常驻服务，不要加--rm，否则你docker stop的时候容器直接没了，想查日志都没得查，而且如果docker restart策略配合了restart=always，容器退出会被自动拉起，--rm还会造成一种奇怪的“删除与重启竞争”的状态。
3. 进入容器：exec、attach、cp 别用混了
3.1 exec 才是进容器的正规方式
要在运行中的容器里执行命令，现在的主流方式就是docker exec。它的格式是docker exec [OPTIONS] CONTAINER COMMAND，比如：
docker exec -it nginx-web /bin/sh这条命令进入nginx容器内部拿到一个shell。-it在exec里同样表示交互模式。新版的nginx:alpine镜像默认没有/bin/bash，只有/bin/sh，直接敲bash会提示No such file，这是我第一次用alpine镜像踩到的坑。
很多人会问exec和docker attach有什么区别。attach是把自己挂到容器主进程的当前终端上，也就是直接接入那个PID 1的输出流。如果你度前是用-d后台跑的服务，attach过去大概率是黑屏没反应，因为服务进程本来就不输出交互内容。即使有输出，ctrl+c也会直接发给主进程，可能把容器搞停。exec则是进容器开一个新进程，不影响主进程的存活，安全得多。所以排查问题时，请默认用exec，不要去碰attach。attach现在只剩少数交互场景还有意义，日常运维基本可以忘掉。
3.2 容器内外文件互拷：cp 命令
docker cp用来在容器和宿主机之间复制文件，格式有两种：
docker cp 容器名:/容器内路径 宿主机路径 docker cp 宿主机路径 容器名:/容器内路径比如想把nginx容器里改坏的配置文件取出来对照：
docker cp nginx-web:/etc/nginx/nginx.conf ./nginx.conf.bakdocker cp不需要容器处于运行状态，只要容器还存在，哪怕已经停止也能拷贝，这个特性在容器崩溃后抢救数据时很管用。不过注意docker cp没法复制目录权限和文件属主信息，拷出来的文件属主可能变成root，这个在恢复数据时要注意一下。
数据交换还有一种方式就是挂载。如果你在run的时候就加上了-v参数，把宿主机目录挂进容器，那根本不需要cp，直接两边就是同一个目录。我的习惯是，所有需要长期读取或修改的配置一律用挂载，cp只用来做临时拷贝和救急。
3.3 不进去也能看到容器状态：top、stats、port
有些场景不需要进容器，在外面就能拿到内部信息。docker top命令可以查看容器内进程列表，效果类似Linux的ps，而且比在容器内执行ps更方便的一点是，它连宿主机上对应的宿主机PID也会显示出来，开容器内部进程真实PID，排查僵尸进程或者CPU占用异常的线程时非常有用。
docker stats可以实时查看所有运行中容器的CPU、内存、网络IO、磁盘IO占用情况，效果类似宿主机上的top命令，但视角是按容器维度的。这样能很快定位到是哪个容器在吃内存、哪个容器网络流量异常。它会持续刷新，想看单次快照就加--no-stream参数。
docker port比较轻量，用于查询某个容器做了哪些端口映射。比如你忘了nginx-web映射了哪个宿主机端口，敲一下docker port nginx-web就知道了。这几个命令虽然用得不如exec频繁，但在线上问题定位时经常能派上大用场，而且它们对容器本身几乎无侵入，不会因为多敲几条命令就影响正在跑的业务。
4. 数据持久化：volume、bind mount 和 tmpfs 怎么选
4.1 三种挂载方式的本质区别
容器本身是可写层，但可写层的生命周期绑定容器，容器删除，数据跟着消失，所以需要持久化。Docker提供了三种挂载方式：bind mount、volume、tmpfs。
bind mount是把宿主机的某个目录直接挂载到容器目录里，宿主机上的文件就是容器里的文件，两边实时同步，修改任意一边，另一边立刻可见。它是最直观的，适合在开发环境挂代码目录、挂配置文件。但它的缺点是权限敏感：宿主机目录的属主和SELinux、权限属性都会直接透传到容器里，容易出现Permission denied的问题。
volume是Docker自己管理的一块存储空间，存放在Docker数据目录下。它的好处是不用关心宿主机具体路径，跨机器迁移更方便，并且支持volume driver扩展，比如挂到NFS这类远端存储上。生产环境我推荐优先用volume，因为它更干净、隔离性更好，操作层面也更统一。相关命令有docker volume create、docker volume ls、docker volume inspect。tmpfs是挂在内存里的临时存储，读写快但数据不持久，适合放缓存、临时文件这种丢了也不心疼的东西。
4.2 具名卷和匿名卷，别把数据搞丢
用-v挂载时，如果冒号左边只写一个名字不写路径，Docker会把它当作一个具名卷，比如-v nginx-data:/usr/share/nginx/html，这里的nginx-data就是volume名称。如果冒号左边完全省略，只写-v /usr/share/nginx/html，就是匿名卷，Docker会随机生成一个卷名。
这里有个容易踩的坑：匿名卷虽然也有持久化能力，但它没有明确名字，时间一长完全不知道里面放的什么，也没法快速定位。而且如果容器被删除重建，匿名卷通常不会自动跟着创建新容器挂载，数据容易变成“孤儿”。我在实验环境经常看到这种状况：容器一堆，匿名卷一堆，谁也不认识谁。所以除非是临时场景，尽量都用具名卷，并且命名规范一点，至少让你一眼能看出是哪个服务的。
4.3 备份和恢复：一条 tar 命令的事
volume的备份与恢复不需要停止业务，但为了数据一致性，建议先停容器。一条命令就可以把卷内容打包出来：
docker run --rm -v nginx-data:/data -v $(pwd):/backup alpine tar czf /backup/nginx-data.tar.gz -C /data .原理很巧妙：启动一个临时容器，把这个卷挂载到容器的/data目录，再把当前目录挂为/backup，容器里执行tar打包。恢复也一样，反向解压即可：
docker run --rm -v nginx-data:/data -v $(pwd):/backup alpine tar xzf /backup/nginx-data.tar.gz -C /data我第一次看到这个套路时觉得挺绕，但用熟练之后发现这正是容器化的精髓：用容器来做数据任务，宿主不需要装额外工具，只要装了Docker，一切都在容器里完成。
5. 容器网络：端口映射、网络模式和容器互联
5.1 -p 端口映射背后发生了什么
-p参数是Docker使用频率最高的网络参数，全称是publish端口发布。-p 8080:80表示把宿主机的8080端口流量转发到容器内的80端口。这个转发不是简单的路由，它依赖Docker的iptables规则和docker-proxy进程。
通常我们访问一个容器服务，访问的是宿主机的某个端口，实际数据链路是：宿主机端口收到请求，通过NAT规则转到容器IP的容器端口，再由容器内的服务进程接收。所以这里有两个常见问题的答案就清楚了。第一，为什么容器内服务监听在127.0.0.1上时，外面访问不到？因为容器内的回环地址只在容器内有效，容器外的流量进不来，服务必须监听0.0.0.0。第二，为什么改了防火墙规则之后，容器端口映射突然失效？因为docker刷的iptables规则可能在防火墙规则之前或之后，顺序不对就被拦住了。
docker run时如果不指定-p，容器网络默认也是通的吗？要看情况。同一宿主机上的容器，如果都接入默认bridge网络，它们之间可以通过IP互通，但宿主机的端口并不会被占用。需要从外部访问服务时，必须显式-p。还有一个经常被忽略的点：-p还可以指定IP，比如-p 127.0.0.1:8080:80，只在本机回环地址上暴露端口，生产环境如果只需要本机反向代理访问，这样更安全，不需要开公网端口监听。
5.2 单机四种网络模式怎么选
Docker原生支持几种网络模式，通过--network指定。bridge模式是默认的，容器有自己的网桥和IP，端口映射就基于这个模式。host模式不隔离网络，容器直接复用宿主机的网络命名空间，启动容器时不产生独立IP，也没有NAT转换。host模式的优点是性能损耗极小，缺点是端口就直接占宿主机的，如果多个容器都用host模式都要监听80端口，必然冲突。
none模式完全没有网络，只适合跑纯计算任务或需要极度隔离的安全场景，连访问外部网络都不行。container模式可以让容器共享另一个容器的网络栈，典型的应用场景是sidecar模式，比如主容器负责业务，边上挂一个抓包容器共享它的网络，这样不需要单独暴露端口就能看到同一个网卡上的流量。
多数情况下，单机用bridge就够了。但如果你对网络延迟极度敏感，或者业务本身依赖很多宿主机的随机端口，host模式是值得考虑的。选型时记住一句话：默认bridge最安全，host最直接，container最特殊，none最隔离。
5.3 自定义网络和容器名 DNS 解析
Docker默认的bridge网络有一个局限：容器的IP地址在创建时动态分配，重启后可能变化，而且容器之间无法直接用容器名来访问。解决方案就是创建自定义网络。创建网络用docker network create，把容器加入指定网络用--network参数，已有容器可以用docker network connect来动态加入。
docker network create my-net docker run -d --name app1 --network my-net myapp:latest docker run -d --name app2 --network my-net myapp:latest docker exec app2 ping app1上面最后一条命令会成功，因为在自定义网络里，Docker自带的DNS服务会根据容器名解析出对应IP。这就是为什么容器互联时尽量用服务名而不是硬编码IP，IP会变，名字不会变。默认bridge网络没有这样的自动DNS解析，所以容器的服务名访问经常要自己维护hosts，非常麻烦。我现在不管单机还是多机，只要是容器之间要通信，第一步就是建一个自定义网络。
6. 资源限制：防止容器把宿主机“吃爆”
6.1 内存、CPU、PID限制的标准姿势
不限制资源的容器会导致两个典型问题：一个是单个容器因内存溢出不停GC，拖垮整个宿主机；另一个是某个容器疯狂写日志，把磁盘吃完，影响同机其他业务。所以生产环境几乎一定要配资源限制。
内存限制用--memory参数，单位是b、k、m、g。docker run -d --memory=512m nginx:alpine表示限制容器最大可用内存512MB。还有一个关联参数--memory-swap，默认和内存一样大，也就是说内存512MB再加--memory-swap=1g，容器最多能用到1.5GB的总内存和交换分区。这里注意：--memory-swap不设的话，容器在内存不够时会用宿主机的swap，具体行为取决于宿主机配置。为了明确限制内存总量，建议把--memory-swap设为和--memory相同，这样彻底禁用swap，避免容器因为内存压力被内核直接OOM kill，却又感知不到。
CPU限制用--cpus参数，--cpus=1.5表示容器最多使用1.5个CPU核心。更细一点，--cpuset-cpus可以指定容器只能在哪些CPU核心上运行，比如--cpuset-cpus=0,1只在0和1号核上跑，适合在NUMA架构上优化性能。这个参数我一般在压测时才用，日常不需要太抠。
除了CPU和内存，还有一个容易被忽视但很重要的限制：--pids-limit。它可以限制容器内能创建的进程数。阻止容器内一个程序因fork炸弹或者失控创建大量进程拖垮宿主机。我见过一个案例，容器里有个worker不断fork新线程，直接把宿主机进程数打满，最后连SSH都登不上。之后凡是跑第三方镜像的应用，我都会加一个--pids-limit=200之类的合理值，至少能让系统在被拖垮之前有反应时间。
6.2 动态调整：docker update 和 docker stats 的配合
如果你发现某个已运行的容器没设资源限制，或者限制太小需要调大，不需要重建容器，docker update可以直接改资源参数：
docker update --memory=1g --cpus=1.5 nginx-webupdate的适用范围包括--memory、--cpus、--pids-limit这些，但还是有些参数不能改，比如端口映射。所以update适合临时调优，如果端口这类静态配置要改，还是得重建。
调整完怎么知道效果？用docker stats看实时占用，然后对比容器内实际进程的日志判断有没有被频繁GC、OOM或者CPU throttle。在容器内部，还可以执行cat /sys/fs/cgroup/memory.max这类文件来查看cgroup限制，因为容器内的资源限制本质就是Linux cgroup的配置，限制条写入的路径，其实就是写这些文件。理解这个原理后，你在容器里排查资源问题时就有思路了，不是瞎猜。比如容器内free -h看到的内存远超限制值，这是正常的，因为free读的是宿主机的内存信息，容器内看到的内存本来就不准确，判断容器内存是否超限应该以cgroup文件内容为准。
7. 日志、排查与常见问题速查
7.1 日志查看与 inspect 的深入用法
容器日志是排查问题的第一入口，最常用的是docker logs。基本用法是docker logs 容器名，默认只显示启动以来stdout和stderr的内容。加-f可以实时跟踪，类似tail -f，加-tail 100可以只显示最后100行。这里也讲一下机制：容器内主进程的stdout和stderr会被Docker捕获并写入日志文件，日志驱动默认是json-file，所以如果容器内进程把日志写到文件而不是输出到stdout，docker logs就看不到内容。遇到这种情况，要么改应用配置把日志打到stdout，要么直接进容器看应用日志文件。
docker inspect是一个非常强大的命令，几乎能读取容器的全部元信息。docker inspect 容器名 | grep -i ip可以看IP地址，docker inspect 容器名 | grep -i mount可以看挂载情况，docker inspect -f '{{.State.Status}}' 容器名可以快速拿到容器的运行状态。Go模板语法看起来有点门槛，但实际常写的就那么几个，比如{{.NetworkSettings.IPAddress}}、{{.Config.Image}}、{{.HostConfig.Memory}}，用顺手之后比整个人翻JSON快得多。
还有一个较少被人用的命令是docker events。它会实时输出Docker守护进程的事件流，比如容器创建、启动、停止、异常退出。适合排查容器反复重启这类问题，而不是逐个容器登进去看状态。开一个终端敲docker events --filter 'type=container'，另一边复现问题，能看到容器从创建到退出的事件时间线，比看日志更直观。
7.2 容器退出代码的“翻译”
容器异常退出时，docker ps -a状态列会显示Exited (code) xxx，这个退出码是判断问题的关键线索。Exit code 0表示正常退出，128表示信号退出，比如128 + 9 = 137说明被SIGKILL，往往是OOM kill或者被人为kill；128 + 15 = 143说明被SIGTERM，一般是stop命令触发。退出码1通常表示应用内部错误，应用自己启动失败、配置错误、依赖连不上都会抛1，需要看它自己的日志。退出码126表示权限问题，127表示命令找不到。
这里有个示例：当你看到Exited (137)时，第一反应不应该是去看容器日志，而是去查是不是内存超限。docker stats里看内存占用，或者查宿主机的dmesg日志，看有没有Out of memory字样。这是我排查OOM问题时总结出来的顺序。如果只看代码，很多新手会钻进应用日志里找原因，浪费时间。
7.3 排查命令的组合拳
最后分享几个我平时用的命令组合。列所有容器包括已停止的：docker ps -a。一次性清理所有停止的容器：docker container prune -f。清理所有不再使用的镜像、容器、网络、构建缓存：docker system prune -a，注意这个会删掉所有没被容器引用的镜像，需谨慎确认。列出所有容器的名称和IP：
docker ps -q | xargs -I {} docker inspect -f '{{.Name}} {{.NetworkSettings.IPAddress}}' {}这行命令在容器数量较多的时候，能快速出一张容器IP清单，比一个个查省太多时间。
8. 数据卷清理与镜像瘦身，别等磁盘报警再动手
8.1 匿名卷、悬空卷的清理策略
数据卷用久了之后，宿主机上会产生大量未被任何容器引用的悬空卷。这些卷经常是容器删除时留下的，名字随机，体积可能很大，但你是无法直接判断能不能删，因为删错了可能造成数据丢失。docker volume ls可以查看所有卷，docker volume ls -f dangling=true只看悬空卷。我建议在确认业务容器不需要那些数据的情况下，再用docker volume prune清理，它会列出所有悬空卷并要求确认。再加-f参数就是强制清理。
生产环境清理数据卷前务必确认，最稳妥的做法是先把悬空卷名字记下来，和当前运行容器做关联排查。如果你不确定某个卷被谁在用，可以用docker inspect来查看容器的Mounts部分，或者用docker volume inspect查看卷的详细信息，确认没有容器引用后再删。我见过因为docker volume prune误删了备份卷导致恢复不了的事故，所以清理操作宁可保守，不要图快。
8.2 镜像体积过大？先清理构建缓存再用多阶段构建
镜像体积大直接影响推送拉取速度和磁盘占用。Dockerfile里每一行RUN指令都会产生一个新的镜像层，即使后面删掉了中间产物，文件依然留在层里。所以常见的处理办法：能合并RUN指令就尽量合并，需要临时下载的文件，在同一层里用完就删除，并且确认没有开放端口和多余依赖。这些手段能压到一半体积，但本质上还是镜像层的结构约束。
更彻底的方案是多阶段构建：构建阶段用完整工具链，运行阶段只拷贝编译结果。比如Go程序，构建阶段用golang镜像编译出二进制，运行阶段用alpine镜像只拷贝这个二进制。这样最终镜像只有几MB。不过多阶段构建不是所有语言都适合，带解释器的语言比如Python、Node.js，本身运行环境就重，能压的空间有限。关于镜像瘦身，核心原则就一个：只包含运行时必要的东西，其他一切不带。
8.3 常用清理命令组合清单
收集一份常用的清理组合，方便日常维护时一键执行：
# 清理所有停止的容器 docker container prune -f # 清理所有悬空镜像（untagged镜像） docker image prune -f # 清理所有未被容器引用的镜像 docker image prune -a # 清理所有悬空卷 docker volume prune -f # 全量清理（包含构建缓存和安全风险提示） docker system prune -a --volumes -f这组命令在开发环境可以放心用，但在生产环境请逐个执行并检查输出，不要上来就system prune -a。我自己的习惯是：生产机上只用docker container prune和docker image prune -f，volume相关的清理几乎都是人工确认后执行。
9. 几个提升效率的命令技巧，适合放在你的日常工具包里
先说要长期保存的命令记录。Docker历史命令有个特点：停了容器之后，docker ps看不到，很多人会以为容器被删了。所以我对容器名有强制要求：只要是正式用途的容器，必须用--name指定名称，不用随机ID。否则到第二天你自己都找不到哪个容器是哪个应用。
再看docker exec的隐藏用法。用它批量在不同容器里执行同一条命令的场景很多，配合循环非常方便：
for c in $(docker ps --format '{{.Names}}'); do echo "=== $c ==="; docker exec $c df -h /; done这个命令可以一次性看所有运行中容器的根目录磁盘使用率。如果某些容器没有df命令，会报command not found，这个正常，alpine类镜像的tools比较少，不必纠结。
还有一个比较实用的技巧，就是通过docker kill停止服务，但docker stop更优雅。docker stop默认10秒，等待时间可以用-t参数调整：docker stop -t 30 nginx-web，给应用留更长的时间来做优雅下线。配合容器内进程处理SIGTERM的逻辑，可以实现无感知重启。
最后提一句环境变量的处理。容器内程序配置通常通过环境变量注入，docker run用-e，docker exec不像run那样直接加-e，但可以在exec时带上环境变量然后执行命令：
docker exec -it -e MY_ENV=prod nginx-web env这条命令不会修改容器的原始环境，只是给这一次执行的进程临时设置环境变量。排查问题时想临时覆盖某个变量，不需要改容器配置，用这个方式最快。
我个人在实操中最大的体会是：Docker命令从来不是靠背的，是靠“理解对象模型+反复操作”形成的肌肉记忆。你只要把镜像、容器、卷、网络四个对象的关系印在脑子里，命令的自然语言结构就会帮你自动推导出该敲什么。再遇到不会写的参数，一个docker run --help就全出来了，比收藏几百条命令清单靠谱。日常维护中，我爱用docker ps加docker stats加docker logs这三条先开局面，大多数问题看一眼就能判断接下来的排查方向。希望这篇能把Docker容器常用操作命令的底层逻辑讲透，帮你少走点弯路。
