企业官网建设流程全解析

很多朋友第一次在Windows上接触Docker，都是兴冲冲下载了Docker Desktop，双击安装，结果一启动就被一个红底白字的报错画面拦住——virtualization support not detected。这一下就卡住了，搜索引擎上翻半天，答案五花八门，试了也不一定好使。

这篇文章我不打算只给一条安装命令。我会把从选后端、查环境、装软件，到第一次跑通MySQL和Redis，最后再给你一份高频命令大全的完整链路走一遍。文章里凡是带“我建议”“我踩过”字样的，都是我实际遇到过的问题，不是从文档里抄来的。Windows上装Docker这件事，麻烦从来不在“下载安装包”这一步，而在你根本没意识到的系统环境细节里。

1. 先别急着装：Windows上Docker的两种后端选型与适用人群

1.1 为什么要先选后端而不是直接装

Docker本身是Linux下的容器技术，Windows上跑Docker容器，靠的是虚拟机把Linux内核拉起来。Docker Desktop在Windows上有两套后端实现：WSL 2和Hyper-V。它们干的活是一样的——提供一个Linux虚拟机环境给容器用——但底层的虚拟化方式、资源消耗、日常体验差别不小。

很多人不知道这个区别，直接下载Docker Desktop默认装完，发现启动不了，或者启动后内存被吃掉一大块，这就是后端没选对。Docker Desktop从4.x版本开始，也把WSL 2作为默认后端，但前提是你系统里的WSL 2得先装好。这一步如果你事先没做，安装过程就会卡在“Install required Windows components for WSL 2”这个环节。

所以我的建议是：装Docker Desktop之前，先把WSL 2准备到位。这个顺序最稳。

1.2 WSL2后端和Hyper-V后端的核心差异

我直接给你一张对比表，把两套后端的核心差异列清楚，看完你就能判断自己该选哪套。

我在实际使用中的感受是：WSL 2后端下，Docker Desktop冷启动到能跑docker ps，基本10秒内搞定；Hyper-V后端经常要等30秒以上。日常开发用WSL 2完全够，而且和VS Code的Remote-WSL插件配合起来非常顺。

1.3 什么情况下你必须用Hyper-V

虽然WSL 2是默认首选，但有两类情况你得反向选择Hyper-V后端。

第一，你本机装了VMware Workstation或VirtualBox，而且日常工作和这些虚拟化平台强绑定。Hyper-V和这些第三方虚拟化软件会争抢CPU的虚拟化指令，通常表现为VMware虚拟机无法嵌套开启虚拟化，或者Docker Desktop反复崩溃。WSL 2也依赖Hyper-V架构，但它是独立实现的，和VMware冲突相对小一些。但如果你连WSL 2都不想用，那就只能关闭Hyper-V相关功能，改用Docker Toolbox——这里我不建议你再碰Toolbox，太老了，镜像都拉不动。

第二，你的公司安全策略锁死了WSL 2，不允许启用“适用于Linux的Windows子系统”这个功能。这种情况下，Hyper-V后端是官方支持的替代方案，只要你是专业版系统就能用。

1.4 老牌Docker Toolbox为什么不建议再用

可能有人会提：那我装Docker Toolbox行不行？那不是更轻量吗？

Docker Toolbox是Docker在Windows上最早期的方案，基于VirtualBox虚拟机跑一个完整的Linux环境，然后在里面运行Docker守护进程。它的问题非常明显：VirtualBox版本老旧，Docker引擎版本停留在Docker 19.03时代，镜像仓库很多新镜像都要求更高的容器运行时版本。而且它不支持WSL 2，文件共享、端口映射都有各种小毛病。你要是只是体验一下，装来玩玩可以；要是真想拿来做开发，趁早放弃。

2. 装机前必查的三件套：BIOS虚拟化、系统版本与WSL2内核

2.1 第一步：确认CPU虚拟化处于开启状态

这个步骤看起来基础，但大多数人启动Docker Desktop失败，根因就是这个开关没打开。

按Ctrl + Shift + Esc打开任务管理器，切到“性能”标签页，点左侧的“CPU”，看右下角的“虚拟化”状态。如果显示“已启用”，说明CPU的VT-x/AMD-V已经打开；如果显示“已禁用”，你就需要进BIOS/UEFI里把它打开。

