Docker入门踩坑指南：镜像、容器、数据卷与MySQL/Redis部署实战

最近被问到的 Docker 相关问题的密度有点高：有人在 Windows 上装了 Docker Desktop，双击图标后直接报 “virtualization support was not detected”；有人在 Ubuntu 上把 docker 装好了，结果docker ps却提示权限不够；也有人兴致勃勃要部署 MySQL，结果容器启动后没数据、时区还是 UTC。说实话，这些问题几乎都是入门者绕不过去的坎，而 Docker 本身恰恰是那种“会者不难，难者不会”的工具。这也让我想把“Docker 的简单介绍”这篇文章认真写得更实用一些，把镜像、容器、安装、排障这些基础概念揉进真实场景里讲清楚。

其实我并不想写一篇教科书式的 Docker 教程，而是想以一名使用者的身份，把“第一次用 Docker 到今天能熟练部署 MySQL、Redis、微服务”这条路上最有价值的经验沉淀下来。无论你是开发同学想统一本地环境，还是运维同学要在一台新服务器上快速拉起一套服务，或者只是前端想在自己的电脑上跑一个带 Python 环境的实验项目，这篇文章都值得你花十分钟看完。只要顺着文章走一遍，你至少能自己完成 Docker 的安装、配置镜像加速、跑起第一个容器，并且遇到常见报错时知道该从哪个方向去查。

1. 先用一句话说清 Docker 到底是什么

Docker 是一个开源的容器化平台，它让你能把应用和它需要的运行环境一起打包成一个“镜像”，再用这个镜像创建出一个个相互隔离的“容器”。这种隔离不像虚拟机那么重，但又比直接跑在宿主机上干净得多。网络上关于 Docker 的定义很多，但我更愿意把它理解成“标准化的软件交付方式”：你在笔记本上怎么跑起来的，到服务器上就能以几乎完全一样的方式跑起来。

1.1 容器与虚拟机：本质区别在哪里

很多人刚开始会把容器和虚拟机混为一谈，其实两者的设计思路差别很大。虚拟机需要模拟出一套完整的硬件环境，每个虚拟机里都要装一个完整的操作系统，所以你启动一台虚拟机，等于是在找一台“虚拟电脑”开机，资源开销自然大。容器就不一样了，它直接共享宿主机的操作系统内核，只是在用户空间里做了隔离。你拉下来的镜像里通常只有应用程序、依赖库、配置文件和必要的系统工具链，没有完整的操作系统内核。

用生活里的比喻来说，虚拟机就像搬了一整套房子，里面要有水电、家具、装修，而容器更像是用标准集装箱运输货物：箱子本身是标准化的，在不同港口之间搬运时只需要统一的吊装设备，也就是宿主机内核，就能高效地装卸。这也是为什么容器启动通常只需要“秒”级的时间，而虚拟机动不动就要等几十秒甚至几分钟。

正因为这种内核共享的机制，容器对硬件资源的利用率会高很多。一台 8 核 16G 的机器，跑几个重量级虚拟机可能就快顶不住了，但跑一二十个轻量容器往往还能轻轻松松。这也是微服务架构和 CI/CD 流水线普遍拥抱容器的重要原因。

1.2 Docker 在真实项目里到底能解决什么痛点

把 Docker 放在实际工程环境里看，它解决的核心痛点是“环境不一致”。同一套代码，你在自己电脑上能跑，同事电脑上报依赖错误，测试服务器上又缺了某个系统库，这种“我这边明明是好的”的惨案，几乎每个团队都经历过。用 Docker 打包镜像后，代码、运行时、依赖、配置全都被固化在镜像里，到哪都是同一套环境。

另一个痛点是快速交付和弹性伸缩。以前部署一个应用可能要写一堆安装文档，什么 GCC、Nginx、Node.js、Python 版本，没有人敢保证照着文档走不会出岔子。现在很多项目只需要把镜像往仓库一推，目标机器上执行docker pull和docker run就完事了。新机器扩容、灾备切换、临时环境搭建，效率都高了不少。

