企业官网建设流程全解析

有没有遇到过这种局面：在自己 Windows 电脑上装好了 Docker Desktop，跟着教程敲docker compose up -d，服务倒是跑起来了，但接下来想查一下容器里某个配置文件在哪儿、想看一眼服务日志、或者把容器里的文件拉出来改一改，突然就不知道从哪儿下手。这个需求其实特别朴素，几乎每个用 Docker Compose 的人都会碰到。所以我把这段时间在 Windows + Docker Desktop 环境下的容器服务查询和文件查看操作整理成一期，作为《Docker Compose 容器服务查询与文件查看操作指南》的第一篇。这篇内容不追求高深原理，主打一个“可以直接照着抄”。适合刚接触 Docker Compose 的开发者、需要临时接管别人留下项目的运维同学，以及任何一位在 Windows 上折腾 Docker Desktop 的同事。

1. 先把环境坐实：Windows 上 Docker Desktop 与 Compose 的前置准备

1.1 为什么 Windows 上跑 Compose 要先把底层环境搞清楚

很多人第一次在 Windows 上装 Docker Desktop，会有一个错觉：这不就是个普通桌面软件吗，双击安装、点两下启动器就能用。结果一启动就撞上经典的virtualization support not detected报错，于是卡在第一步。

关键在于理解 Docker Desktop 的运行机制。Windows 本身并不是 Linux 系统，而 Docker 容器依赖 Linux 内核特性，所以 Docker Desktop 的底层实际上是一个运行在 WSL2 或 Hyper-V 中的轻量级 Linux 虚拟机。Docker Desktop 这个 GUI 只是前台壳子，真正的容器引擎跑在虚拟化层里。换句话说，虚拟化没打开，Docker Desktop 就是一具空壳，点多少次 Start 都没用。

我个人的检查顺序是这样的，基本能覆盖 90% 的启动失败场景：

1. 进 BIOS/UEFI 确认 CPU 虚拟化已经开启。Intel 平台找 VT-x，AMD 平台找 SVM 或 AMD-V，不同品牌主板菜单名不太一样，但一般都在“Advanced”或者“CPU Configuration”里。
2. 在 Windows“启用或关闭 Windows 功能”里勾选“虚拟机平台”和“适用于 Linux 的 Windows 子系统”。这两个选项是 WSL2 的地基，少勾一个都不行。
3. 以管理员身份打开 PowerShell，执行wsl --update更新 WSL2 内核。
4. 重启电脑。别小看这一步，我见过太多人改完设置不重启就继续点 Docker Desktop，然后理所当然地再次看到那个报错。

如果想确认虚拟化是否真的就绪，可以在 PowerShell 里敲systeminfo，最后的“Hyper-V 要求”区域会显示相关信息。如果显示“已检测到虚拟机监控程序。将不显示 Hyper-V 所需的功能”之类的内容，说明虚拟化层面已经正常。

另外说一个 Windows 特有的坑：如果你电脑上同时装着 VMware Workstation 或 VirtualBox，Docker Desktop 和它们偶尔会打架，具体表现就是启动异常或容器网络不通。遇到这种情况，先关掉其他虚拟化软件再试。这种冲突问题在 Linux 上几乎不存在，但在 Windows 上属于老朋友了。

1.2 装好 Docker Desktop 后，先验证 Compose 能不能用

Docker Desktop 安装过程本身没什么好讲的，安装向导一路下一步就行。需要注意的是安装过程中的“Use WSL 2 instead of Hyper-V”选项，如果系统里已经启用了 WSL2，建议勾选这一项，因为 WSL2 的资源占用、启动速度和文件性能都比传统 Hyper-V 模式更适合开发场景。

装完之后别急着创建项目，先用两个命令验证环境：

docker version docker compose version

这里有个细节值得强调：现在官方推荐的命令是docker compose，中间带一个空格，它是 Docker 官方插件，跟随 Docker Desktop 一起发布。而docker-compose（带连字符）是老一代独立 Python 工具，已经进入维护期。如果你在网上看到教程还在用docker-compose，要么教程很老，要么作者的习惯还停留在过去。我建议新项目一律使用带空格的docker compose。

