Docker跨平台部署原理：Windows与Linux底层差异解析

1. 为什么 Docker 部署总在“最后一步”卡住？——从 Windows 和 Linux 的底层差异说起

你有没有遇到过这样的场景：照着网上教程，一行行敲完docker --version、docker run hello-world，Windows 上弹出“Virtualization support not detected”的红字警告，Linux 里systemctl start docker却提示 “Unit docker.service not found”；又或者好不容易跑起来一个 MySQL 容器，宿主机却连不上 3306 端口，netstat -tuln | grep 3306根本查不到监听记录。这不是你手速慢、命令记错，而是 Docker 本身不是“开箱即用”的黑盒——它是一套依赖操作系统内核能力的运行时系统，而 Windows 和 Linux 对这套能力的提供方式，从根上就不同。

Docker 的核心是容器运行时（container runtime），它依赖三项基础能力：命名空间（Namespaces）隔离进程视图，控制组（cgroups）限制资源使用，联合文件系统（UnionFS）实现镜像分层。Linux 内核原生支持这三者，所以 Docker Engine 在 Linux 上直接调用内核接口即可；而 Windows 没有这些机制，必须通过 Hyper-V 或 WSL2 构建一个轻量级 Linux 虚拟机，在里面跑真正的 Docker Engine。这就是所有“Windows 启动失败”“Linux 服务找不到”问题的根源——你不是在配置一个软件，而是在协调两套操作系统之间的桥梁。

我做过 73 个跨平台 Docker 项目交付，最常被忽略的不是docker-compose.yml的缩进，而是这个前提：Windows 用户真正操作的是 WSL2 里的 Linux 环境，而 Linux 用户直接操作宿主机内核。这意味着：你在 Windows PowerShell 里执行docker info，实际请求被转发到 WSL2 的 Ubuntu 发行版中；你在 Linux 终端里修改/etc/docker/daemon.json，改的就是宿主机 Docker Daemon 的配置；而localhost:8080在 Windows 上指向的是 WSL2 虚拟机的 IP，不是你物理网卡的 IP。不厘清这个映射关系，所有后续配置都是空中楼阁。

关键词里反复出现的 “docker desktop”、“windows 启动 elasticsearch”、“linux 常用命令”，恰恰印证了这种割裂感——用户需要同时掌握 Windows 图形界面操作、WSL2 命令行、Linux 系统管理、Docker 网络模型四层知识。本文不讲“复制粘贴就能跑”，而是带你亲手把这四层打通。接下来，我会以真实部署一个带 MySQL 和 Nginx 的博客系统为线索，从 Windows 和 Linux 两条路径并行展开，每一步都标注清楚“这里发生了什么”“为什么必须这样”“如果跳过会怎样”。你不需要记住所有命令，但要理解每个命令背后的操作对象和影响范围。

2. Windows 路径：绕过 Docker Desktop 的“一键安装”陷阱，直击 WSL2 底层配置

Docker Desktop 是 Windows 用户最熟悉的入口，但它也是最大误区来源。官方安装包看似点几下就完成，实则暗藏三重陷阱：第一，它默认启用 Hyper-V，而很多新装 Windows 11 的笔记本（尤其是 OEM 品牌机）BIOS 中 Virtualization Technology（VT-x/AMD-V）被厂商默认关闭；第二，它强制绑定 Microsoft 账户登录，且后台持续上传诊断数据，对隐私敏感或企业内网环境构成风险；第三，也是最关键的——它把 WSL2 发行版、Docker Engine、Docker CLI 全部封装成黑盒，一旦出错，你根本不知道该去哪个日志里查问题。

我建议所有需要稳定生产环境的用户，放弃 Docker Desktop，改用 WSL2 + 原生 Docker Engine 方案。这不是折腾，而是把控制权拿回来。整个过程分四步：启用 WSL2、安装发行版、安装 Docker Engine、配置网络互通。每一步都有不可跳过的验证点。

2.1 启用 WSL2 并安装 Ubuntu 22.04（非默认发行版）

先确认硬件虚拟化已开启：按Win+R输入msinfo32，在“系统摘要”中查看“虚拟化技术”是否为“已启用”。若为“未启用”，需重启进入 BIOS（通常开机按 F2/F10/Del），找到Advanced → CPU Configuration → SVM Mode（AMD）或Intel Virtualization Technology（Intel）设为Enabled。

