必须先确认容器是否运行：docker ps仅显示“Up”容器，若未列出则用docker ps -a查状态；若为Exited或Created，需用docker logs查错因，再针对性修复。
docker exec -it 进不去？先确认容器是不是真在跑
执行 docker exec -it <container_name> /bin/sh</container_name> 报错 Error response from daemon: Container is not running，不是命令写错了，而是容器根本没活。Windows 上 Docker Desktop 启动失败、WSL2 未就绪、资源被占满，都可能导致容器秒退或压根没起来。
必须先查状态：
-
docker ps只显示“Up”状态的容器；如果看不到目标容器，立刻补查docker ps -a - 看 STATUS 列：如果是
Exited (1)或Created，说明启动失败或卡在初始化阶段 - 别信 Docker Desktop GUI 界面右下角那个“Running”图标——它只表示 Desktop 应用本身在跑，不等于容器在跑
容器显示 Exited？立刻看日志，别急着重启
容器启动后立刻退出，90% 是入口命令崩了，比如配置文件路径错、依赖服务没连上、权限不足。直接 docker start 很可能重复失败。
先抓最直接的线索：
- 运行
docker logs <container_name></container_name>，看最后一两行输出，重点关注FATAL、Permission denied、Connection refused这类关键词 - 加
-f参数（docker logs -f <container_name></container_name>）可实时跟踪，适合调试启动过程 - 如果日志空或只有时间戳，说明进程根本没跑起来——极可能是 CMD/ENTRYPOINT 指令执行失败，或者镜像里根本没有指定的可执行文件
进得去但找不到 bash？换 shell 或加 -i 参数
Windows 用户常遇到 docker exec -it <name> /bin/bash</name> 报 No such file or directory，不是路径写错，是镜像里压根没装 bash。Alpine 镜像默认只有 /bin/sh，Distroless 镜像甚至啥 shell 都没有。
应对方式很直接：
- 先试
/bin/sh：docker exec -it <name> /bin/sh</name> - 如果连
/bin/sh都报错，说明是 distroless 类型镜像，不能交互式进入，只能靠docker logs和暴露端口验证行为 - 确保加了
-i（interactive），漏掉它会导致 stdin 关闭，终端卡住不动
WSL2 后端下文件访问慢？别在 /mnt/c 下构建镜像
Windows 上用 WSL2 后端时，容器内读写挂载自 Windows 盘（比如 -v C:\myapp:/app）会明显变慢，尤其是 node_modules 安装、go build 这类高 I/O 操作。这不是 Docker 问题，是跨文件系统桥接的固有延迟。
临时排错可以接受，但长期开发请绕开：
- 把代码放 WSL2 文件系统里（如
/home/user/myapp），再用-v /home/user/myapp:/app挂载，性能接近原生 - 检查当前 WSL2 发行版是否为版本 2：
wsl -l -v，若显示Version 1，运行wsl --set-version <distro_name> 2</distro_name> - Docker Desktop 设置里关闭 “Use the WSL 2 based engine” 再重开，有时能重置挂载通道（慎用，会重启所有容器）
Windows 上 Docker Desktop 的排错链条很清晰：状态 → 日志 → 进程 → 文件系统。最容易被忽略的是 WSL2 版本和挂载路径选择，这两点不调好，后面所有操作都会拖慢半拍甚至误导判断。