操作环境上，我也推荐一个 Windows 下的效率工具：Windows Terminal。它的多标签能力非常好用，可以同时开着 PowerShell、CMD 和 WSL 会话，查 Docker 容器、看文件、跑命令都集中在同一个窗口里。Docker Desktop 自带的终端入口也是基于它的。如果你现在还在用老版 ConHost 窗口，建议升级一下，体验差距是肉眼可见的。

还有一个 Windows 专属建议：如果你的 Windows 用户名包含中文，或者在 D 盘建了一个带空格的“我的 docker 项目”目录，Compose 文件里尽量不要写死绝对路径。Windows 下中文路径偶尔会惹出编码和权限问题，而且排查起来非常费劲。更稳妥的做法是在项目目录里使用相对路径，配合./前缀来指定挂载目录，这些细节在第 3 章会详细展开。

1.3 准备一个测试项目：nginx + redis

为了把后面的查询和文件查看命令讲到位，我们需要一个真实可操作的项目。我选了nginx和redis两个镜像，原因很简单：体积小、启动快、服务边界清晰。nginx 有配置文件可以看、有静态页面可以挂载，redis 有经典的服务端进程可以查状态、可以用客户端命令验证连接，非常适合当样例。

在任意工作目录下新建一个文件夹，假设叫docker-demo，里面放一个docker-compose.yml：

services: nginx: image: nginx:1.27-alpine container_name: demo-nginx ports: - "8080:80" volumes: - ./html:/usr/share/nginx/html restart: unless-stopped redis: image: redis:7-alpine container_name: demo-redis ports: - "6379:6379" restart: unless-stopped

简单解释一下里面的关键配置。container_name是给容器起一个固定名字，方便后续用docker cp和docker exec时不用猜随机生成的容器 ID。ports把容器的 80 端口映射到宿主机 8080，这样本地访问http://localhost:8080就能看到 nginx 首页。volumes里的./html:/usr/share/nginx/html是把当前目录下的html文件夹挂载进容器，这个设计在第 3 章查看文件时会非常有用。restart: unless-stopped是让容器在系统重启或 Dockerd 重启后尽量保持原状态，比较适合本地开发。

然后在docker-demo目录下创建一个html/index.html，随便写一句 “hello docker”，内容无所谓，主要是为了验证挂载和文件查看。

在项目目录下执行：

docker compose up -d

第一次执行会拉取镜像，可能需要几分钟。看到Started或done字样后，浏览器访问http://localhost:8080，能看到写的“hello docker”页面就说明环境已经完全打通。

2. 查询容器服务状态：别只会 ps，这几个命令才抓得到细节

2.1 用 docker compose ps 看项目状态

服务启动后的第一件事，就是确认它们到底跑没跑起来。最直观的命令是docker compose ps：

docker compose ps

输出会显示当前 Compose 项目下的所有服务，包括 NAME、IMAGE、COMMAND、SERVICE、STATUS、PORTS 几列。对于我这种习惯同时开好几个项目的人，docker compose ps的价值在于它只会显示当前目录对应的服务，不会把其他项目里的容器也列出来。加了-a参数后，已经停止的容器也会显示出来，方便对比。

STATUS 这一列需要学会读。正常情况下看到的是Up X minutes；如果容器不断重启，会看到Restarting；如果服务启动失败，会看到Exited (1) 2 minutes ago之类的内容，括号里的数字是退出码。很多初学者只看到“状态不是 Up 就知道坏了”，但并不知道怎么继续查。这时候应该做两件事：看日志、看退出码。日志问题我会在第 2.3 节展开，退出码的含义在第 4 章会有更具体的分析。

2.2 用 docker ps -a 和 docker stats 追查容器生命周期细节

docker compose ps是站在“项目”维度看服务，而docker ps则是站在“容器”维度看全局。两者各有用途：多项目并存时，docker compose ps帮你快速锁定当前项目；当你需要查看所有容器时，docker ps -a一个都不遗漏。我个人的习惯是先用docker compose ps，发现问题后再用docker ps -a --filter "name=demo"配合过滤条件定位。