进BIOS的方法，Win10/Win11下最稳妥的方式是：设置 → 系统 → 恢复 → 高级启动 → 立即重新启动。重启后会进入蓝色菜单，选“疑难解答 → 高级选项 → UEFI固件设置 → 重启”，就能直接进BIOS。不同主板上这个选项的名称不一样，常见的有Intel Virtualization Technology、VT-x、SVM Mode（AMD平台），把它设为Enabled，保存退出。

我上周刚帮一个朋友远程处理过这个问题，折腾了两个小时，最后发现是BIOS里虚拟化开关被某次系统更新重置了。这个“虚拟化”状态，装Docker之前一定要看一眼。

2.2 第二步：确认Windows版本与家庭版的特殊处理

Docker Desktop要求Windows 10 64位版本在2004（Build 19041）及以上，Windows 11全版本都可以。

重点说下Windows 10家庭版。家庭版默认没有Hyper-V功能，但这不影响你用WSL 2后端。你只需要确保系统版本够新，然后正常装WSL 2就行。很多教程说“家庭版必须用WSL 2，因为没有Hyper-V”，这句对，但前提是WSL 2也是基于虚拟化平台（VirtualMachinePlatform）的，这个组件在家庭版里同样可以手动开启，并不是说家庭版就不能虚拟化了。

如何确认系统版本：Win + R输入winver，在弹出的窗口里看版本号和Build号。低于19041的话，先去Windows更新把系统升上去再继续。

2.3 第三步：完整开启WSL2的“官方三连”

这里我给出完整的PowerShell操作流程，按顺序执行，必须用管理员权限打开PowerShell（开始菜单右键 → Windows PowerShell(管理员)或终端(管理员)）。

第一条命令，启用“适用于Linux的Windows子系统”功能：

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

第二条命令，启用“虚拟机平台”功能：

dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

执行完这两条，系统会提示重启。重启后继续。

第三条命令，把WSL默认版本设置为2：

wsl --set-default-version 2

如果你执行这条命令时提示需要更新WSL内核，或者直接报错，那就需要手动下载WSL2 Linux内核更新包。去微软官方文档里找“WSL2 Linux内核更新包”的下载链接，下载wsl_update_x64.msi安装即可。这一步很多教程会漏掉，但实际遇到的人非常多，尤其是Win10系统。

第四条命令，更新WSL到最新版本（Win10也支持）：

wsl --update

最后用这条命令验证WSL2状态：

wsl --status wsl -l -v

如果能正常输出版本信息，且状态里没有红字报错，环境准备就算通过了。

2.4 环境检查清单

我把上面所有检查项整理成一个清单，你可以按顺序打勾，全部通过再继续安装Docker Desktop。

• CPU虚拟化：任务管理器 → 性能 → CPU → 虚拟化，显示“已启用”
• 系统版本：winver≥ Build 19041
• 已启用WSL功能：PowerShell执行dism.exe两条命令成功
• 已启用虚拟机平台：同上
• WSL版本为2：wsl -l -v中VERSION列为2
• WSL内核已更新：wsl --update不报错

这一套检查下来大概需要10分钟，但它能帮你躲开后面90%的安装坑。

3. Docker Desktop安装全程与第一次启动的关键配置

3.1 下载安装包与安装过程中的两个选项

去Docker官网下载Docker Desktop for Windows安装包，大约500MB左右。如果下载缓慢，可以找个网络环境好的时间段再下，安装包本身没有强制校验版本。

双击安装文件，会进入安装向导。安装过程中有两个勾选项需要留意。

第一个是Install required Windows components for WSL 2，默认会勾上，保持勾选。这个选项的意思是，如果你的系统还没装WSL 2组件，安装程序会帮你补上。但我的建议是既然前面你已经手动装过了，这里它再执行一次也无妨，不会冲突。

第二个是Use WSL 2 instead of Hyper-V，如果你用的是WSL 2后端，这个必须勾上。如果你因为我上面提到的特殊情况必须使用Hyper-V后端，那这个选项不要勾。

安装完成后通常需要注销并重新登录一次Windows账户，或者重启系统。我实测过，重启最省心，不会遇到权限缓存问题。

3.2 第一次启动Docker Desktop前先设置好两处配置

安装好后先不要急着点开Docker Desktop，先做两件事。

