Docker启动超时怎么办？从引擎到服务一层层排查

前几天下午，我在终端敲下docker compose up -d，日志滚动了几行之后突然停住，光标在waiting for server to start...后面一直闪。过了十几秒，一排红字出来了：timeout。紧接着，消息提示框弹出一条“容器启动超时”。当时我手头有一个测试环境正在被别人用，数据库和缓存都在 Docker 里跑着，这行超时提示一出来，我心里是真的"咯噔"一下——不夸张地说，惊出一身汗。

这个标题估计能戳中不少人的经历：Docker 启动超时。它可能发生在 Docker Desktop 双击图标后半天起不来，也可能发生在docker run命令执行后长时间卡住，还可能发生在容器 STATUS 已经是 Up 但里面真正的服务迟迟不就绪，最后被健康检查判了"超时死刑"。很多人在这一步就开始慌了，反复重启 Docker、反复删容器重建，但问题依旧。其实启动超时不是一个单一故障，它是好几种不同层面的问题共同表现出来的"统一症状"。只有先把症状分类，才能对症下药。

这篇文章我就从自己那次"被吓出汗"的排查过程说起，把 Docker 启动超时可能出现的三种舞台、完整排查链路、以及每种场景的具体解法全部拆开讲一遍。内容涉及 Docker Desktop、WSL2、PostgreSQL/MySQL 这类常用容器、docker compose编排、镜像拉取等高频场景，适合刚上手 Docker 的新人，也适合被超时问题折磨过、想彻底理清排查思路的老手。

1. 惊吓现场：那条 timeout 日志是怎么冒出来的

1.1 我在那条日志里看到了什么

我当时执行的是最普通不过的一件事：用docker compose把一个 PostgreSQL 服务拉起来。docker-compose.yml里写得很简单，端口映射、数据卷、环境变量，都是老一套。但这次和之前不一样，容器没有像往常一样几秒钟就进入健康状态。

启动 PostgreSQL 容器... 等待服务器启动... 超时（timeout）

docker ps -a一看，容器状态是Exited (1)。docker logs翻出来一看，最后几行是典型的 PostgreSQL 启动失败记录：

2024-xx-xx xx:xx:xx.xxx UTC [xxx] LOG: could not bind IPv6 socket: Cannot assign requested address 2024-xx-xx xx:xx:xx.xxx UTC [xxx] HINT: Is another postmaster already running on port 5432? 2024-xx-xx xx:xx:xx.xxx UTC [xxx] LOG: database system was interrupted; last known up at ...

看到这行日志，我心里稍微有数了：这不是 Docker 本身的问题，而是容器里的 PostgreSQL 在恢复过程中遇到了麻烦，导致整个启动流程超出了等待时限。但"超时"这个词太具有迷惑性了，它的表面意思会把你引到一个错误的方向——让你觉得"是不是网络慢""是不是 Docker 引擎卡了"。其实完全不是一回事。

1.2 为什么"等等就好了"是最危险的心理陷阱

遇到启动超时，人的第一反应经常是"再等等""多试几次"。这里我必须说一句：超时提示之后，再等下去的收益是很低的。因为超时提示本身就是一个"截止时间已到"的信号，意味着程序等到了它能够容忍的极限，内部往往已经做了失败处理。你接下来要做的不是继续等，而是立刻进入"查证据"模式。

第二个心理陷阱是"重启大法"。Docker Desktop的 Restart 按钮、systemctl restart docker、wsl --shutdown，这些操作确实能解决一部分"卡死"类问题，但它会把你排查问题的现场全部毁掉——日志可能被重置、容器状态可能被清理、临时文件可能消失。尤其是你还没搞清楚状况就重启 Docker，只会让"偶发性"问题变成"玄学"问题。正确的姿势是：先留存现场证据（日志、状态、配置），再做任何重启操作。

当时我强迫自己冷静下来，把"启动超时"这四个字拆成了三个问题：是 Docker 引擎没起来？还是容器进程没起来？还是容器里真正的业务服务没起来？这三个问题的排查路径完全不同，接下来我就按这个思路一层层说。

2. 启动超时的三个舞台：引擎、容器、服务各自演各自的

很多教程把 Docker 启动超时当成一个孤立问题来处理，这是不对的。实际使用中，它至少有三个完全不同的"舞台"，你在不同舞台上看到的超时场景、错误提示、修复手段都截然不同。把它们区分开，是解决问题的第一步。

2.1 引擎超时：连 docker version 都敲不出结果