docker ps -a里有一个容易被忽视但很关键的字段：退出码。常见退出码的直观含义如下：

查看实时资源占用时，可以开一个docker stats，效果类似 Windows 的任务管理器。它会实时刷新每个容器的 CPU、内存、网络和磁盘占用，排查内存溢出时特别有用。用 Ctrl+C 退出。

还有一个容易被忽略的命令docker compose top，它能看到容器内的实际进程列表，相当于在宿主机上执行ps aux。比如怀疑 redis 主进程是否还活着，docker compose top redis一眼就能确认。

2.3 日志是服务查询的另一只眼睛：docker compose logs

容器是短暂的，服务不会自己告诉你为什么起不来，但日志会。docker compose logs是排查服务问题的第一选择。

docker compose logs -f --tail=200 nginx

-f表示 follow，持续跟踪输出，类似 Linux 下的tail -f；--tail=200表示只显示最后 200 行，避免刷屏。不跟服务名则显示项目所有服务的日志。需要按时间过滤时，可以用--since和--until参数，例如只查看最近 10 分钟的日志：

docker compose logs --since 10m redis

这里说一个原理层面的小知识点：容器应用日志只要写到了标准输出和标准错误流，Docker 就会自动接住，docker compose logs本质上把 stdout 和 stderr 的流重新拉给你看。所以如果应用把日志写进了自己的文件而不是 stdout，比如某些 Java 应用写日志到/logs/app.log，那么docker compose logs是抓不到的，必须去容器里看对应文件。这就是第 3 章要讲文件查看操作的原因之一。

2.4 配置文件写对了吗：docker compose config

服务起不来还有一种常见原因：docker-compose.yml本身写错了。YAML 对空格和缩进极其敏感，少一个空格都可能让整个配置解析失败。这时候不需要启动任何容器，用一条命令就能验证：

docker compose config

这条命令会读取当前目录的 Compose 文件，解析并输出最终生效的完整配置。如果 YAML 有语法错误或字段填错，它会直接报错并指出行号。加上-q参数则进入静默模式，没有错误就不输出任何内容，非常适合写进 CI 脚本里做前置检查。

我自己的习惯是：每次执行docker compose up之前，先跑一遍docker compose config -q。这个动作只花一秒钟，但能挡住一半左右的低级拼写错误。尤其是团队协作场景下，同事改了一行ports导致缩进错乱，config命令一眼就能把问题揪出来。

3. 查看容器内文件：exec、cp、挂载目录三种思路互为补充

3.1 进入容器前的“心智模型”：什么是 exec

服务查询确认容器处于运行状态之后，下一个高频需求就是“看一眼容器里的文件”。很多人到这一步会犯迷糊，因为 Docker 的理念是“容器隔离环境”，仿佛文件就应该藏在某个看不见的地方。其实容器的文件系统跟宿主机的目录没有任何物理隔离，你可以把它理解为一个独立的小系统，只要你有办法进去，就能像操作普通 Linux 一样查看文件。

进入运行中容器的标准方式是docker compose exec：

docker compose exec redis sh

这条命令会在redis这个服务对应的容器内启动一个shshell。为什么用sh而不是bash？因为很多精简镜像（比如 alpine 系列）只预装了sh，根本不带bash，进去之后发现命令不存在，反而浪费时间。进入之后可以用redis-cli ping验证连接，返回PONG说明服务正常。

docker compose exec和docker compose run是两种容易混淆的操作。exec是在一个已有的容器内部执行新命令，不创建新容器；run则是基于服务配置临时创建一个新容器来执行命令，命令结束后容器退出。打个比方，exec相当于你远程桌面连上了一台正在运行的台式机，继续开个记事本；run则是从库房推来一台新电脑装完系统用一下就还回去。日常查看文件请优先用exec，临时跑一次性命令才用run。

3.2 文件查看的核心操作：cat、ls、find，一个都不能少

如果你只想快速看一眼文件内容，根本不必先进入容器再敲cat，可以直接用exec一次性完成：