Docker 的应用范围也非常宽。大数据领域有人直接拉 Hadoop 镜像做实验；AI 领域有人用 Docker 部署模型推理服务，比如用 vLLM 镜像加载 Qwen3 这类开源模型；安全领域里，Kali 的 DVWA 靶场也经常以容器方式部署。可以说，只要是需要“研究软件运行环境”的场景，Docker 几乎都能以更干净、更可复现的方式介入。

2. 安装 Docker：Windows 与 Linux 两条路

安装是卡住很多人的第一道坎。Docker 的安装方式跟操作系统关系很大，而且官方针对桌面端和服务器端提供了不同的解决方案。这里我分别把 Windows 和 Linux 的安装过程说清楚，顺便把最常出现的启动失败和权限问题一起处理掉。

2.1 Windows 安装 Docker Desktop 与虚拟化检查

Windows 上主流的方案是安装 Docker Desktop，它基于 WSL 2 或者 Hyper-V 运行。安装过程本身不复杂，从官网下载 Docker Desktop 安装包，双击运行，按提示“同意协议 → 选择是否使用 WSL 2 → 安装完成”，真正让人崩溃的是安装之后启动失败。

如果你遇到 Docker Desktop 启动时弹窗提示 “Docker Desktop failed to start because virtualization support was not detected” 这类错误，说明宿主机上的虚拟化能力没有被正确识别。这时候按顺序做三件事：

第一，重启进 BIOS/UEFI 设置，检查 CPU 虚拟化是否开启。Intel 平台找 VT-x，AMD 平台找 SVM，不同主板叫法不一样，但基本都在 Advanced / CPU Configuration 这类菜单里。不少品牌机出厂默认是关闭的，这一步最容易漏。

第二，确认 Windows 功能里已经启用了“适用于 Linux 的 Windows 子系统”和“虚拟机平台”。可以在“启用或关闭 Windows 功能”窗口里勾选，也可以在管理员 PowerShell 里执行：

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

执行完重启系统，再重新启动 Docker Desktop。Windows 11 上这个过程通常会更顺畅一些，老版本 Windows 10 则要特别注意系统版本和补丁是否到位。

第三，打开 PowerShell 执行wsl --status，确认默认版本是否为 2。如果发现当前 WSL 内核版本过旧，执行wsl --update更新内核。Docker Desktop 首次启动时会初始化一个后端 Linux 虚拟机，这一步需要下载并安装特定内核文件，网速不好时可能卡很久，甚至让你误以为程序卡死了。多等一会儿，或者挂一次系统更新后再试试，一般就能解决。

Docker Desktop 本身也支持界面截图、容器日志查看和镜像管理，对普通用户来说比纯命令行友好太多。Windows 11 上如果看到英文界面不习惯，可以在 Settings 里调整界面语言，实际功能上中英文的差异并不大。

2.2 Linux 安装：Ubuntu 与 CentOS 的差异

Linux 下安装 Docker 的路径主要有两条：一是直接用发行版自带的 docker.io 包，二是安装 Docker 官方仓库里的 docker-ce 版本。对大部分学习者来说，Ubuntu 用户用系统自带的包就满足需求了：

sudo apt update sudo apt install docker.io -y sudo systemctl enable --now docker docker version

执行完docker version能看到客户端和服务器版本信息，就说明 Docker 服务已经跑起来了。需要提一下，systemctl enable --now docker的作用是设置开机自启，并且立即启动服务。如果漏了这一步，服务器重启后 Docker 服务不会自动拉起，到时候排查“docker 服务启动失败”又会多绕一圈。

CentOS 7 的情况稍微特殊一点。老版本 CentOS 自带源里的 podman 和旧版 docker 包很容易让人踩坑，更稳妥的做法是安装 docker-ce。官方仓库地址和安装步骤在网上可以查到，大体思路就是先把 Docker 官方仓库加到yum源里，再安装docker-ce。如果你机器上已经有旧版本 docker，执行更新时要留意要不要保留旧数据目录/var/lib/docker：

sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo sudo yum install -y docker-ce docker-ce-cli containerd.io sudo systemctl start docker sudo systemctl enable docker

