AI 生成 Compose 的冷启动竞态怎么查
文章通过全新数据卷上的三次冷启动，对比 AI 生成配置、常见补丁与修正方案，复现应用先于 Postgres 就绪而连接失败的问题。核心提醒是 depends_on 简写只控制启动顺序，不保证服务已可用。
AI 深度解读
AI 生成的 Docker Compose 能跑起来，为什么到了 CI 或同事电脑上，第一次连接数据库就报错？作者用三次全新数据卷冷启动，复现了一类很容易被演示掩盖的问题：容器启动了，不代表 Postgres 已经能接连接；加了健康检查，也可能检查错了对象。
最值得带走的结论是：启动顺序、健康检查和应用实际连接的路径，必须对得上。 这既是 Compose 配置问题，也是审查 AI 生成基础设施代码时的一条实用标准。
为什么本地能跑，换台机器就连接失败
Compose 用一份 YAML 定义和运行多个容器。常见配置在 app 下写一个简写依赖列表：depends_on: - db。它保证先启动数据库容器，再启动应用容器，却不保证数据库已经准备好。
Postgres 第一次启动时，需要执行 initdb，启动用于初始化的临时服务器，运行 /docker-entrypoint-initdb.d/ 中的脚本，最后才交给正式服务器作为 PID 1 运行。应用如果在这个过程中访问 db:5432，就可能收到拒绝连接。
旧数据卷会把问题藏起来。
数据目录已经初始化后，Postgres 会跳过上述流程，容器启动与接受连接之间的间隔明显缩短。作者认为，人和编程 Agent 经常在这样的环境里验证配置，因此「测试通过」可能是真的，只是没测首次启动。
作者在 2026-10-29 使用 Docker Engine 29.1.3、Docker Compose v5.1.4，配合 alpine:3.20 和 postgres:16-alpine，完成了三次删除数据卷后的冷启动。
测试应用每隔 0.5 秒探测一次 db:5432，最多尝试 30 次。最基础的依赖配置连续失败四次，第五次才成功，约有两秒连接窗口没有被启动顺序覆盖。数据库日志中的就绪时间为 08:10:28，应用此前已经开始请求。
CI runner、同事的新电脑、全新 VM，恰好都会遇到这种首次初始化。restart: unless-stopped 可能让应用反复重启，最终碰上数据库就绪，看起来恢复正常，但首次连接失败依然发生过。
为什么加了 healthcheck，应用还是启动早了
把依赖改成长格式，并设置 condition: service_healthy，Compose 就会等数据库健康检查通过后再启动应用。
问题转移到了另一个地方：健康检查究竟测了什么？
常见命令 pg_isready -U postgres 没有指定主机，探测的是 Unix socket，也就是容器内部的本地通信入口。官方 Postgres 镜像初始化时启动的临时服务器，恰好也会在这个入口应答，但此时应用使用的 TCP 服务尚未就绪。
健康检查通过，只能证明它所检查的路径通过。
作者记录到，健康状态在启动后 +0.78 秒进入 starting，+3.02 秒变为 healthy，而正式服务器到 +7.06 秒才接受 TCP 连接，相差约四秒。应用被放行后连续七次连接失败，第八次才成功。
下面这段探测日志，展示了临时服务器应答、随后关闭的过程：
08:13:52.4 exit 0 /var/run/postgresql:5432 - accepting connections
08:13:54.5 exit 0 /var/run/postgresql:5432 - accepting connections
08:13:56.5 exit 2 /var/run/postgresql:5432 - no response
要看的是前两行的 /var/run/postgresql:5432：它们证明 socket 能连接，不能证明应用访问的 db:5432 已经可用。
作者还在一次实验中加入休眠四秒的初始化脚本，拉长观察窗口。这没有凭空制造初始化阶段，但会影响具体等待时长。因此，四秒提前量是该实验条件下的结果，不能直接套到所有项目。
修复要让等待条件和连接路径同时正确
作者给出的完整配置如下。它用 TCP 健康检查避开临时初始化服务器，再让应用等待健康状态通过：
services:
app:
image: alpine:3.20
depends_on:
db:
condition: service_healthy
restart: true
command: >
sh -c 'i=0;
while [ $$i -lt 30 ]; do
i=$$((i+1));
if nc -z -w 1 db 5432 2>/dev/null; then
echo "ATTEMPT $$i: CONNECTED";
exit 0;
else
echo "ATTEMPT $$i: CONNECTION-REFUSED";
fi;
sleep 0.5;
done;
echo "GAVE UP"'
db:
image: postgres:16-alpine
environment:
POSTGRES_PASSWORD: example
volumes:
- pgdata:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -h 127.0.0.1 -U postgres"]
interval: 2s
timeout: 3s
retries: 10
start_period: 10s
volumes:
pgdata:
关键看 -h 127.0.0.1：它强制 pg_isready 走 TCP，避免初始化临时服务器通过 socket 提前报健康。配合 condition: service_healthy，修正后的冷启动在第一次连接就成功。
依赖项里的 restart: true 用于 Compose 显式重启依赖时联动重启应用。它和应用自身的 restart: unless-stopped 不是同一个设置，也不承担持续恢复数据库连接的职责。
时间预算同样需要调整。这里每 2 秒检查一次，单次超时 3 秒，允许 10 次失败，初始宽限期为 10 秒。作者的冷启动约需七秒，因此建议至少留出 10 秒，并给共享 CI runner 更多余量。这是作者环境下的配置建议，不是所有项目通用的下限。
start_period 主要让初始化阶段的失败暂不计入失败预算；真正防止提前放行的，仍然是探测目标正确。
我的判断
这篇最扎实的部分，是用日志拆开了三个状态：容器已运行、socket 能应答、TCP 能连接。三者容易混在一起，作者的实验解释了为什么「加上 healthcheck」仍然不够。
但标题把问题归因于 Agent 继承旧教程，证据没有同样充分。
原文引用 arXiv:2506.20495，说明模型即使能访问当前文档，仍可能生成过时 API；又引用 arXiv:2511.21022，其中 GPT-3.5 的 API 预测有 37.4% 已被弃用。这些材料支持「模型可能输出旧知识」，却不是对 Compose 生成结果的直接统计。原文没有交代具体使用哪个 Agent、什么模型、多少次生成，也没有给出失败比例。
因此，把它当作一种合理解释可以，把所有同类错误都归给训练语料就过头了。缺少运行验证、提示要求含糊，同样可能产生这类配置。
另外，实验应用用 nc 检查端口，证明的是 TCP 可达，并未验证业务查询。即使 TCP 探针通过，也不能单靠它断言账号、目标数据库、迁移结果都符合应用需求。
和固定等待几秒相比，基于正确探针等待更贴近实际状态；和应用重试相比，两者承担不同阶段的工作。启动等待减少第一次连接失败，应用重试处理运行期间的断连。数据库两小时后重启，启动门槛不会自动替应用修好连接。
能拿来做什么
- 给前端项目配套 Node API、Postgres 开发环境时，把「全新数据卷首次启动」列入验证。已有数据卷上的成功，只覆盖了一部分运行条件。
- 审查 Agent 生成的 YAML 时，依次检查依赖是否设置
condition: service_healthy、Postgres 探针是否指定 TCP，以及start_period等预算能否容纳初始化脚本。 - 在可丢弃的测试项目中运行
docker compose down -v && docker compose up --wait，验证冷启动。前半条会删除数据卷，应限定在测试数据上；--wait的结论仍取决于探针是否测对了对象。 - 给 Agent 的要求写清「应用等待 service_healthy，Postgres 使用 TCP 探针」，并提供当前规范内容。生成后继续审查；Node 应用也要保留带退避的连接重试，覆盖运行期间的数据库断连。