第一件事，确认Docker Desktop默认引擎是WSL 2。打开Docker Desktop，进入Settings（右上角齿轮图标），在General选项卡里找到Use WSL 2 based engine，确保它是勾选状态。如果你看不到这个选项，说明你的Windows版本或组件不满足WSL 2要求，系统会提示你，这时候再回去补环境。

第二件事，到Resources → WSL Integration里，打开你希望和Docker联动的WSL发行版开关。比如你装了Ubuntu发行版，就把Ubuntu对应的开关打开。这样你在Ubuntu终端里直接敲docker ps、docker run这些命令也能用，非常方便。不打开的话，你只能在Windows下用PowerShell或CMD执行Docker命令，那就错失了一半体验。

3.3 给Docker配一个可用的镜像加速

完成上述配置后，Docker Desktop就能正常启动了。但在拉取第一个镜像之前，我强烈建议你先配置镜像加速。

原因很简单：默认的Docker Hub源在国内访问速度很不稳定，一个几百MB的镜像可能要拉到天荒地老，还经常拉取到一半连接中断。

镜像加速的配置位置：Settings → Docker Engine，在JSON配置里加上registry-mirrors字段。下面是一个示例：

{ "registry-mirrors": [ "https://docker.mirrors.ustc.edu.cn", "https://hub-mirror.c.163.com" ] }

提示：不同镜像加速源的可用性会变化，如果某个源失效，拉镜像时会报类似connection refused或timeout的错误，这时候去搜“docker镜像加速”找当前可用的源替换即可。阿里云也提供个人专属加速地址，需要登录容器镜像服务控制台获取，格式是https://xxxx.mirror.aliyuncs.com，有条件的可以配上。

配置完点击Apply & Restart，等Docker Desktop重启完成即可。

3.4 用hello-world做第一次冒烟验证

配置完镜像加速后，打开终端（PowerShell或Windows Terminal），执行：

docker version

如果能同时看到Client和Server两段信息，说明Docker引擎已经正常跑起来了。Server如果没有显示，说明Docker Desktop还在启动中，或者启动失败了，回到上一节的内容排查。

再执行一个经典的冒烟测试：

docker run hello-world

镜像会从配置的加速源拉取，然后打印一段说明文字，告诉你Docker安装成功。看到这段文字，你的Docker才算真正活过来了。

4. “virtualization support not detected”报错的完整排查链路

4.1 这个报错到底在说什么

我把这个报错单独拿出来写一节，因为它是Windows上装Docker后最普遍、也最容易劝退新人的问题。

报错全文一般是这个：

Docker Desktop failed to start because virtualisation support wasn't detected.

翻译过来就是：Docker Desktop启动失败，因为检测不到虚拟化支持。

这句话的信息量很大，但它没说清楚到底是哪一层虚拟化没通过。Docker Desktop在启动时，会依次检查CPU虚拟化、Hyper-V/WSL2组件、Hypervisor启动类型这几个维度，任何一个不满足，就统一抛这个错误。整个链路里有好多个闸口，光看报错你根本不知道卡在哪。

4.2 从BIOS到系统功能的六级排查顺序

我建议你按下述顺序逐项排查，这个顺序是从硬件到软件、从最底层到最上层的递进逻辑，效率最高。

第一级，按Ctrl + Shift + Esc打开任务管理器，确认CPU虚拟化为“已启用”。如果这里是“已禁用”，跳到BIOS设置里开启，上面2.1节已经说过具体方法。这是最常见的闸口，大约占所有案例的50%以上。

第二级，确认CPU是否支持SLAT（二级地址转换）。CPU是否支持SLAT可以用一个系统自带工具检查。在CMD或PowerShell里执行：

systeminfo

在输出里找到“Hyper-V 要求”这一节。如果显示“已检测到虚拟机监控程序。将不显示 Hyper-V 所需的功能。”，说明Hypervisor已经在跑；如果显示某个功能“状态: 否”，就按提示去开对应功能。如果显示“固件中已启用虚拟化: 否”，那还是回第一级。

第三级，检查Windows功能里Virtual Machine Platform和适用于Linux的Windows子系统是否都已启用。检查方法是：Win + R输入optionalfeatures，打开Windows功能窗口，往下滚动看这两个项是否被勾选。没勾选就勾上并重启。

第四级，检查Hypervisor是否正常启动。这一步很多人会忽略。在管理员PowerShell里执行：

bcdedit /set hypervisorlaunchtype auto