CentOS 7 上安装较新版本 Docker 时，可能会遇到依赖库版本过老的问题，尤其是container-selinux和iptables相关组件。尽量不要盲目卸载系统组件来迁就安装，优先选择跟系统版本匹配的 Docker 版本，或者考虑把老系统升级到更新的发行版再去跑 Docker。这听起来像是“逃避”，但实际部署时，旧系统的兼容性黑洞会浪费大量时间。

2.3 不用动不动就 sudo：docker 权限配置

装完 Docker 后，普通用户执行docker ps往往会看到“permission denied”或者 “Got permission denied while trying to connect to the Docker daemon socket” 的提示。这是因为 Docker 守护进程的 socket 文件/var/run/docker.sock默认只有 root 用户和 docker 组的成员可以访问。

解决办法不是每次命令都加sudo，而是把自己加入 docker 用户组：

sudo usermod -aG docker $USER newgrp docker

newgrp docker是让当前会话立刻生效的命令，不用重新登录系统。如果你用的是远程 SSH 连接，可能还是要断开重连一次才能让用户组变更完全生效。加完组之后再执行docker ps，就不会再报权限问题了。

不过这里我要多说一句：把用户加入 docker 组，相当于把等同于 root 级别的能力交给了该用户，因为 Docker CLI 可以通过 socket 操作容器，进而操作宿主机文件系统。在自己本机学习时没有太大问题，但在生产服务器上添加 docker 组成员要慎重，至少不要随便给普通业务账号开放这个权限。

3. 镜像、容器、网络与数据卷

安装好之后，就要开始真正使用 Docker 了。很多初学者喜欢只记命令，不去理解背后的对象模型，结果遇到组合场景就懵。实际上，只要理清“镜像、容器、网络、数据卷”这四个核心对象的关系，Docker 的基本玩法你就算掌握一大半了。

3.1 先学会拉镜像、查镜像、删镜像

镜像可以理解成一个只读的模板，里面包含运行应用所需的一切。最常用的获取方式是从镜像仓库拉取，比如：

docker pull mysql:8.0 docker pull redis:7 docker pull python:3.10-slim

这里说一下:后面的 tag。mysql:8.0里的“8.0”是版本号，用来区分不同版本的镜像。省略 tag 时默认拉取latest，但生产环境建议显式指定版本，否则哪天基础镜像更新了，你的环境可能就变得不可复现了。

拉取完成后，可以用docker images查看本机已有的镜像。这句话执行后，你会看到 REPOSITORY、TAG、IMAGE ID、CREATED、SIZE 这几列。IMAGE ID 是镜像的唯一标识，删除镜像时可以用：

docker rmi mysql:8.0

如果镜像已经被某个容器使用了，docker rmi会提示无法删除。这就是 Docker 里的一种“依赖关系”：容器由镜像创建而来，反过来删除镜像前要先清理掉由它创建的容器。这种顺序感在入门阶段要建立起来。

3.2 创建和进入容器：docker run 的正确打开方式

创建容器的命令非常直观：

docker run -d --name mynginx -p 8080:80 nginx

拆开看：-d表示后台运行；--name mynginx给容器起个名字；-p 8080:80把宿主机的 8080 端口映射到容器的 80 端口；nginx是使用的镜像名。执行完之后，浏览器访问http://localhost:8080，就能看到 Nginx 的欢迎页。这台容器现在已经是一个完整的、可访问的 Web 服务了。

我遇到过很多次把-p搞反的情况，这里重点强调一下端口映射的方向：左边是宿主机端口，右边是容器内端口。很多人写配置时总写成-p 80:8080，然后发现访问不到，排查半天，其实就是方向反了。

进入一个正在运行的容器，最常用的是docker exec：

docker exec -it mynginx bash

-it的意思是分配一个交互式终端，后面跟容器名和要执行的命令。Nginx 官方镜像里可能没有bash，只有sh，那就用docker exec -it mynginx sh。在容器内做的修改，如果不把数据卷或文件拷贝出来，容器一旦被删除，修改就全部丢了。这是后话，但不提前知道很容易踩坑。