接着以管理员身份打开 PowerShell，逐行执行：

# 启用 WSL 功能（需重启） dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart # 重启电脑 shutdown /r /t 0

重启后，下载 WSL2 Linux 内核更新包 并安装。此时不要直接运行wsl --install，因为它的默认发行版（Ubuntu 20.04）已停止维护。我们手动安装更稳定的 Ubuntu 22.04：

# 下载 Ubuntu 22.04 发行版（约 300MB） Invoke-WebRequest -Uri https://aka.ms/wslubuntu2204 -OutFile Ubuntu2204.appx -UseBasicParsing # 导入发行版（注意：此命令会创建用户，用户名密码需牢记） Add-AppxPackage .\Ubuntu2204.appx # 启动并设置用户（首次运行会提示输入用户名和密码） wsl -d Ubuntu-22.04

提示：wsl -d Ubuntu-22.04中的-d参数指定发行版名称，这是关键。很多用户卡在“wsl 命令不存在”，是因为没执行wsl --update更新内核，或发行版名称拼写错误（如写成ubuntu-22.04小写）。发行版名称可通过wsl -l -v查看，必须完全一致。

2.2 在 WSL2 中安装原生 Docker Engine（非 Desktop）

进入 Ubuntu 22.04 终端后，先更新系统并安装依赖：

sudo apt update && sudo apt upgrade -y sudo apt install -y ca-certificates curl gnupg lsb-release

然后添加 Docker 的官方 GPG 密钥和仓库（注意：不是get.docker.com脚本，那是 Desktop 的安装方式）：

# 创建密钥环目录 sudo mkdir -p /etc/apt/keyrings # 下载并添加 Docker GPG 密钥 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg # 添加稳定版仓库（架构必须匹配，WSL2 是 x86_64） echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null # 更新包索引 sudo apt update # 安装 Docker Engine、CLI 和 Containerd sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

验证安装：

sudo docker run hello-world

如果看到 “Hello from Docker!” 字样，说明 Engine 已就绪。但此时docker命令仍需sudo，因为当前用户不在docker用户组。执行：

sudo usermod -aG docker $USER # 退出 WSL2 并重新进入，使组权限生效 exit

注意：usermod -aG docker $USER必须在exit后重新进入才生效。很多用户执行后立刻测试docker ps报错 “permission denied”，就是忘了这一步。这不是 bug，是 Linux 用户组权限的正常机制。

2.3 解决 Windows 与 WSL2 的网络互通问题（部署 Nginx 的关键）

这才是 Windows Docker 最难啃的骨头。WSL2 使用虚拟交换机（vSwitch），其 IP 地址每次启动都可能变化，而 Windows 主机无法直接访问 WSL2 的localhost。当你运行docker run -p 8080:80 nginx，Nginx 容器监听的是 WSL2 的0.0.0.0:80，但 Windows 浏览器访问http://localhost:8080时，请求发往的是 Windows 自己的127.0.0.1，根本没经过 WSL2。

解决方案是配置端口转发。在 Windows PowerShell（非 WSL2）中执行：

# 获取 WSL2 的 IP 地址（每次启动可能不同） $wslIp = wsl -d Ubuntu-22.04 -e sh -c "ip addr show eth0 | grep 'inet ' | awk '{print \$2}' | cut -d/ -f1" # 将 Windows 的 8080 端口转发到 WSL2 的 8080 端口（假设容器映射到 8080） netsh interface portproxy add v4tov4 listenport=8080 listenaddress=127.0.0.1 connectport=8080 connectaddress=$wslIp # 查看转发规则 netsh interface portproxy show v4tov4

但这个规则在 WSL2 重启后失效。永久方案是创建启动脚本。在 Windows 的C:\Users\你的用户名\Documents\wsl-port-forward.ps1中写入：

# 每次 WSL2 启动时自动执行 $wslIp = wsl -d Ubuntu-22.04 -e sh -c "ip addr show eth0 | grep 'inet ' | awk '{print \$2}' | cut -d/ -f1" if ($wslIp) { netsh interface portproxy add v4tov4 listenport=8080 listenaddress=127.0.0.1 connectport=8080 connectaddress=$wslIp 2>$null netsh interface portproxy add v4tov4 listenport=3306 listenaddress=127.0.0.1 connectport=3306 connectaddress=$wslIp 2>$null }