hypervisorlaunchtype这个启动类型如果被手动改成了off，或者系统异常把它重置掉了，Docker Desktop根本没法启动底层虚拟化服务。执行完这条命令，重启电脑。

第五级，排除第三方软件干扰。某些国产安全软件、系统优化工具会禁用虚拟化相关服务或篡改启动项。如果你装了这类工具，先临时退出或卸载，重启后再试一次Docker Desktop。

第六级，排查Windows安全中心的“内核隔离-内存完整性”设置。这个功能和虚拟化有冲突的情况我遇到过一次，当时是Windows 11系统，更新后Docker Desktop突然启动不了，折腾到最后发现是内存完整性开关被打开了。把Settings → 隐私和安全性 → Windows安全中心 → 设备安全性 → 内核隔离 → 内存完整性，关掉并重启后，Docker就恢复了。

4.3 排查链条中的几个“假修复”

排查过程中有几个操作看起来是在修复，实际上没什么用，我列出三个典型。

一是反复卸载重装Docker Desktop。我见过真的有人因为这个报错重装了五六遍，每次装完问题依旧。因为这个报错根因基本都在系统环境，Docker Desktop应用本身很少出问题。

二是在系统设置里乱调虚拟内存或性能选项。虚拟化开关和Windows的“性能选项”完全没关系，调了也白调。

三是手动改了WSL版本后发现没用。如果你用的是Hyper-V后端，wsl --set-default-version 2根本不解决问题，因为这条命令只管WSL，不管Hyper-V。

4.4 用hypervisorlaunchtype强制启动Hypervisor层

我再单独强调一下bcdedit这条命令，因为它确实能解决不少“看起来什么都配置好了但还是报错”的疑难杂症。

打开管理员PowerShell，执行：

bcdedit /set hypervisorlaunchtype auto

执行成功后会提示“操作成功完成”。如果提示“拒绝访问”，说明你的PowerShell不是管理员模式，右键重新以管理员身份打开再执行。

这条命令的作用是把Windows的Hypervisor启动方式设为自动，重启后生效。Docker Desktop在检测虚拟化支持时，会依赖这个Hypervisor层。系统某些更新或优化软件，可能把它改成了off，故意关掉了Hyper-V底层。强制设回auto，很多启动失败就迎刃而解。

4.5 其他容易撞上的启动失败报错处理

除了virtualization support not detected，还有两个高频启动报错。

一个是WSL 2 installation is incomplete。这个报错的意思是WSL2内核没装好，解决方案就是敲wsl --update，或者手动安装WSL2 Linux内核更新包。装完重启即可。

另一个是An unexpected error occurred while starting Docker Desktop。这种错误很笼统，多半是Docker的配置或缓存损坏了。解决方法是退出Docker Desktop，然后删除配置目录再启动。删除命令如下：

Remove-Item -Recurse -Force "$env:APPDATA\Docker" Remove-Item -Recurse -Force "$env:LOCALAPPDATA\Docker"

删完重新打开Docker Desktop，它会重新生成配置，恢复到初始状态。注意这个操作会清除所有本地镜像和容器数据，执行前确认你不心疼。

5. 装完就上手：用MySQL和Redis各跑一遍，验证Docker真的能用

5.1 跑一个带数据卷的MySQL 8.0

装好Docker不动手跑几个真实服务，等于没装。我选MySQL和Redis来验证，因为这是日常开发里最常用的两个中间件，而且它们能充分验证端口映射、数据卷、环境变量、容器日志这几项核心能力。

先跑MySQL 8.0。在终端里执行：

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

说一下这几个参数的含义，理解比死记重要。

-d表示后台运行容器。--name mysql8给容器起名字，方便后续用名字操作，而不是用随机容器ID。-p 3306:3306把宿主机的3306端口映射到容器的3306端口，这样你本机的数据库客户端（比如Navicat）才能连上。-e MYSQL_ROOT_PASSWORD=123456是MySQL镜像要求的环境变量，用来设置root密码，不设这个变量容器会因为缺少必要的初始化参数直接退出。-v mysql-data:/var/lib/mysql是命名数据卷，把MySQL的数据目录挂载到Docker管理的磁盘上，容器删了数据还在。

执行完后，用这条命令确认容器在运行：

docker ps

如果STATUS列显示Up，说明容器启动成功。然后进容器里执行SQL验证：

docker exec -it mysql8 mysql -uroot -p

