搜「Docker Compose教程」的人，多数不是缺概念，而是卡在就地验证这一步：不确定本机装的是 Compose V2 插件还是老的 docker-compose 独立二进制，不确定 compose 文件里写的版本字段还该不该保留，也不知道 MySQL 容器起不来该先看哪条日志。这篇按真实排查顺序走一遍：先确认版本与入口，再确认权限，最后给一条最短能跑通的路径和一个带具体取值的场景，每一步都标出命令该看到什么输出。
判断顺序建议是这样：先用 docker compose version 和 docker info 确认是 V2 插件、Docker 守护进程可用；再看当前用户在不在 docker 组或有等效权限；然后确认 compose.yaml 所在目录就是执行目录。三步都对，再谈写服务和装 MySQL。改完配置一律用 docker compose config 校验，再用 docker compose up -d 起、docker compose ps 和 docker compose logs 看结果。版本号、镜像标签这类会变的东西，以本机命令输出和 Docker Hub 镜像页为准，不要凭记忆写死。
Docker Compose最新版本使用教程
「最新版本」在 Compose 里对应的不是某个固定版本号，而是「V2 插件形态」这一步：命令写成 docker compose（中间是空格），而不是 docker-compose（中间是连字符）。前者由 Docker CLI 插件机制加载，后者是独立的 Python 实现，两者配置文件大体兼容但命令行为有差别。
确认是不是 V2，可以在终端直接跑：
docker compose version
docker info --format '{{.ServerVersion}}'第一条正常输出形如 Docker Compose version v2.x.x，如果报 docker: 'compose' is not a docker command，说明插件没装或不在 CLI 插件目录里。可以用 docker info 的输出确认守护进程在线；守护进程不通时，compose 子命令也会一并失败，容易误判成 Compose 没装。
另一个可核对的位置是插件目录：Linux 下通常是 /usr/libexec/docker/cli-plugins 或 /usr/local/lib/docker/cli-plugins，里面应能看到名为 docker-compose 的可执行文件。具体路径和安装方式会随发行版和安装渠道变化，以本机 docker info 输出的插件信息和所用安装包的说明为准。
还有一处容易踩：老教程里的 version: '3' 顶层字段。V2 插件下这个字段已不再必需，写了通常也不影响运行，但会给出提示。要不要删，看你团队其他机器的实际情况，统一比「最新」更重要。
Docker Compose安装MySQL教程
在 Compose 里装 MySQL，本质是写一个 service 再用镜像启动，而不是在容器里跑安装脚本。这一步对应的工作是：编辑 compose.yaml 的 services 段、设置环境变量、映射端口和挂载数据目录，然后用 up 拉起。
一份最小可用的写法如下，放在项目目录下的 compose.yaml 里：
services:
mysql:
image: mysql:8.0
container_name: demo-mysql
restart: unless-stopped
environment:
MYSQL_ROOT_PASSWORD: change-me-root
MYSQL_DATABASE: demo
MYSQL_USER: demo
MYSQL_PASSWORD: change-me-user
ports:
- "3306:3306"
volumes:
- ./mysql-data:/var/lib/mysql
healthcheck:
test: ["CMD", "mysqladmin", "ping", "-h", "127.0.0.1", "-uroot", "-pchange-me-root"]
interval: 10s
timeout: 5s
retries: 5镜像标签写 mysql:8.0 是一个保守选择，具体可用标签以 Docker Hub 上该镜像的 tags 页面为准，不要照抄别人文章里的版本号。密码写在 environment 里只适合本地练习，正式使用应改用 env_file 或密钥管理。
起来之后按顺序核对三处：docker compose ps 里 STATE 应为 running、health 最终为 healthy；docker compose logs mysql 里应出现 ready for connections；宿主上用 mysql -h 127.0.0.1 -P 3306 -u demo -p 能连上并执行 select 1。三处有一处不对，先看 logs 里的报错原文，再做判断。
Docker Compose之前先确认这三件事
三个前提缺任何一个都会让你在后面的步骤里反复试错，且报错信息往往指向错误的地方。
- 版本：在哪看——docker compose version 的输出。命令名带空格还是连字符，决定了你后面所有命令的写法；博客里两种写法混用是最常见的困惑来源。
- 权限：在哪看——直接执行 docker ps，不报 permission denied on /var/run/docker.sock 就说明当前用户可用。报错说明没加入 docker 组或没有等效权限。加组需要重新登录会话才生效。
- 入口位置：在哪看——pwd 和 ls compose.yaml 或 docker-compose.yml。compose 默认在当前目录找配置文件；在不含该文件的目录执行，会得到 no configuration file provided 的错误，而不是「服务不存在」。
三件事都能用一条命令给出可核对的结果，不必靠猜。把它们放在写服务之前做，能省掉大量「以为是 YAML 写错了」的时间。
Docker Compose：最短可用路径
- 建目录并进目录：mkdir -p ~/compose-demo && cd ~/compose-demo。做完后 pwd 应显示这个路径。
- 写最小配置：把下面内容存成 compose.yaml。
- 校验配置：docker compose config。正常会打印出解析后的完整配置；有语法或字段错误会直接报行号。
- 后台启动：docker compose up -d。应看到容器创建并启动的进度行。
- 核对结果：docker compose ps 看 STATE，docker compose logs -f 看启动日志。
services:
web:
image: nginx:stable
ports:
- "8080:80"
volumes:
- ./html:/usr/share/nginx/html:ro在目录下建一个 html 子目录并放一个 index.html，浏览器访问 http://127.0.0.1:8080 应能看到页面。这一步同时验证了三件事：端口映射生效、只读挂载生效、容器确实在运行。nginx:stable 只是示意标签，实际可选标签以镜像仓库页面为准。
Docker Compose：一个真实场景的完整做法
场景设为：本地开发环境需要一套「Web 应用 + MySQL 8」的组合，MySQL 存一张约十万量级的用户表，数据需要持久化到宿主目录，重启容器后数据不丢。所有配置都写在项目根目录的 compose.yaml 里，环境变量取自同目录的 .env 文件。
services:
db:
image: mysql:8.0
restart: unless-stopped
env_file: .env
environment:
MYSQL_DATABASE: appdb
ports:
- "3306:3306"
volumes:
- ./mysql-data:/var/lib/mysql
app:
image: nginx:stable
depends_on:
- db
ports:
- "8080:80"
volumes:
- ./html:/usr/share/nginx/html:ro.env 文件里放 MYSQL_ROOT_PASSWORD、MYSQL_USER、MYSQL_PASSWORD 三项，不要把密码直接写进 compose.yaml，避免提交到版本库。注意 environment 段会覆盖 env_file 里的同名项，所以 MYSQL_DATABASE 只放在一处，避免两边取值不同还要排查。
核对位置分三层：compose.yaml 里看服务名、端口、挂载路径；.env 里看密码与用户；运行后用 docker compose config 确认变量已正确展开，再 docker compose ps 看两个容器的 STATE，最后 docker compose logs db 确认 ready for connections。数据是否真持久化，可以 docker compose down 后重新 up，再连库查询已有表来验证。数据目录权限、宿主机端口占用、镜像标签是否可用这三点会随环境和版本变化，需要在实际机器上确认。