查看容器日志用docker logs mynginx，停止和删除容器分别用docker stop mynginx和docker rm mynginx。如果容器已经停止但不删，它仍然占用着容器的名字和文件系统，下次想用同一个名字就不行。所以调试阶段，我通常直接用docker rm -f 容器名强制删除，一步到位。

3.3 数据卷：容器再也不是“一次性玩具”

刚开始接触 Docker 的人最容易犯的一个错误是：在容器里存数据，然后随手docker rm把容器删了，发现数据全没了。容器本身是瞬态的，应该把数据存储在宿主机上或者数据卷里。

数据卷可以理解成 Docker 帮你管理的一块独立存储区域，它与容器的生命周期解耦。创建容器时挂载数据卷的写法是：

docker run -d --name mysql8 \ -e MYSQL_ROOT_PASSWORD=123456 \ -v mysql-data:/var/lib/mysql \ mysql:8.0

这里-v mysql-data:/var/lib/mysql表示把名为mysql-data的卷挂载到容器内的/var/lib/mysql目录。MySQL 的数据文件都写在/var/lib/mysql里，所以以后即使容器被删，只要卷还在，重新创建容器时挂上同一个卷，数据就都还在。

除了命名卷，Docker 也支持 bind mount，也就是把宿主机上的某个绝对路径直接挂载进容器：

-v /home/user/app:/app

这种方式适合开发调试，因为宿主机上的代码改完之后容器里立刻就能看到。但 bind mount 和容器间的权限映射比较复杂，新手阶段建议优先使用命名卷，简单且不容易出现权限问题。

3.4 网络：为什么容器之间连不上

“docker 网络不通”是我见过被问得最多的问题之一。要理解容器网络，先记住几个默认概念。Docker 安装后会自动创建几个网络，其中最常见的是bridge网络。默认情况下，容器会加入bridge网络，并且有一块独立的 IP 地址，宿主机可以通过映射端口访问容器，但容器如果要访问另一个容器，最好不要依赖动态 IP，而是通过容器名去访问。

由于默认 bridge 网络里的容器之间不能直接用容器名解析，比较稳妥的办法是创建自定义网络，并让相关容器加入同一网络：

docker network create mynet docker run -d --name redis-server --network mynet redis:7 docker run -d --name app --network mynet myapp-image

在同一个自定义网络里，容器可以直接通过容器名互相访问。比如上面例子中app容器里写redis-server这个主机名就能连上 Redis，不用关心 IP 地址是多少。这个特性在做服务编排、微服务联调时特别重要，也是后面 Docker Compose 能轻松实现多容器互联的基础。

如果容器要访问外部网络，默认的 bridge 网络本身就会做 NAT 转发，正常情况下不需要额外配置。但有些服务器环境里 iptables 被改过，或者 Docker 服务启动时没有正确初始化网络规则，就会出现容器能起来但无法访问外网的现象。排查时可以先看宿主机能不能上网，再检查容器内/etc/resolv.conf的 DNS 配置，很多时候时区不对、DNS 不对，都会让人误判成网络问题。

4. 高频实操场景：MySQL 8.0 与 Redis 主从

概念说再多，不如亲手部署两个典型的服务。MySQL 和 Redis 可以说是容器化部署最常接触的两个中间件，一个代表持久化存储，一个代表缓存和数据结构，各有各的注意点。

4.1 部署 MySQL 8.0 并从宿主机访问

部署 MySQL 8.0 的命令本身并不复杂，关键是参数要理解到位：

docker run -d --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD=root123 \ -e MYSQL_DATABASE=testdb \ -e MYSQL_USER=testuser \ -e MYSQL_PASSWORD=user123 \ -e TZ=Asia/Shanghai \ -v mysql-data:/var/lib/mysql \ mysql:8.0

环境变量MYSQL_ROOT_PASSWORD是 root 用户的密码；MYSQL_DATABASE、MYSQL_USER、MYSQL_PASSWORD是用来创建一个初始数据库和普通用户的。如果你不写这三个，容器启动后只有一个 root 用户。这里建议官方镜像的习惯，尽量不要用 root 跑业务连接，把普通用户建好，密码单独管理。