docker compose exec nginx cat /etc/nginx/nginx.conf

输出会直接打到终端上，省去进入和退出的往返。这个组合我几乎每天都会用。需要看目录结构时，用ls -l：

docker compose exec nginx ls -l /etc/nginx/

如果你完全不知道文件在容器的哪个路径，可以用find全盘搜索。需要注意 find 在容器里可能比较慢，配合2>/dev/null把权限报错过滤掉会清爽很多：

docker compose exec nginx find / -name "nginx.conf" 2>/dev/null

这里还有一个“看不到文件但摸不清楚为什么”的辅助手段：docker image inspect。它可以查看镜像的元信息，其中WorkingDir、Entrypoint、Env这些字段能帮你快速判断一个镜像长什么样、默认工作目录在哪里、启动时执行了什么命令。比如说你想知道 nginx 默认把日志写在哪儿，用docker image inspect nginx查一下它的WorkingDir，再结合 nginx 官方文档就能很快定位。

3.3 docker cp：把文件拿出来看，改完再放回去

exec适合在终端里直接看，但有些场景下你更想把文件拉出来，用 Windows 记事本或 VS Code 打开，仔细看、再修改。这时候就要用docker cp。

从容器复制文件到宿主机：

docker cp demo-nginx:/etc/nginx/nginx.conf ./nginx.conf.bak

把宿主机文件复制回容器：

docker cp ./index.html demo-nginx:/usr/share/nginx/html/index.html

docker cp的使用逻辑非常直观：容器名:容器内路径就是容器的文件坐标，后面的路径就是宿主机坐标。新版 Compose 也提供了docker compose cp nginx:/etc/nginx/nginx.conf ./nginx.conf.bak的写法，作用是免去记忆container_name，但考虑到跨版本兼容，我更倾向于使用底层命令docker cp，因为它不依赖 Compose 插件的版本差异。

有一个容易踩的坑：docker cp复制到宿主机的是一个静态快照，不是实时同步。也就是说，你在 Windows 里改了文件，改完后必须手动docker cp回去，再执行docker compose restart nginx让进程重新加载配置，修改才会生效。如果每次都这么做，开发效率会很低，更直接的做法是采用下文的挂载目录方案。

3.4 用挂载目录实现无声的文件查看与修改

这是 Windows 用户最顺手的方式。在docker-compose.yml里通过volumes配置宿主机目录和容器目录的映射，宿主机里改文件，容器内立即生效，连重启都不用。

以第 1 章的项目为例：

volumes: - ./html:/usr/share/nginx/html

执行docker compose up -d后，Windows 上的docker-demo/html和容器里的/usr/share/nginx/html就是同一个目录的两个视角。你在 Windows 里新建一个index.html，浏览器访问http://localhost:8080立刻能看到新内容。这种做法不仅适合静态页面，也适合存放配置文件、日志目录、上传文件等场景。

这里说几个 Windows 下的注意事项。第一，Compose 文件里建议用./开头的相对路径，不要写死C:\Users\xxx这类绝对路径，因为 Windows 路径反斜杠在容器环境里可能导致解析异常。第二，Windows 挂载目录的权限通常比较宽松，但在某些镜像里容器内进程对挂载目录的写入仍可能因为权限不足而失败，表现是启动时报权限错误或者运行中无法写文件。第三，挂载方式是一种联合视图，本身不解决“容器镜像里内置文件”的查看问题。如果容器里根本没有挂载目录，只有镜像内部的静态文件，那还是要老老实实用exec或docker cp。

所以我的结论是：日常开发首选挂载目录，因为查看和修改文件都变成了纯 Windows 操作；一次性备份或导入文件用docker cp；临时探查容器内部结构用exec。三种思路互相补充，覆盖了文件查看的全部高频场景。

4. Windows 环境专属踩坑：启动失败、端口占用与文件权限排查

4.1 Docker Desktop 启动就报 virtualization support not detected，怎么查

