容器状态卡在created表示Docker Engine仅完成元数据创建但未调用containerd启动init进程，主因包括镜像入口命令异常、宿主机资源锁死或WSL2下cgroups初始化失败。
容器状态卡在 created 是 Docker Engine 没执行启动动作，不是容器内部问题
这说明 docker run 或 docker start 命令只完成了容器创建（分配 ID、挂载点、网络命名空间等），但没真正调用 containerd 启动 init 进程。常见于镜像入口命令异常、宿主机资源锁死、或 WSL2 下 cgroups 初始化失败。
注意：created 和 exited 有本质区别——前者根本没跑起来，后者是跑完就退出。别急着查日志，先确认是否真“启动过”：
- 运行
docker ps -a，看 STATUS 列是否稳定显示Created（不是一闪而过） - 执行
docker start -a <container_id></container_id>，观察终端是否有输出或立即返回；若卡住无响应，大概率是 exec 过程被阻塞 - 检查
docker info是否能正常返回，若报Cannot connect to the Docker daemon，说明 Docker Engine 本身未就绪，created只是表象
wsl --shutdown 后仍卡 created，大概率是 WSL 发行版处于僵尸状态
Docker Desktop 在 WSL2 后端下依赖 wsl.exe --list --verbose 获取发行版状态。如果某个发行版（比如 Ubuntu-20.04）上次被强制终止，注册表里状态仍是 Running，但实际进程已消失，wsl.exe 调用就会超时，导致 Docker Engine 无法推进到容器启动阶段——所有后续 run 都会卡在 created。
验证方法：在 PowerShell 中执行
wsl --list --verbose
看是否有发行版显示 Running 但你确定它没在跑。再执行
wsl -d Ubuntu-20.04
若卡住几秒后报错 CommandTimedOut 或直接无响应，就是典型僵尸发行版。
修复操作（必须按顺序）：
- 先执行
wsl --shutdown（杀掉所有 WSL 实例） - 再手动注销问题发行版：
wsl --unregister Ubuntu-20.04 - 重装该发行版（从 Microsoft Store 或
wsl --install），不要复用旧导出包 - 重启 Docker Desktop，此时
docker run才可能真正走到running
Linux/macOS 上容器卡 created，优先检查 systemd 或 launchd 服务状态
macOS 和 Linux 版 Docker Desktop 依赖后台服务托管 containerd 和 dockerd。如果 com.docker.vmnetd（macOS）或 docker.service（Linux）没起来，docker run 就只能创建容器元数据，无法触发真正启动。
排查步骤：
- macOS：运行
launchctl list | grep docker，确认com.docker.vmnetd和com.docker.driver.amd64-linux状态为 0（正常）；若显示not found或负数，执行sudo /Applications/Docker.app/Contents/MacOS/Docker --uninstall后重装 - Linux：运行
sudo systemctl status docker.service，若为inactive (dead)，执行sudo systemctl start docker.service；若报Failed to start docker.service: Unit docker.service not found，说明 Docker Desktop 未安装服务单元，需改用官方.deb/.rpm包而非 AppImage - 无论哪一平台，都别跳过
sudo journalctl -u docker.service -n 50 --no-pager（Linux）或log show --predicate 'subsystem == "com.docker"' --last 1h（macOS），重点搜failed to mount、cgroups v2、permission denied
镜像 ENTRYPOINT 或 CMD 写错也会让容器永远停在 created
这不是 Docker Desktop 的 bug，而是 OCI 规范行为：如果镜像指定的启动命令路径不存在、权限不足、或是个空字符串，runc 会在 exec 阶段直接失败，不抛异常也不退出，容器就卡在创建完成但未启动的状态。
典型错误写法：
ENTRYPOINT ["/bin/sh", "-c", "sleep 10"] # ✅ 正常
ENTRYPOINT ["nonexistent-binary"] # ❌ 卡 created
CMD [""] # ❌ 卡 created（空数组）
快速验证方式：
- 用
docker image inspect <image_name></image_name>查看Config.Entrypoint和Config.Cmd字段是否合理 - 换一个基础镜像测试：
docker run --rm hello-world，如果它能跑通，说明环境没问题，问题出在你自己的镜像构建逻辑上 - 临时覆盖启动命令：
docker run --rm -it <your_image> sh</your_image>，若能进 shell，证明镜像是好的，只是原ENTRYPOINT有缺陷
真正难排查的是那些依赖宿主机内核特性（如 memcg、pid namespace）的镜像——在 WSL2 或某些 macOS 虚拟化层下，runc 可能静默失败而不报错，最终只留下一个 created 容器。这种时候，别只盯着 Docker 日志，得去翻 /var/log/syslog（Linux）或 Console.app 里 kernel panic 类提示。