TZ=Asia/Shanghai是我强烈建议加上的参数。MySQL 容器如果不指定时区，默认是 UTC，日志时间跟你本地的“北京时间”差 8 个小时。你想象一下，半夜排查日志发现时间差了 8 小时，有多崩溃。容器里很多软件默认 UTC，凡是跟时间打交道的组件，都建议显式设置TZ。

启动后，在宿主机上执行：

docker exec -it mysql8 mysql -uroot -p

输入密码后就能看到 MySQL 命令行。如果你习惯使用 DBeaver、Navicat 这类图形化工具连接，连接信息里主机填localhost，端口填3306，用户名和密码用上面环境变量里设置的即可。

有一个很常见的坑：宿主机上本来就已经装了 MySQL，占了 3306 端口，容器再映射 3306 就会冲突。启动报错信息通常是“port is already allocated”或者Bind for 0.0.0.0:3306 failed: port is already in use。解决方案很简单，换一个宿主机端口，比如-p 3307:3306，这样容器对外就是 3307 端口，容器内仍然监听标准 3306。这种“宿主端口可以随意变、容器端口保持标准”的思路，在容器化环境里非常实用。

4.2 用 Docker 搭建 Redis 主从

Redis 主从是另一个很适合用容器来演示的功能。原因很简单：主从复制需要两个 Redis 实例，自己下载源码编译安装一遍再配置，费时费力，用 Docker 两分钟就能搞定。

先创建自定义网络，让主从容器可以按容器名通信：

docker network create reids-net

启动主节点：

docker run -d --name redis-master \ --network reids-net \ -p 6379:6379 \ -v redis-master-data:/data \ redis:7 \ redis-server --appendonly yes

启动从节点：

docker run -d --name redis-slave \ --network reids-net \ -p 6380:6379 \ -v redis-slave-data:/data \ redis:7 \ redis-server --slaveof redis-master 6379

--slaveof redis-master 6379是告诉从节点去复制 master 的数据。这里能看到容器网络的价值：从节点不需要知道主节点的 IP，只需要在同一个自定义网络里，通过容器名redis-master就能找到对方。

验证复制是否生效，可以进入主节点写一条数据，再到从节点查询：

docker exec -it redis-master redis-cli SET foo bar docker exec -it redis-slave redis-cli GET foo

如果返回bar，说明主从同步已经成功建立。Redis 7 版本里也支持REPLICAOF命令，但命令行参数--slaveof仍然是兼容的。需要提醒的是，容器里跑 Redis 如果开启了持久化，务必挂载/data目录，常写-v redis-master-data:/data，这样即使容器重建，数据也不会丢。如果你只是本地测着玩，不挂载卷也能跑，但生产环境不持久化的 Redis 容器就是在制造事故。

5. 当项目变复杂时：Docker Compose 与镜像打包

单个容器好管理，但真实项目往往由多个组件组成：数据库、缓存、后端服务、前端静态文件，如果每个都用一条长长的docker run命令来启动，命令又多又乱，根本无法维护。这时候该上 Docker Compose 了。

5.1 Compose 文件的基础写法

Docker Compose 的核心思想是用一个 YAML 文件把多个容器的配置集中起来，然后一个命令起停整个应用。

services: db: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: appdb ports: - "3306:3306" volumes: - db-data:/var/lib/mysql app: build: . ports: - "8080:8080" environment: DB_HOST: db DB_PORT: 3306 depends_on: - db volumes: db-data:

这个文件里定义了两个服务：db和app。db直接使用 MySQL 镜像；app用build: .表示从当前目录下的 Dockerfile 构建镜像。depends_on用来声明服务启动顺序，让数据库先启动。注意depends_on只控制容器的启动顺序，并不能保证数据库已经完全初始化完成，业务代码里最好还是要加一个重试机制。

使用 Compose 最常用的命令就三个：

docker compose up -d docker compose ps docker compose down