Docker 引擎（守护进程）是真正负责拉镜像、起容器的核心服务。在 Windows 上它由 Docker Desktop 管理，在 Linux 上它是dockerd守护进程。引擎超时最典型的表现是：你敲任何 Docker 命令，终端都回你一句"连接超时"或"cannot connect to the Docker daemon"。

在 Windows 上的经典报错是：

failed to connect to the docker api at npipe:////./pipe/dockerdesktoplinuxen

或者 Docker Desktop 界面一直停留在 "Starting..."，等很久都没有进入"Engine running"状态。在 Linux 上则通常是systemctl start docker执行后卡住，或者docker info报：

ERROR: Cannot connect to the Docker daemon at unix:///var/run/docker.sock

引擎超时的根源基本集中在几个地方：底层虚拟化（WSL2/Hyper-V）没正常工作、Docker Desktop 的 Linux 子系统卡死、资源被占满导致守护进程起不来。热词里那条virtualization support not detected docker desktop failed to start就是典型的引擎层问题——你的 CPU 虚拟化功能在 BIOS 里被关掉了，Docker Desktop 直接罢工。

2.2 容器超时：docker start 卡在 Loading 状态

第二类超时发生在容器本身。引擎已经正常工作了，但你要启动的容器一直卡着。表现是docker start执行后长时间没有返回，或者docker ps里容器状态一直是Restarting、Created、Up (starting)。

容器层超时的常见原因，我总结下来大概有四类：

• 镜像拉取卡住：docker pull网络超时，镜像一直下不下来，导致后续步骤全部停摆。
• 端口冲突：宿主机端口已被其他进程占用，容器绑定端口时反复失败，进入重启循环。
• 数据卷挂载异常：挂载的目录权限不对，容器启动时无法读写，初始化逻辑一直失败。
• 资源限制：容器配置了过低的内存/CPU限制了，启动时申请不到足够资源，被系统反复杀掉（OOM）。

这类超时有个特点：Docker 引擎没毛病，docker ps 也能跑，但就是起不来想要的容器。很多人这时候会反复删容器重建，其实如果根源是端口冲突或卷权限问题，你删一百遍也一样失败。

2.3 服务超时：容器 Up 了但业务没起来

第三类最隐蔽，也是我那次遇到的真正问题：容器本身已经处于 Up 状态，但容器里面的服务没有就绪。比如 PostgreSQL 容器显示 Up，但数据库端口 5432 迟迟不可连接；MySQL 容器 Up 了，但mysqladmin ping一直在报错。

这类超时最终往往表现为外部访问失败、CI/CD 流水线里连接数据库超时、或者你手动敲docker logs看到一堆"waiting for server to start"的反复循环。容器没有崩溃、没有退出，但你面对的是一个"僵尸服务"——壳是活的，内核是死的。

如果你用的是docker compose加健康检查（healthcheck），这一层超时通常表现为：

healthcheck: unhealthy

服务层超时的根源一般更"深"，比如数据库崩溃恢复耗时太长、配置参数导致初始化 SQL 执行极慢、容器内资源不足、共享内存（/dev/shm）被限制得太小等。它很像是"程序员的程序在慢启动"，和 Docker 自身的关系反而没那么大。

2.4 三张脸对照表：快速判断你遇到的是哪一类

有了这张表，排查方向就不会乱。接下来我把我那次完整的排查链路还原出来，每一步都给出原因，保证你可以照着走一遍。

3. 顺藤摸瓜的完整排查链路：四条命令和两个判断逻辑

我在处理 Docker 问题时有一条铁律：任何超时问题，先确认"卡在哪一层"，再动手改任何配置。这条铁律能帮你省下大量"瞎试"的时间。下面是完整的排查步骤，每一步都对应明确的判断依据。

3.1 第一步：docker version 和 docker info 确认引擎状态

排查第一件事，是先确认引擎是否健康。敲：

docker version

如果这条命令在几秒内不返回结果，或直接报连接错误，问题基本锁定在引擎层。这个时候再去敲docker ps没有任何意义，因为引擎都不通，所有的容器操作都是空中楼阁。

如果docker version能正常输出，接下来敲：

docker info

这里重点看三样东西：

• Server Version：Docker 引擎版本是否正常。
• Storage Driver：存储驱动是否正常（一般 overlay2 没问题）。
• Docker Root Dir：磁盘路径是否还有剩余空间，配合df -h检查。