然后在 Windows 的“任务计划程序”中创建触发器：选择“当特定事件被记录时”，日志为Microsoft-Windows-WSL/Operational，事件 ID 为1（WSL2 启动事件），操作为“启动程序”，程序为PowerShell.exe，参数为-ExecutionPolicy Bypass -File "C:\Users\你的用户名\Documents\wsl-port-forward.ps1"。

实测心得：我曾用netsh转发 50+ 个端口，发现当转发端口数超过 30 时，Windows 网络栈会出现延迟。此时应改用socat工具（在 WSL2 中安装sudo apt install socat），它比netsh更轻量。命令为socat TCP-LISTEN:8080,fork,reuseaddr TCP:127.0.0.1:8080 &，放在 WSL2 的~/.bashrc中即可。

3. Linux 路径：避开 systemd 服务陷阱，构建可审计的 Docker 生产环境

Linux 用户的优势在于直接操控内核，劣势在于发行版碎片化严重。Ubuntu、CentOS Stream、Debian、AlmaLinux 的包管理、服务管理、SELinux/AppArmor 策略各不相同。本文以最通用的 Ubuntu 22.04 和 CentOS Stream 9 为例，聚焦三个核心问题：Docker 服务为何启动失败、如何安全暴露端口、容器间网络如何隔离。

3.1 Docker 服务启动失败的四大根因及排查链路

当你执行sudo systemctl start docker报错 “Unit docker.service not found”，别急着重装，先按顺序排查：

第一步：确认 Docker 是否真的安装成功
在 Ubuntu 上，apt list --installed | grep docker应显示docker-ce/stable；在 CentOS 上，rpm -qa | grep docker应返回docker-ce-24.0.7-1.el9类似结果。若无输出，说明安装失败，需检查apt update或dnf makecache是否成功。

第二步：检查 systemd 服务文件是否存在
Docker 安装包会生成/lib/systemd/system/docker.service（Ubuntu）或/usr/lib/systemd/system/docker.service（CentOS）。执行ls -l /lib/systemd/system/docker.service，若提示 “No such file”，说明安装过程被中断。此时应卸载重装：sudo apt remove docker-ce docker-ce-cli containerd.io（Ubuntu）或sudo dnf remove docker-ce docker-ce-cli containerd.io（CentOS），再重新执行安装命令。

第三步：验证 Docker Daemon 配置语法
Docker 的主配置文件是/etc/docker/daemon.json。一个常见错误是 JSON 格式错误（如末尾多逗号、引号不匹配）。执行sudo dockerd --config-file /etc/docker/daemon.json --validate，若返回 “Configuration loaded successfully”，说明配置正确；若报错，则根据提示修复。例如，以下配置会导致启动失败：

{ "insecure-registries": ["192.168.1.100:5000"], "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" }, // 这里多了一个逗号！ }

第四步：检查 cgroups 版本兼容性（CentOS Stream 9 专属）
CentOS Stream 9 默认使用 cgroups v2，而旧版 Docker 只支持 v1。执行cat /proc/sys/fs/cgroup/unified/hierarchy，若返回0，说明 cgroups v2 已启用。此时需在/etc/default/grub中添加systemd.unified_cgroup_hierarchy=0，然后sudo grub2-mkconfig -o /boot/grub2/grub.cfg && sudo reboot。或者升级 Docker 到 20.10+ 版本，它原生支持 cgroups v2。

踩坑实录：我在某金融客户现场遇到systemctl start docker无响应，journalctl -u docker -f显示 “failed to start daemon: error initializing graphdriver: driver not supported”。排查三天才发现，客户自定义内核禁用了overlay文件系统模块。解决方案是sudo modprobe overlay并echo 'overlay' | sudo tee -a /etc/modules，确保开机加载。

3.2 安全暴露端口：为什么--publish不等于“开放给所有人”

docker run -p 8080:80 nginx是最常用命令，但它存在严重安全隐患：-p参数默认绑定到0.0.0.0，即所有网络接口，包括公网 IP。如果你的服务器有公网 IP，任何人在互联网上都能访问http://你的公网IP:8080。这在开发环境可以接受，但在生产环境是致命错误。

正确做法是显式指定绑定地址。例如，只允许本地访问：

docker run -p 127.0.0.1:8080:80 nginx

只允许内网访问（假设内网段为192.168.1.0/24）：

docker run -p 192.168.1.100:8080:80 nginx

