导语：容器起不来，先别删了重建——90% 的问题就三类：端口冲突、路径挂载、依赖缺失。这一篇每类给典型报错 + 排查方法，一次讲清。
25 篇你学会了 docker compose up -d --build，28 篇学会了看日志。但容器还是会时不时起不来——别慌，90% 就三类问题，认出报错就能修。
一、三类问题总表
| 类型 | 典型报错（关键词） | 排查命令 |
|---|---|---|
| 端口冲突 | bind: address already in use |
ss -tlnp 查谁占着 |
| 路径挂载 | no such file or directory |
docker inspect 容器名 看挂载 |
| 依赖缺失 | ModuleNotFoundError / command not found |
docker logs 容器名 看报错 |
经验：先认出是哪类，再动手——三类对应三种修法，认错了就是瞎折腾。
二、逐类拆解
① 端口冲突：报 bind: address already in use
意思：你要用的端口，已经被别的进程/容器占了。
排查：
ss -tlnp # 看谁在监听这个端口（14 篇学过）
docker ps # 是不是另一个容器占着
修法（三选一）：
- 停掉占端口的进程/容器；
- 换映射端口：compose 里把
5000:5000改成5001:5000（25 篇的坑）； - 如果端口被你自己上次启动的容器占着——
docker ps -a找到它，删掉旧的再启动。
经验："端口被占"九成是你自己上次的容器还活着——docker ps -a 一看便知，别先怀疑系统。
② 路径挂载：报 no such file or directory
意思：挂载的目录/文件不存在，或容器里路径写错。
排查：
docker inspect 容器名 # 看 Mounts 部分，核对宿主机路径和容器路径
修法：
- 宿主机目录不存在 → 先创建（
mkdir -p）； - 路径写错 → 对照 compose 里的
- 宿主机路径:容器路径格式改； - 权限不足 → 检查目录权限，必要时
chmod/chown。
经验："左边宿主机、右边容器"别写反——左边是你服务器上真实存在的路径，右边是容器内部的路径（容器里没有，Docker 会自动建，但目录不存在时挂载会失败）。
③ 依赖缺失：报 ModuleNotFoundError / command not found
意思：镜像里没有你的应用需要的包/工具。
排查：
docker logs 容器名 # 看报错缺哪个模块
修法：
- 缺 Python 包 → 把依赖写进
requirements.txt（18 篇 Dockerfile 的COPY+pip install）； - 缺系统工具 → 在 Dockerfile 里
RUN apt-get install ...； - 改完 Dockerfile 必须重新 build：
docker compose up -d --build（25 篇的坑：改代码/依赖不重新 build 不生效）。
经验：依赖改了不重新 build = 白改——容器跑的是镜像里的旧依赖，重启（restart）不重新构建镜像，永远装不上新包。
三、通用排查三步（哪类问题都用得上）
- 看状态：
docker ps -a——Exited状态说明挂了，Restarting说明在反复重启（大概率配置错）。 - 看日志：
docker logs 容器名——报错原文在这里（28 篇）。 - 想改动：最近改了 compose？Dockerfile？代码？（29 篇黄金线索："最近改了啥"）。
经验：三步走完，还没定位就贴日志给 AI（29 篇提问模板）——报错原文 + 环境 + 最近改动，一次解决。
四、避坑清单
- 别删容器！先看状态：
docker ps -a的 Exited 状态自带原因提示，删了线索就没了（28 篇：先看日志再动手）。 - 报错贴原文：给 AI 的是
docker logs的原文，不是"它跑不起来"（29 篇）。 - 重启 ≠ 修复：改了 Dockerfile/依赖，
restart没用，必须--build重新构建。 - 端口被占先查：
ss -tlnp看谁占着，别直接换个随机端口（可能撞上别的服务）。 - 挂载目录先创建：
mkdir -p建好再启动，别等报错。
总结
- 三类问题：端口冲突（
bind: address already in use）、路径挂载（no such file or directory）、依赖缺失（ModuleNotFoundError）。 - 各配一条命令：
ss -tlnp/docker inspect/docker logs。 - 通用三步：
docker ps -a看状态 →docker logs看日志 → 想"最近改了啥"。 - 核心心法：认出类型再修；改依赖/代码要重新
--build；先看再删，报错贴原文。
10 分钟小任务：故意制造一个"端口冲突"——把 compose 里端口改成 5000:5000（假设 5000 已被占用），启动看报错，再用 ss -tlnp 和 docker ps 找到"凶手"，最后换端口修复。亲手搞挂再亲手修好，比看十篇教程都管用。 下一篇，学 AI 时代的保命课：别把密钥喂给 AI。
下一篇：AI 协作安全：别把密钥喂给 AI，别直接跑看不懂的代码。