我遇到过一次docker info卡住的情况，最后定位到是磁盘 IO 被打满，Docker 守护进程在等待存储操作完成。所以在引擎层排查时，顺手看一眼：

df -h

如果/var/lib/docker（Linux）或 Docker Desktop 的虚拟磁盘所在位置使用率已经 95% 以上，超时问题很可能就是磁盘不足导致的。

3.2 第二步：docker ps -a 和 docker logs 定位容器卡点

引擎确认没问题后，看容器当前状态：

docker ps -a

这一步信息量巨大：

• 如果容器状态是Exited (1)，说明容器启动后立刻崩溃，看日志是最快的路径。
• 如果状态是Restarting，说明容器在"崩溃-重启"死循环里，通常和端口、健康检查、资源限制有关。
• 如果状态是Up (starting)或Up 5 seconds，说明容器进程活着，但内部服务可能还在初始化，或者初始化卡死了。

然后立刻查看日志：

docker logs --tail 200 <容器名>

日志是判断"容器碰到的真正问题是什么"的第一手证据。以 PostgreSQL 为例，docker logs里如果出现database system was interrupted、could not bind socket，那问题和网络、崩溃恢复有关；如果一直循环FATAL: could not create shared memory segment，那问题在容器共享内存限制上。

3.3 第三步：docker inspect 和 docker stats 看资源与配置

日志不一定能覆盖所有问题，尤其是当你怀疑是资源限制导致的超时时。这时候用两个命令交叉验证：

docker inspect <容器名> docker stats --no-stream

docker inspect里重点看：

• HostConfig.Memory和HostConfig.NanoCpus：容器被限制的资源规格。
• Mounts：数据卷挂载是否指向了正确路径。
• NetworkSettings.Ports：端口映射是否生效，是否存在目标端口冲突的可能。

docker stats看的是实时资源占用。如果容器一启动就冲到 100% 内存，随后被 OOM 杀掉然后重启循环，这就是典型的资源不足型超时。解决办法是调大容器内存限制，或者用--memory-swap给足交换空间。

3.4 第四步：回到 Docker Desktop 和 WSL2 看底层环境

如果在 Windows 上使用 Docker Desktop，前三步都查不到明显问题时，考虑底层子系统的问题。重点检查两个方向：

第一个方向是虚拟化是否启用。很多电脑的 BIOS 默认没有开启虚拟化，Docker Desktop 会给出明确提示：

virtualization support not detected

此时需要进入 BIOS 打开 VT-x/AMD-V，并确保 Windows 的"适用于 Linux 的 Windows 子系统"和"虚拟机平台"两个功能已开启。

第二个方向是 WSL2 是否正常。Docker Desktop 在 Windows 上依赖 WSL2 作为 Linux 内核运行环境，如果 WSL2 本身卡死，表现就是 Docker 引擎"永远在启动"。可以打开 Windows 终端执行：

wsl --status wsl --shutdown

wsl --shutdown会强制终止所有 WSL 实例，这相当于给 WSL2 做了一次"软重置"。在我实际处理过的案例里，这条命令解决掉的 Docker Desktop 卡死问题，占比相当高。注意，这个操作不会删除你的容器和数据，可以放心执行。

另外，Virtualization-based Security（VBS）和 Hyper-V 某些版本存在兼容性问题，如果排查后发现和虚拟化有关，可以尝试在"Windows 功能"里关闭虚拟机监控程序平台后重启，不少用户反馈这能解决 Docker Desktop 反复启动超时的问题。

3.5 时间分层法：用"等多久"判断超时发生在哪一层

排查经验丰富了以后，我总结出一个特别实用的判断技巧——时间分层法。你观察超时发生的时间点，就能快速锁定问题层级：

• 0~5 秒就失败：大概率是启动前的配置检查失败，比如端口冲突、卷挂载权限、Dockerfile 里CMD指定的命令不存在。
• 10~30 秒失败：容器已经拉起了，但初始化过程中资源不足，或者内部服务启动遇到瓶颈，数据库、缓存这类需要初始化数据的服务最常见。
• 超过 1 分钟甚至更久：要么是镜像拉取/网络问题，要么是容器内服务确实非常慢（比如 GitLab），要么是引擎本身在等待底层虚拟化资源。

这个判断方法不精确，但在前期快速定位方向上很有效。你不需要一开始就深挖日志细节，先通过"失败时间"判断大致位置，再针对性地去查对应的日志、配置和资源，效率会高很多。

4. 分场景按下重启键：引擎层、容器层、服务层的对症解法