输入密码（上面设置的123456）后进入MySQL命令行，执行show databases;，能看到information_schema、mysql、performance_schema、sys这几个默认库，就说明一切正常。

我实际操作中踩过一个坑：本机原来就装了MySQL，3306端口被占。启动容器时一直失败，docker logs mysql8里显示的却是正常启动的信息，但宿主机3306被占了，端口冲突导致容器一直处于启动重试状态。解决办法很简单，把宿主机的映射端口改掉：

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

这样宿主机用3307端口就能连上容器内的MySQL。

5.2 用docker compose一次性编排MySQL和Redis

Redis跑单条命令也能跑，但既然要体验Docker带来的工程化能力，我建议直接上Docker Compose。先在任意工作目录下新建一个docker-compose.yml文件，内容如下：

version: '3.8' services: mysql8: image: mysql:8.0 container_name: mysql8 restart: always environment: MYSQL_ROOT_PASSWORD: 123456 ports: - "3306:3306" volumes: - mysql-data:/var/lib/mysql redis: image: redis:7 container_name: redis7 restart: always ports: - "6379:6379" volumes: - redis-data:/data volumes: mysql-data: redis-data:

这个文件比单条命令看起来复杂，但其实很好理解。services下面定义了两个服务，mysql8和redis。restart: always表示容器如果崩了或Docker重启了，它会自动重新拉起，这个在生产环境里非常实用。volumes里定义的两个命名卷，给MySQL和Redis存储数据用。

在该目录下执行：

docker compose up -d

-d表示后台运行。执行完后用docker compose ps查看状态，两个服务都显示running就成功了。

这条命令用于把容器停掉并移除：

docker compose down

注意down会把容器和默认网络一并清理，但数据卷还在，数据不会丢。如果想连数据卷一起清理，要用docker compose down -v，这个命令要慎用，因为会把数据清空。

5.3 容器里看日志、看资源的基本姿势

容器跑起来之后，你迟早会遇到“我连不上MySQL了”“Redis响应超时”这类问题，这时候看日志是最快的定位方式。

查看MySQL容器日志：

docker logs mysql8

加上-f参数可以持续跟踪输出，类似tail -f：

docker logs -f mysql8

查看容器资源占用：

docker stats

这条命令会展示当前所有运行中容器的CPU、内存、网络、磁盘IO情况，而且是实时刷新的。按Ctrl + C退出。排查性能问题时有奇效。

如果你改动了某个容器但不想删掉重建，可以用：

docker restart mysql8

这会在停止容器后重新启动它，保留容器的所有配置和文件系统状态。

6. 高频命令速查表：镜像、容器、数据卷与Compose一页说清

6.1 镜像命令：搜索、拉取、删除与打标签

镜像就是一个只读模板，容器是它运行时的实例。这套逻辑类似编程里的“类与对象”，理解了这个，命令就不难记。

搜索Docker Hub上的镜像：

docker search nginx

拉取镜像到本地：

docker pull nginx:latest

列出本地已有镜像：

docker images

删除一个本地镜像：

docker rmi nginx:latest

给镜像打标签，常用于推送到私有仓库前：

docker tag nginx:latest myregistry.example.com/nginx:v1

把镜像推送远程仓库：

docker push myregistry.example.com/nginx:v1

提示：docker rmi是删镜像，docker rm是删容器，两者别搞混。我见过不少人rmi写顺手了，把容器ID也塞进去，结果报错Error: No such image，其实自己想删的是容器。

6.2 容器生命周期命令：run、exec、logs与排错

容器命令是整个Docker使用频率最高的一块，我分三组列。

第一组是启动和停止。

docker run -d --name nginx-demo -p 8080:80 nginx:latest

run最常见的写法是-d后台运行加-p端口映射。如果你想临时测试，不加-d，前台运行，按Ctrl + C就能停掉。也推荐加--rm参数，容器停止后自动删除：

docker run --rm -it -p 8080:80 nginx:latest

-it是交互式终端的组合参数，进容器里操作时用。日常操作命令还有：

docker ps # 列出运行中的容器 docker ps -a # 列出所有容器，包括已停止的 docker start nginx-demo docker stop nginx-demo docker restart nginx-demo docker pause nginx-demo # 暂停容器进程，不停止整个容器 docker unpause nginx-demo docker rm nginx-demo # 删除容器

第二组是进入容器和查看日志。

docker exec -it nginx-demo /bin/bash