up -d在后台启动所有服务；ps查看当前项目里所有容器的状态；down停止并删除容器。加上-v会连命名卷一起删除，操作前一定要确认数据是否需要保留。新版本的 Docker 已经内置了 compose 子命令，不需要再单独装 docker-compose 那套老工具。

5.2 用 Dockerfile 把项目打包成镜像

Compose 里的build: .依赖 Dockerfile。Dockerfile 就是用文本格式描述“如何把一个应用构建成镜像”的说明书。以 Python 项目为例，最简单的写法是这样：

FROM python:3.10-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD ["python", "app.py"]

每行都对应镜像构建的一层：FROM指定基础镜像；WORKDIR设置工作目录；COPY把宿主机文件复制进镜像；RUN在构建过程中执行命令；CMD定义容器启动时要运行的默认命令。构建命令是：

docker build -t my-python-app .

-t给镜像打一个标签，比如my-python-app。构建过程中如果多次改动代码，重新 build 时只有 COPY 之后的那几层会重建，之前依赖安装的层会走缓存，所以构建速度很快。这也是 Dockerfile 设计上的一个重要优势：把不容易变化的依赖安装放在前面，把频繁变化的源码 COPY 放在后面。

其他语言项目的套路是类似的。Java 项目可以准备一个带 Maven 或 Gradle 的构建阶段，也可以直接写多阶段构建，先编译出 jar，再复制到带 JRE 的运行时镜像里。IDE 里集成 Docker 插件后，打包镜像会进一步简化，比如 IDEA 里只要配置好 Docker 插件，右键就能执行 Build Image，不用每次手动docker build。PHP 项目也一样，用 PHP-FPM 镜像做好扩展安装，再把代码 COPY 进去即可。

5.3 微服务项目与多容器编排注意点

微服务项目的容器化，很典型的做法是每个服务一个镜像，再通过 Compose 把所有服务串起来。这时有几个细节非常影响体验。

第一个是服务发现。容器 IP 会变化，不能用固定 IP 去互联，必须依赖 Compose 自动创建的网络，在应用配置里把对其他服务的地址写成服务名。比如 Java 项目里配置数据源，jdbc:mysql://db:3306/appdb里的db就是 Compose 服务名，而不是 IP。

第二个是配置来源。不要把数据库密码、密钥直接写在镜像里，最好通过环境变量注入。镜像本身是静态的“可交付物”，环境变量是“部署参数”，两者分开，同一个镜像才能在开发、测试、生产环境复用。

第三个是日志。容器内的日志默认写到标准输出，用docker logs查看。微服务数量一多，建议统一采集到日志系统再聚合查看，不然每个容器挨个docker logs，调试效率会低到让人怀疑人生。Compose 文件里可以配置 logging 驱动，把容器日志转发到统一的日志后端，具体配置方式取决于团队用的日志平台。

6. 高频问题与排查速查表

最后把这几年积累的、群里被问得最多的排障经验整理成一个问题速查表，按“启动失败类、下载与网络类、权限类、容器运行期类”这几个方向展开。很多问题看起来五花八门，但底层原因就那么几种，掌握排查思路比死记报错信息有用得多。

6.1 启动失败类：Docker Desktop 与 docker 服务

这里要特别强调：排查服务启动失败的第一步永远不是盲目重装，而是看日志。Linux 上执行journalctl -u docker -n 50，Windows 上查看 Docker Desktop 的日志文件，日志会直接告诉你是网络初始化失败、存储驱动不支持，还是配置文件语法错误。我见过太多人重装了三次才发现只是/etc/docker/daemon.json里写了一个无效参数。

6.2 下载慢与网络不通

镜像拉取慢是初学者最普遍的体验之一。这通常取决于镜像源与当前网络环境的连接质量，常规的解决方法是给 Docker 配置镜像加速器。Windows 桌面版可以在 Settings 的 Docker Engine 里修改 JSON 配置；Linux 需要编辑/etc/docker/daemon.json：

{ "registry-mirrors": ["https://docker.mirrors.example.com"] }