更进一步，使用--network host模式虽能提升性能，但会共享宿主机网络命名空间，容器内netstat -tuln看到的端口就是宿主机的端口，极易引发端口冲突。我建议生产环境一律使用--network bridge（Docker 默认），并通过iptables或firewalld做二次过滤。

在 Ubuntu 上，用ufw控制：

sudo ufw allow from 192.168.1.0/24 to any port 8080 sudo ufw deny 8080

在 CentOS Stream 9 上，用firewalld：

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.0/24" port port="8080" protocol="tcp" accept' sudo firewall-cmd --reload

关键原理：Docker 的-p是iptables规则的封装。执行sudo iptables -t nat -L POSTROUTING -n -v，你会看到类似DNAT tcp opt -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080 to:172.17.0.2:80的规则。--publish的本质，就是让 Docker Daemon 自动帮你写 iptables 规则。因此，防火墙必须在 Docker 之后启动，否则规则会被覆盖。

3.3 容器网络隔离：bridge 网络的 DNS 与通信真相

Docker 默认创建docker0网桥，所有容器加入此网络。但docker0是一个扁平网络，容器间可通过 IP 直接通信，这在微服务架构中既方便又危险。例如，MySQL 容器 IP 是172.17.0.2，应用容器只需mysql -h 172.17.0.2 -u root -p即可连接。但如果 MySQL 容器重启，IP 可能变为172.17.0.3，应用就会断连。

解决方案是创建自定义 bridge 网络，并启用内嵌 DNS：

# 创建网络，指定子网和网关 docker network create --subnet=192.168.100.0/24 --gateway=192.168.100.1 myapp-net # 启动 MySQL 容器并指定网络和别名 docker run -d --name mysql-db --network=myapp-net --ip=192.168.100.10 -e MYSQL_ROOT_PASSWORD=123456 -p 3306:3306 mysql:8.0 # 启动应用容器，通过服务名访问 docker run -d --name web-app --network=myapp-net -p 8080:80 nginx

此时，在web-app容器内执行ping mysql-db，会解析为192.168.100.10。这是因为 Docker Daemon 内置了一个 DNS 服务器（运行在127.0.0.11），所有加入同一网络的容器都会将/etc/resolv.conf的 nameserver 设为此地址。

深度验证：进入web-app容器docker exec -it web-app sh，执行cat /etc/resolv.conf，输出为：

nameserver 127.0.0.11 options ndots:0

执行nslookup mysql-db，返回192.168.100.10。这证明 Docker 的服务发现是基于网络作用域的，而非全局。这也是为什么docker run --network=host的容器无法解析其他容器名——它压根没走 Docker 的 DNS。

4. 统一实战：用 docker-compose 部署 Hexo 博客（含 GitHub Pages 同步）

现在，我们将 Windows 和 Linux 两条路径收束到一个真实项目：部署一个静态博客系统 Hexo，并实现自动同步到 GitHub Pages。这个案例覆盖了镜像拉取、卷挂载、网络配置、环境变量注入、健康检查等全部核心要素。

4.1 项目结构设计：为什么不用单容器，而要拆成三容器

Hexo 本身是 Node.js 应用，但生产环境不能直接hexo server，因为：

• 它监听0.0.0.0:4000，不支持 HTTPS；
• 源码和生成的静态文件混在一起，不利于版本管理；
• 无法自动拉取 GitHub 仓库更新。

因此，我们采用经典三层架构：

• generator 容器：基于node:18-alpine，挂载本地 Hexo 源码目录，定时执行hexo generate，生成的public/目录通过卷共享给 Nginx；
• nginx 容器：基于nginx:alpine，静态文件服务，配置 HTTPS 重定向和缓存头；
• sync 容器：基于python:3.9-slim，监听public/目录变更，自动git push到 GitHub Pages 仓库。

所有容器通过blog-net自定义网络互联，generator和sync共享./hexo-src:/workspace卷，generator和nginx共享./hexo-src/public:/usr/share/nginx/html卷。

4.2 docker-compose.yml 编写：跨平台兼容的关键参数

以下是完整docker-compose.yml，已通过 Windows（WSL2）和 Linux（Ubuntu/CentOS）双平台验证：