这个报错是整个 Windows 环境里出现频率最高的一条。只要 Docker Desktop 启动时检测不到虚拟化支持，就会直接弹这个错误。它背后的原因往往是下面三选一：BIOS 层面虚拟化没开、Windows 虚拟化功能没启用、WSL2 内核没安装完整。

我的排查顺序如下：

1. 重启进 BIOS，确认 CPU 虚拟化选项已开启，选项名一般是 Intel VT-x、AMD SVM、Virtualization Technology 这一类的关键词。
2. 在“启用或关闭 Windows 功能”里同时勾选“虚拟机平台”和“适用于 Linux 的 Windows 子系统”，缺一不可。
3. 管理员 PowerShell 执行wsl --update更新内核。
4. 如果以上都正常但还是报错，执行bcdedit /set hypervisorlaunchtype auto并重启。这条命令解决的是 Windows 引导层面 Hypervisor 没有自动启动的问题，某些精简系统镜像和更新后的系统会出现这个情况。

整个流程跑完后，建议重启一次 Docker Desktop。这里我要特别强调一下重启的重要性：在 Windows 上，很多系统级配置修改都需要重启才能让底层虚拟化服务真正生效，改完设置不重启就直接点 Docker Desktop，等于白改。

4.2 WSL2 内核异常导致 Docker 引擎一直连不上

另一种容易混淆的情况是 Docker Desktop 能启动，但右下角一直显示 Docker Engine Stopped，仿佛引擎罢工了。这个问题通常出在 WSL2 的底层状态上。

排查时先看一下 WSL 状态：

wsl --status

如果显示异常，直接执行：

wsl --shutdown

这条命令会关闭当前所有 WSL 实例，然后重新启动 Docker Desktop，让引擎重新初始化。很多情况下到此就恢复正常了。

如果重试后依然连不上 Docker 引擎，可以检查一下 Docker 的上下文配置：

docker context ls docker context use desktop-linux

docker context是 Docker 用来切换不同引擎连接配置的机制，Docker Desktop 安装后通常默认使用desktop-linux这一项。曾经安装过其他 Docker 工具或手动改过上下文后，当前上下文可能指向了一个不存在的引擎，自然连接不上。切换回desktop-linux通常就能解决。

这里说一句安全提示：WSL2 异常时不要冲动地执行wsl --unregister删除发行版，因为整个发行版里的文件会被彻底清空。真正需要重置时，也要先备份数据，再考虑这个操作。

4.3 容器起不来：端口占用、配置语法错误、退出码排查

端口占用是 Windows 上容器启动失败的第二大原因。最常见的是 nginx 默认映射 80 端口，结果本机 IIS 或其他程序占用了 80。如果docker compose ps显示容器处于Exited (0)或Exited (1)，先看日志：

docker compose logs nginx

日志里如果出现 “port is already allocated” 或 “bind: An attempt was made to access a socket” 这类信息，基本就能断定是端口冲突。在 Windows 上查端口占用，有两种命令：

# CMD 环境 netstat -ano | findstr :80 # PowerShell 环境 Get-NetTCPConnection -LocalPort 80

查到占用的 PID 后，在任务管理器里找到对应进程判断要不要结束它，或者干脆修改 Compose 文件里的端口映射，比如把80:80改成8080:80。我个人处理这类问题时，更倾向改 Compose 文件而不是杀掉占用端口的进程，因为 Windows 上很多进程属于系统组件，杀掉容易引发连锁问题。

另一类启动失败源于 YAML 配置错误。验证手段就是第 2.4 节提到的docker compose config，快速定位语法问题。配置验证通过后，再用docker compose logs看应用层面的报错，两步组合基本上能解决 95% 的启动失败问题。

4.4 文件查看时的 Windows 专属问题：中文路径、换行符、编码

Windows 环境查看容器内文件，有四个高频细节值得特别留意。

第一是路径问题。Compose 文件里的相对路径最好全部使用正斜杠/且以./开头。反斜杠\是 Windows 路径分隔符，但它在容器内部会被当成转义字符处理，稍不注意就解析错乱。如果你非要用绝对路径，注意目录名不要包含中文或空格，否则某些老镜像里的工具可能无法正确处理路径。