修改完成后执行systemctl daemon-reload && systemctl restart docker，再重新拉取镜像，速度会明显改善。这里要注意，镜像加速器只处理镜像下载这一类问题，不改变所谓“外部网络”的访问路径，如果需要拉取某些特殊来源的镜像，还是要靠配置对应 registry 的认证或合规的网络策略。

容器内网络不通的另一个常见场景：容器能启动，但容器里apt install完全没反应。这时候要先确认宿主机网络正常，再进容器检查 DNS：

docker run -it --rm alpine cat /etc/resolv.conf

如果 DNS 配置异常，可以在容器启动参数里手动指定 DNS：--dns 8.8.8.8。不过在自定义网络里，Docker 会自动处理 DNS 转发，绝大多数情况下不需要手动干预。

6.3 权限和命令找不到问题

权限问题前面已经讲过主流的解法：加入 docker 组。这里再补充一个细节：如果你是通过脚本安装的 Docker，安装完脚本通常已经帮你创建好 docker 组了，但如果你的机器之前没有 docker 组，直接执行usermod -aG docker $USER会报“group docker does not exist”，需要先手动创建：

sudo groupadd docker sudo usermod -aG docker $USER

“命令找不到”这个类别里，最典型的是 IDE 或者 CI 环境中报cannot run program "docker": createprocess error=2, 系统找不到指定的文件。这表示执行环境里找不到 Docker 可执行文件。在 Windows 上如果 Docker Desktop 已经装好，检查 Docker CLI 的路径是否在 PATH 里，通常它位于C:\Program Files\Docker\Docker\resources\bin下。在 IDE 里打开 Docker 配置，手动指定 Docker 可执行文件的完整路径即可解决。这一类问题其实不是 Docker 本身坏了，而是系统的 PATH 环境变量没有把 Docker 目录加进去。

6.4 容器运行期常见问题

容器能启动，不代表一切正常。运行期的问题往往更让人困惑，这里挑几个高频的列出来。

端口映射不生效是最常见的。检查顺序是：先docker ps看容器状态和端口映射列是否显示了0.0.0.0:8080->80/tcp，再确认宿主机防火墙是否放行了对应端口。如果你开了 ufw 或者云安全组，80 端口映射得再对，防火墙禁止了照样访问不了。这一步排查不出技术问题，就是配置问题。

容器内时区不对也比较常见。很多官方镜像的默认时区是 UTC，处理方法是在启动参数里加上-e TZ=Asia/Shanghai，或者在 Dockerfile 里显式设置。别小看这个问题，日志监控、定时任务、数据库记录全都依赖正确的时间。

还有个容易被忽略的问题是容器里的文件权限。挂载宿主机目录后，容器内进程可能没有权限读写宿主机文件，尤其是以非 root 用户运行的镜像。报错信息往往是Permission denied，解决办法通常是确保宿主机目录权限对应用户可写，或者在容器命令里显式指定--user参数。这里尽量别用--privileged这种绕开问题的方案，权限范围太大会带来安全风险。

最后再聊一点个人体会

玩 Docker 这几年，我最大的感受是：它的命令真的不用刻意去背，关键是理解“镜像、容器、网络、数据卷”这四个对象之间的关系。很多看似复杂的部署，拆开之后不过就是拉镜像、起容器、配网络、挂数据卷这几步的排列组合。初学者最容易走的弯路，是嘴上说要学 Docker，却一直停留在“能用命令跑起一个实例”的层面，对于数据到底存在哪里、容器之间怎么通信、构建镜像时为什么要把依赖安装放前面这些问题缺乏思考。其实这些才是真正决定你能否把 Docker 用顺手的核心点。

如果你现在正被某个 docker 问题卡住，我的建议是从“日志”开始查，而不是反复卸载重装。Docker 的报错信息大多数时候已经把原因写得很清楚了，只是我们习惯性忽略它。这篇文章里提到的 MySQL、Redis、Compose 场景，你可以自己动手各跑一遍，跑通之后再换成自己的项目和配置，慢慢你就会发现，容器化带来的“环境一致”是如此自然的一件事。后续有机会，我还会把镜像仓库的搭建、容器安全加固、以及生产环境里日志和监控的配置这些话题展开写一写。