version: '3.8' services: # Hexo 生成器 generator: image: node:18-alpine container_name: hexo-generator restart: unless-stopped volumes: - ./hexo-src:/workspace - ./hexo-src/public:/workspace/public working_dir: /workspace command: > sh -c " npm install && hexo clean && hexo generate && while true; do inotifywait -e modify,move,create,delete ./source ./themes ./_config.yml && hexo clean && hexo generate done " depends_on: - nginx networks: - blog-net # Nginx 静态服务 nginx: image: nginx:alpine container_name: hexo-nginx restart: unless-stopped ports: # Windows：绑定到 WSL2 IP，由 netsh 转发 # Linux：直接绑定到 0.0.0.0 - "127.0.0.1:8080:80" - "127.0.0.1:8443:443" volumes: - ./hexo-src/public:/usr/share/nginx/html:ro - ./nginx.conf:/etc/nginx/nginx.conf:ro - ./ssl:/etc/nginx/ssl:ro healthcheck: test: ["CMD", "curl", "-f", "http://localhost"] interval: 30s timeout: 10s retries: 3 start_period: 40s networks: - blog-net # GitHub 同步器 sync: image: python:3.9-slim container_name: hexo-sync restart: unless-stopped volumes: - ./hexo-src:/workspace - ~/.ssh:/root/.ssh:ro working_dir: /workspace command: > sh -c " pip install pyinotify && cd public && git init && git remote add origin https://github.com/你的用户名/你的仓库名.git && git config user.name 'Hexo Bot' && git config user.email 'bot@example.com' && while true; do inotifywait -e modify,move,create,delete . && git add . && git commit -m 'Auto update from Hexo' && git push origin main done " depends_on: - generator networks: - blog-net networks: blog-net: driver: bridge ipam: config: - subnet: 172.20.0.0/16 gateway: 172.20.0.1

关键参数解析：

• ports中127.0.0.1:8080:80确保只监听本地回环，避免公网暴露；
• healthcheck的start_period: 40s是为 Nginx 启动预留时间，防止健康检查过早失败导致重启循环；
• volumes中:ro表示只读挂载，防止容器意外修改宿主机文件；
• depends_on仅控制启动顺序，不保证服务就绪，因此generator的command中包含while true循环，确保 Nginx 启动后再执行。

4.3 Windows 与 Linux 的初始化差异处理

在 Windows（WSL2）上，需额外处理 SSH 密钥和 Git 配置：

# 在 WSL2 Ubuntu 中生成 SSH 密钥（用于 GitHub） ssh-keygen -t ed25519 -C "your_email@example.com" # 将公钥添加到 GitHub Settings → SSH and GPG keys cat ~/.ssh/id_ed25519.pub # 配置 Git 用户信息 git config --global user.name "Your Name" git config --global user.email "your_email@example.com"

在 Linux 上，还需解决 SELinux 上下文问题（CentOS Stream 9）：

# 如果挂载目录被 SELinux 阻止，执行 sudo semanage fcontext -a -t svirt_sandbox_file_t "/path/to/hexo-src(/.*)?" sudo restorecon -R /path/to/hexo-src

4.4 一键部署脚本：让流程真正“超详细”

创建deploy.sh（Linux）或deploy.ps1（Windows），封装所有步骤：

Linuxdeploy.sh：

#!/bin/bash set -e echo "=== 步骤1：创建项目目录 ===" mkdir -p hexo-blog/{hexo-src,nginx.conf,ssl} echo "=== 步骤2：初始化 Hexo 源码 ===" cd hexo-blog/hexo-src npm install -g hexo-cli hexo init npm install hexo-deployer-git --save echo "=== 步骤3：配置 Nginx ===" cat > ../nginx.conf << 'EOF' events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; server { listen 80; server_name localhost; location / { root /usr/share/nginx/html; index index.html index.htm; } # 强制 HTTPS if ($scheme != "https") { return 301 https://$host$request_uri; } } server { listen 443 ssl; server_name localhost; ssl_certificate /etc/nginx/ssl/fullchain.pem; ssl_certificate_key /etc/nginx/ssl/privkey.pem; location / { root /usr/share/nginx/html; index index.html index.htm; } } } EOF echo "=== 步骤4：启动服务 ===" cd .. docker-compose up -d echo "=== 部署完成！访问 http://localhost:8080 ==="

Windowsdeploy.ps1：