排查链路走完之后，核心问题基本浮出水面。这一节我按层级给出具体的解决方案，都是实践中验证过的"对症药"。

4.1 引擎层超时：Windows 虚拟化与 WSL2 的检修清单

如果你的问题定位在引擎层，按下面的顺序依次检查，大部分都能解决：

检查 CPU 虚拟化是否开启

打开任务管理器，切换到"性能"标签，点击"CPU"，看右下角"虚拟化"是否显示"已启用"。如果显示"已禁用"，需要重启进入 BIOS，找到Intel Virtualization Technology（Intel 平台）或SVM Mode（AMD 平台），设置为 Enabled，保存退出。

确认 Windows 功能是否齐全

打开"控制面板 - 程序 - 启用或关闭 Windows 功能"，确保以下三项已勾选：

• 适用于 Linux 的 Windows 子系统
• 虚拟机平台
• Hyper-V（如果 Docker Desktop 用的是 Hyper-V 后端）

缺哪项补哪项，补完重启电脑。

升级并重置 WSL2

在管理员 PowerShell 里执行：

wsl --update wsl --shutdown

升级到最新 WSL2 内核后，很多旧版本的内核兼容性问题会消失。重置之后再启动 Docker Desktop，观察"Starting..."状态是否在 1 分钟内转入 "Engine running"。

检查 Docker Desktop 的引擎配置

打开 Docker Desktop 设置，进入Resources标签，确认内存分配不要太低。Windows 上默认通常为 2GB，如果机器内存够大，建议调到 4GB 以上。WSL2 后端模式下，Docker 引擎运行在轻量虚拟机里，内存给得太小会直接导致启动超时。

顺手清理 Docker Desktop 的锁文件

如果以上都不行，可能是 Docker 引擎残留了上次未正常退出的锁文件。在%AppData%\Docker或 WSL2 发行版里的/var/lib/docker下删掉*.lock文件，再重启 Docker Desktop。这个操作略激进，操作前建议先备份，但往往能解决"引擎起不来"的最后 10% 疑难杂症。

4.2 容器层超时：镜像加速与端口/目录冲突处理

引擎恢复健康后，容器层超时是最常遇到的一类。下面分两种情况展开。

镜像拉取卡住导致启动超时

很多人习惯直接docker run xx，但忽略了docker run会先去拉镜像。如果镜像太大或网络不稳，拉取过程可能耗时几分钟，期间 Docker CLI 会一直"卡住"，最终在终端表现为超时。解决方案分两步：

第一，单独执行docker pull把镜像先拉下来。比如：

docker pull mysql:8.0

确认镜像下载完成后，再进行docker run或docker compose up，这样"超时"的锅就不会甩给容器启动，而是清晰定位在镜像层。

第二，配置镜像加速。国内拉取 Docker Hub 镜像速度不稳定是现实问题，最直接的解法是在 Docker Desktop 的Docker Engine配置里，添加registry-mirrors加速地址。配置完记得点击 Apply & Restart，再用docker info查看Registry Mirrors是否生效。该配置能显著提升docker pull的稳定性，从根源上减少"镜像拉取超时"导致的启动失败。

端口冲突和数据卷权限问题

端口冲突的排查命令：

docker ps -a docker port <容器名> netstat -ano | findstr 5432

如果发现宿主机 5432 端口已经被别的进程占用，要么停掉占用进程，要么修改容器的端口映射：

ports: - "5433:5432"

数据卷权限问题在 Linux 上更常见。容器内的进程（比如 MySQL 的 mysql 用户）可能对挂载的宿主机目录没有写权限。解法是提前给目录放权：

sudo chown -R 1000:1000 ./data

1000:1000是多数官方镜像里非 root 用户的 UID:GID，具体值可以通过docker run --rm 镜像名 id 用户名来查。

4.3 服务层超时：给数据库足额的启动时间

服务层超时的根子在"容器内服务没能在默认等待时间内完成初始化"。数据库是重灾区，尤其是 PostgreSQL 和 MySQL。我那次遇到的正是这个。

PostgreSQL 的启动日志里典型的等待超时提示是：

waiting for server to start... LOG: database system was interrupted; last known up at ... LOG: database system was not properly shut down; automatic recovery in progress

数据库崩溃恢复（recovery）需要时间，尤其是数据量大、磁盘慢的情况下，恢复时间可能会超过 Docker 默认的等待窗口。这种情况要从两个方向处理：