第二是换行符问题。容器内的 shell 脚本和配置文件都是 Unix 风格换行（LF），而 Windows 记事本默认保存的是 CRLF。如果你用记事本修改了一个容器内脚本后直接挂载回容器，运行时常会报 “exec format error” 或脚本执行异常。解决方法是使用 VS Code 等支持换行符切换的编辑器，把行尾序列设为 LF 再保存。

第三是编码问题。容器日志和配置文件绝大多数是 UTF-8 编码，而 Windows 老控制台默认使用 GBK。如果你在 CMD 环境里看容器日志出现中文乱码，可以先用chcp 65001把代码页切到 UTF-8，或者在 Windows Terminal 里设置默认编码。Windows Terminal 在这方面做得比老版本好很多，这也是我推荐它的原因之一。

第四是中文界面诉求。有些人会去搜索 Docker Desktop 的汉化方案，社区里确实有汉化包，但我个人不太建议依赖汉化界面做日常操作。因为 Docker 的命令行工具全是英文，界面汉化只覆盖了 GUI 的一部分，实际排查问题还是得回到命令本身。把常用的docker compose子命令混熟，比界面汉化实在得多。

5. 一次完整实操串联：从 docker compose up 到找到容器里的配置文件

5.1 完整命令行记录：一套可以直接照抄的流程

前面各章把命令拆开讲了一遍，最后我用一个完整流程把它们串联起来。假设已经准备好了第 1 章的docker-demo项目，从零开始的一次完整操作是这样的：

# 1. 检查配置文件是否有语法错误 docker compose config -q # 2. 启动项目（守护模式） docker compose up -d # 3. 查看当前项目所有服务状态，包括已停止的 docker compose ps -a # 4. 查看 nginx 最近 200 行日志并持续跟踪 docker compose logs -f --tail=200 nginx # 5. 进入 nginx 容器，查看配置文件目录结构 docker compose exec nginx ls -l /etc/nginx/ # 6. 把 nginx.conf 复制到宿主机备份 docker cp demo-nginx:/etc/nginx/nginx.conf ./nginx.conf.bak # 7. 检查容器内是否有静态页面文件 docker compose exec nginx ls -l /usr/share/nginx/html/

这套流程覆盖了“启动前检查 → 启动 → 状态查询 → 日志排查 → 文件查看 → 文件导出”的完整链路。我第一次给同事演示的时候，他用这个流程处理了一个遗留项目的 nginx 403 问题，从docker compose ps发现服务正常但访问异常，到docker compose exec nginx ls -l /usr/share/nginx/html/发现 html 目录为空，整个过程不到五分钟就定位到了根因。

5.2 沉淀一套“服务查询与文件查看”的固定套路

实操过程中，我逐渐把上面的命令总结成一个固定套路，每次接手新项目都按这个顺序过一遍。

第一步是docker compose config -q，确认配置文件合法。第二步是docker compose up -d或docker compose start，把服务拉起来。第三步是docker compose ps -a，看服务当前状态。第四步是docker compose logs，从日志里找应用的蛛丝马迹。第五步是docker compose exec进入容器探查文件结构。第六步是docker cp或挂载目录，把文件从容器里导出来或放进去。

这套路看起来朴素，但实际价值在于“有章法”。大多数人在 Windows 上被 Docker 折腾得焦头烂额，不是因为命令不熟，而是出了问题不知道按什么顺序查。状态不行看日志，日志没有看配置，配置没问题查文件，文件路径不确定就进容器内部找。把这三层查完，几乎不存在找不到根因的情况。我个人在实际操作中最常用的组合是docker compose ps+ 挂载目录 +docker cp三件套：ps管状态，挂载目录管日常文件操作，cp管一次性导入导出。以后你在 Windows 上接手任何 Docker 项目，也可以从这套思路入手，先跑通服务再谈其他。

下期我可以接着聊容器日志的集中收集、数据卷备份与恢复，或者带数据库依赖的复杂服务在 Compose 里的编排注意点。先把查询和文件查看这两块基础打牢，后面任何进阶操作都不容易走偏。