exec在运行中的容器里执行命令，是最常用的进入容器方式。有些精简镜像没有/bin/bash，改成/bin/sh即可。

docker logs nginx-demo docker logs -f nginx-demo docker logs --tail 100 nginx-demo # 只看最后100行

第三组是文件拷贝和进程状态。

docker cp ./local-file.txt nginx-demo:/tmp/ docker cp nginx-demo:/etc/nginx/nginx.conf ./nginx.conf docker top nginx-demo # 查看容器内进程 docker inspect nginx-demo # 查看容器详细信息，JSON格式

docker inspect非常强大，网络配置、挂载卷、环境变量全在里面。遇到容器行为诡异时，先inspect看配置，再logs看日志，90%的问题都能定位。

6.3 数据卷和网络：让容器不“失忆”的两件套

容器是临时的，默认情况下删了就什么都没了。数据卷和网络是让容器“可持久化”和“可互通”的两个关键概念。

数据卷常用命令：

docker volume create my-data docker volume ls docker volume inspect my-data docker volume rm my-data

创建容器时挂载卷的两种方式：

# 方式一：命名卷，数据由Docker管理 docker run -d -v my-data:/data nginx:latest # 方式二：绑定挂载，挂载宿主机的具体目录 docker run -d -v /操作系统的绝对路径:/data nginx:latest

我用绑定挂载比较多，因为代码目录直接挂在宿主机上，改完代码容器里就能用，配合开发调试非常顺。

网络常用命令：

docker network ls docker network create my-net docker network inspect my-net docker network rm my-net

创建容器时指定网络：

docker run -d --network my-net --name nginx-demo nginx:latest

同一个网络里的容器之间可以直接用容器名互相访问，这就是Docker内置的DNS解析。比如MySQL容器叫mysql8，应用容器里配置数据库连接地址直接写mysql8:3306，而不是localhost:3306或IP。这个设计在docker compose里自动实现，也是容器编排的基础。

6.4 Docker Compose与清理命令

Compose命令以docker compose开头，日常用得最多的是这三条：

docker compose up -d docker compose ps docker compose logs -f

up -d启动所有服务，ps看状态，logs -f跟日志。再加两条：

docker compose down # 停止并移除容器，保留卷 docker compose down -v # 停止并移除容器，同时删除卷，数据会丢

还有带构建的自定义镜像项目会用到：

docker compose up -d --build

最后是清理命令，磁盘快满时的救命稻草。

docker system df # 查看Docker占用的磁盘空间 docker system prune # 清理所有未使用的资源（容器、网络、镜像缓存） docker system prune -a --volumes # 更彻底，会连未使用的镜像和卷一起清掉

docker system prune -a --volumes会把所有没在使用的镜像和卷一股脑清掉，有些镜像下次用还要重新拉，所以执行前确认一下。

6.5 命令易混点速记

最后列几个我见过无数人记混的对比项，一句话区分：

docker rm删容器，docker rmi删镜像。

docker exec在运行中的容器里执行命令，docker attach是进入容器的主进程，attach用不好容易直接停掉容器，新手尽量用exec。

-p 8080:80把宿主机的8080映射到容器的80，-P是随机分配宿主机端口。

docker start启动已停止的容器，docker run是创建并启动一个新容器。run包含pull（镜像不存在时）+create+start。

docker logs查日志，docker logs -f实时跟踪，docker logs --tail 100只看最后100行。日志文件如果很大，直接docker logs会刷屏刷到手软，记得带上--tail。

docker inspect查容器的详细信息，docker stats看资源占用，docker top看进程列表。排查问题时建议按logs → inspect → stats的顺序来。

这些命令不用背，用多了自然就记住了。最忌的是在不确定参数含义的情况下盲目执行，尤其是带-v、--force、prune这类有破坏性的命令，动手前先想清楚，或者先加--dry-run看效果（如果支持的话）。

我在Windows上把Docker折腾到能顺畅跑起来，前后也踩了不少坑。回头总结，最关键的其实不是命令记了多少，而是安装前那份环境检查清单做到位了没有——BIOS虚拟化、Windows版本、WSL2组件、Hypervisor启动类型，这四个关卡只要有一个没过，后面所有操作都是白费。你在安装过程中如果卡在哪一步，不妨回头再按第4节的排查顺序走一遍，很多时候问题就藏在你以为“肯定没问题”的那一层里。