方向一：延长容器编排里的启动等待时间。如果你用的是docker compose，在服务定义里加上：

healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres"] interval: 10s timeout: 5s retries: 12 start_period: 30s

start_period: 30s是关键，它告诉 Docker："给我 30 秒的宽限期，这段时间内健康检查失败不算失败。" 这样一来，即使数据库恢复耗时较长，容器也不会被过早打上 unhealthy 标签。

方向二：调整容器内服务的启动参数。如果经常因为数据库崩溃恢复导致超时，可以在 PostgreSQL 的启动命令里附上-c参数，降低恢复阶段的工作负载。比如：

command: > -c max_connections=100 -c shared_buffers=256MB -c fsync=off

最后一个参数fsync=off只建议在临时测试环境用，生产环境别动，否则磁盘故障时可能丢数据。它本身不直接影响启动等待时间，但能减少 IO 压力，间接缩短恢复时间。

对 MySQL 镜像来说，常见的服务层超时原因是初始化脚本执行太长。如果你挂载了/docker-entrypoint-initdb.d目录，容器第一次启动时要按顺序执行里面的.sql脚本。脚本多了、数据量大了，启动时间自然变长，外部连接就会报"连接超时"，但容器本身其实还在努力干活。这时候你要做的不是重启，而是等待并查看docker logs mysql是否还在滚动输出新的日志。日志还在滚动，说明进度没卡死，耐心等初始化完成即可。

4.4 compose 编排里怎么把"启动超时"提前消灭掉

很多超时问题不是"发生了才暴露"，而是"编排写得不合理，一开始就埋了雷"。合理的docker-compose.yml设计，能帮你挡掉一大半超时烦恼。这里分享几个关键设计：

• 服务启动顺序用健康检查来保证。不要直接用depends_on的默认行为——它只确保"依赖的容器启动了"，不保证里面的服务可用了。正确写法是让依赖方等待被依赖方的健康检查通过：

services: db: image: postgres:15 healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres"] interval: 5s timeout: 3s retries: 10 start_period: 20s app: image: my-app:latest depends_on: db: condition: service_healthy

这样一来，app 启动时，db 的 PostgreSQL 一定已经可以接受连接，不会出现"应用先起来了，连接数据库超时"的尴尬。

• 预留足够的 start_period。任何有初始化逻辑的服务（数据库、缓存、对象存储、代码托管平台）都要设置合理的start_period。我见过很多人在 healthcheck 里只配了interval和retries，却漏了start_period，导致服务启动过程中被误判为不健康，引发连锁的"重启超时"。

• Restart 策略要区分场景。开发环境无脑加restart: always确实方便，但你要明白：always意味着无论什么原因退出（包括代码 bug 导致的崩溃），Docker 都会尝试重启。如果容器因初始化速度慢而启动超时，always会触发更频繁的重启循环，反而让服务永远起不来。更稳妥的是restart: unless-stopped，至少手动停止的容器不会被强制拉起。

5. 被超时牵扯出来的连带坑：镜像拉取、权限、网络和高负载服务

超时问题往往不单独出现，它经常伴随着一长串"连带坑"。这些坑有时会伪装成超时，有时会加剧超时，排查的时候需要一并处理。

5.1 镜像下载慢导致的"启动假死"

docker run时如果镜像本地不存在，Docker 会先拉取镜像。网络一旦不稳，终端就会长时间停留在Pulling fs layer/Waiting状态。这个状态下你按 Ctrl+C 终止，再重新运行，大概率又卡在同一层。这其实不是启动超时，是镜像拉取超时。

处理办法在 4.2 已经说过，核心是两步：先单独docker pull，再配置镜像加速。这里再补充一个实践技巧：启动前先确认镜像在本地。敲：

docker images | grep postgres

如果镜像已经存在，docker run就不会走网络，启动速度会快很多，也可以避免"假死"状态带来的误导。

5.2 权限不足被误判成超时

很多新手在 Linux 上装完 Docker 后，直接敲docker ps，报错是：

Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock

这个提示本身不叫超时，但如果你配合sudo systemctl start docker一起使用，可能会看到启动流程卡顿，误以为超时。实际上问题很明确：当前用户不在docker用户组里。

解法：

sudo usermod -aG docker $USER newgrp docker

重新登录终端后，docker ps就能正常执行了。这一步比重启 Docker 引擎有意义得多。

5.3 容器网络异常引发的连锁慢启动