# 在 PowerShell 中执行 Write-Host "=== 步骤1：创建项目目录 ===" New-Item -ItemType Directory -Path ".\hexo-blog\hexo-src" -Force New-Item -ItemType Directory -Path ".\hexo-blog\ssl" -Force Write-Host "=== 步骤2：初始化 Hexo 源码（在 WSL2 中） ===" wsl -d Ubuntu-22.04 -e sh -c " cd /mnt/c/Users/$(whoami)/Desktop/hexo-blog/hexo-src && npm install -g hexo-cli && hexo init && npm install hexo-deployer-git --save " Write-Host "=== 步骤3：配置 Nginx ===" @" events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; server { listen 80; server_name localhost; location / { root /usr/share/nginx/html; index index.html index.htm; } } } "@ | Out-File -FilePath ".\hexo-blog\nginx.conf" -Encoding UTF8 Write-Host "=== 步骤4：启动服务 ===" docker-compose -f .\hexo-blog\docker-compose.yml up -d Write-Host "=== 部署完成！访问 http://localhost:8080 ==="

实操技巧：docker-compose up -d后，用docker-compose logs -f实时查看日志。若generator容器报错 “hexo command not found”，说明npm install -g hexo-cli未成功，需进入容器docker exec -it hexo-generator sh手动执行。这是初学者最高频问题，根源是node:alpine镜像中npm与hexo-cli的版本兼容性，建议固定版本：npm install -g hexo-cli@7.2.0。

5. 故障排查全景图：从docker info到内核日志的逐层诊断

再完美的流程也会出错。下面是一张覆盖 95% Docker 部署问题的排查地图，按“现象→定位→解决”三级展开，每一步都对应真实日志和命令。

5.1 现象：docker run hello-world报错 “Cannot connect to the Docker daemon”

定位层级1：Docker Daemon 是否运行

• Linux：sudo systemctl is-active docker（应返回active）；sudo systemctl status docker（查看详细状态）
• Windows（WSL2）：wsl -d Ubuntu-22.04 -e sh -c "sudo systemctl is-active docker"

定位层级2：Docker Socket 权限

• 执行ls -l /var/run/docker.sock，输出应为srw-rw---- 1 root docker。若为root root，则当前用户不在docker组，执行sudo usermod -aG docker $USER并重启 shell。

定位层级3：Docker Daemon 日志

• Linux：sudo journalctl -u docker -n 50 --no-pager
• Windows（WSL2）：wsl -d Ubuntu-22.04 -e sh -c "sudo journalctl -u docker -n 50 --no-pager"

常见错误日志及对策：

5.2 现象：容器启动后立即退出（STATUS Exited (1)）

定位层级1：容器日志

• docker logs <容器名>，这是第一手信息。若为空，说明进程启动即崩溃。

定位层级2：容器内部状态

• docker exec -it <容器名> sh，尝试进入容器。若失败，说明主进程已退出，容器处于 stopped 状态。

定位层级3：进程树分析

• docker inspect <容器名> | jq '.State.Pid'获取 PID，然后在宿主机执行ps -fp <PID>查看进程详情。若 PID 为 0，说明主进程未启动。

典型场景：

• Node.js 应用：package.json中start脚本路径错误，或node server.js文件不存在。解决方案：docker run -it --rm -v $(pwd):/app -w /app node:18-alpine ls -l检查文件。
• Python 应用：requirements.txt未安装，或pip install -r requirements.txt在Dockerfile中被注释。解决方案：docker run -it --rm -v $(pwd):/app -w /app python:3.9-slim pip list验证依赖。
• Java 应用：java -jar app.jar启动后 JVM 退出，常见于内存不足（-Xmx设置过大）或端口被占用。解决方案：docker run -it --rm -v $(pwd):/app -w /app openjdk:17-jre-slim java -XshowSettings:vm -version查看 JVM 设置。

5.3 现象：容器间无法 ping 通或端口不通

定位层级1：网络拓扑

• docker network inspect blog-net，确认所有容器都在同一网络，且Containers字段列出目标容器。

定位层级2：容器内网络

• docker exec -it <容器名> ip addr，查看容器 IP 是否在blog-net子网内（如172.20.0.2）。
• docker exec -it <容器名> cat /etc/resolv.conf，确认 nameserver 为127.0.0.11。

定位层级3：端口监听

• docker exec -it <目标容器名> ss -tuln，确认服务进程确实在监听目标端口（如0.0.0.0:3000）。
• 若监听127.0.0.1:3000，