另一种容易被误判为超时的情况，是 Docker 网络初始化失败。表现是容器本身启动没问题，但访问容器内服务时总是超时。这类问题通常和 Docker 的 bridge 网络有关。

快速确认方式：

docker network ls docker network inspect bridge

如果发现网络状态异常，或容器没出现在预期网络上，可以重建容器并显式指定网络：

docker network prune docker run --network=bridge ...

如果在docker compose里自定义了网络，还可以尝试：

docker compose down docker compose up -d

down会把旧的网络一起清掉，再up时重新创建网络，很多"网络连接超时"的玄学问题，用这个重置大法能解决一半。

另外，热词里有一条docker 网络不通，这通常伴随容器之间无法互相访问的问题。检查步骤很简单：进入一个容器，ping 另一个容器的服务名，不通就看docker network inspect里两个容器是否在同一网络；不在同一网络就执行docker network connect <网络名> <容器名>把它们拉进同一网络。

5.4 GitLab 这类重服务的"假超时"

最后提一个容易让新人崩溃的场景：GitLab。docker run gitlab/gitlab-ce之后，容器一直处于Up，但打开页面始终"502"或"连接超时"。这不是 Docker 的问题，而是 GitLab 本身就是个大胖子，启动过程要初始化数据库、编译资产、启动几十个子服务，首启动耗时三到五分钟很正常。

对策非常简单：别慌，看日志进度。执行：

docker logs -f gitlab

看到日志持续滚动输出，就没有问题，等着就行。为了不让健康检查疯狂报警，建议在 compose 里给 GitLab 单独设置：

healthcheck: test: ["CMD", "curl", "-f", "http://localhost"] interval: 30s timeout: 10s retries: 30 start_period: 180s

start_period给到 180 秒，甚至更长，让 GitLab 从容完成首次启动。

6. 顺手补几个我从实战里养成的习惯

既然标题叫"吓得我一身汗"，最后我就分享几个被打过几次脸之后养成的习惯。它们不直接解决某一次超时，但能让你以后遇到超时少慌一点。

习惯一：日志是第一现场，动手重启之前先留证据。我现在遇到任何容器异常，第一件事永远是docker logs --tail 500 <容器名> > /tmp/container.log，把现场日志先留存。后面不管怎么重启、怎么删容器，都有第一手资料可以翻。这套习惯救过我很多次，尤其是在排查"偶发性"启动超时时，日志里往往藏着你平时不会注意到的真正线索。

习惯二：健康检查是编排的标配。我在自己的 compose 文件里，任何有依赖关系的服务都会配健康检查。没有健康检查，depends_on就是假的，服务之间的启动超时就成了玄学。宁可写的时候多敲几行配置，也不要事后对着unhealthy状态一头雾水。

习惯三：区分"等待超时"和"连接超时"。启动超时的 "timeout" 提示，要区分是 Docker CLI 等待容器启动超时，还是应用连接数据库/缓存时超时。前者是容器侧的问题，查docker logs和容器状态；后者是网络层或配置层的问题，查docker network和应用配置文件。一字之差，排查方向天差地别。

习惯四：给容器设置明确的资源上限。我会在 compose 里显式声明mem_limit、cpus等参数，而不是完全依赖 Docker 的默认资源分配。尤其是数据库容器，默认情况下 Docker 不会限制容器内存，但如果宿主机本身内存紧张，多个容器一起启动时会出现资源争抢，导致启动超时。显式声明资源，相当于给每个服务划了固定的地盘，互相不干扰。

习惯五：遇到"真的查不出原因"的超时，先看基础设施。磁盘空间、CPU 负载、内存占用、防火墙、DNS 解析。这五样东西检查一遍，比反复测 Docker 本身的配置更有效。有一次我遇到容器启动超时，查了半天 Docker 配置、镜像、网络，最后发现是宿主机磁盘满了——df -h一看 100%。这些基础设施问题往往才是"超时"背后的真正黑手。

那次 PostgreSQL 启动超时最后怎么解决的？其实很简单：我把日志保存下来，确认是数据库崩溃恢复导致启动过慢，然后在 compose 里给 healthcheck 加了start_period，并顺手调了容器的内存上限，重启后服务就正常了。整个过程不到二十分钟，但如果没有"先分层、再定位、后修改"的思路，这二十分钟可能就变成了"重启—等待—失败—再重启"的无尽循环。

希望你下次遇到 Docker 启动超时时，能想起这篇文章里的某一条思路——先问自己在哪一层，再看日志，再动手。那么这四个字就不会再让你吓得一身汗了。