AI生成Compose配置为何冷启动连不上数据库
文章通过全新数据卷下的冷启动实验，检查 AI 生成的 Compose 配置、常见半修复方案及修正版本。核心问题是 depends_on 列表只保证容器启动顺序，不保证 Postgres 已准备好接收连接。
AI 深度解读
AI 生成的 Docker Compose 文件，可能在本机测试通过，换到 CI 或同事电脑上却连不上数据库。作者追查的是一个老问题：容器已经启动，Postgres 却还没准备好；更隐蔽的是，补上健康检查之后，仍然可能提前放行。
作者在全新数据卷上做了三次冷启动实验，发现常见的 pg_isready -U postgres 会把初始化阶段的临时服务当成数据库就绪。对日常用 AI 写配置的程序员来说，这篇最有用的提醒是：测试环境和探针问的问题，都得审。
为什么本机通过，第一次部署却失败
Compose 用一份 YAML 定义和运行多个容器，但短格式的 depends_on 只保证启动顺序。先启动 db，再启动 app，并不保证后者启动时数据库已经能接连接。
Postgres 的首次启动尤其容易暴露这个时间差。数据目录为空时，入口脚本要执行 initdb、启动临时数据库、运行 /docker-entrypoint-initdb.d/ 下的初始化脚本，最后才切换到正式服务。应用如果紧跟着启动，就可能撞上这个窗口。
已经初始化过的数据卷会跳过前面的工作，连接窗口随之缩短。因此，作者认为很多「验证通过」是真的通过了，只是验证用的是旧数据卷。
热启动通过，不能证明首次启动可靠。
作者于 2026-10-29 使用 Docker Engine 29.1.3、Docker Compose v5.1.4 做了三次实验，每次都删除数据卷重新开始。数据库镜像是 postgres:16-alpine，模拟应用是 alpine:3.20：每隔 0.5 秒探测一次 db:5432，最多尝试 30 次。
最基础的配置中，前四次连接被拒绝，第五次才成功。数据库日志里的就绪时间是 08:10:28，应用在此之前已经开始请求。作者测到的失败窗口约为两秒；磁盘更慢、初始化脚本更多时，窗口还可能变长。
这也是 restart: unless-stopped 容易掩盖的问题：应用反复退出、重启，最终等到了数据库，看起来整个栈顺利起来了。但启动竞态还在，只是被自动重启盖住。
健康检查为什么也会提前亮绿灯
把依赖改成长格式，并添加 condition: service_healthy，确实可以让 Compose 等待数据库健康之后再启动应用。问题转移到了下一层：健康检查到底测了什么？
常见探针是 pg_isready -U postgres。原文指出，不带主机参数时，它探测的是 Unix socket；而官方 Postgres 镜像在首次初始化时，会启动一个只监听 Unix socket 的临时服务。
于是，探针能连上，应用却连不上。应用访问的是 TCP 地址 db:5432，两者走的路径不同。
作者给出的探针日志，直接展示了临时服务先响应、随后退出的过程：
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 上有服务响应，不能证明应用需要的 TCP 服务已经可用。
在这次实验里，健康状态于启动后 +0.78 秒进入 starting，+3.02 秒变为 healthy，正式服务到 +7.06 秒才接受 TCP 连接。提前放行约四秒，应用连续七次连接失败，第八次才成功。
作者说明，为了让初始化窗口更容易观察，其中一次实验在初始化目录挂载了一个休眠四秒的脚本。这个设置会拉长已有窗口，因此不能把「四秒」当成所有项目都会出现的固定值。
启动门禁是否可靠，取决于探针有没有检查应用真正需要的连接路径。
修复要改哪里，验证又该怎么做
作者给出的完整配置如下。它用健康条件控制应用启动，并强制探针走 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。它让检查走 TCP，初始化阶段只监听 socket 的临时服务就无法提前交卷。修正后的冷启动中，作者观察到应用第一次连接便成功。
其余参数各有职责。condition: service_healthy 建立等待条件；依赖项下的 restart: true 用于 Compose 显式操作依赖时联动重启应用，作者举的命令是 docker compose restart db。它和应用自身的 restart: unless-stopped 不是同一层配置，也不能替代运行期间的连接恢复。
时间预算也要按项目设置：这里每 2s 检查一次、超时 3s、允许 10 次失败，start_period: 10s 给首次初始化留出宽限。宽限期主要影响失败如何计数，并不是强制等待十秒。作者数据库冷启动约需七秒，因而选择十秒；共享 CI runner 上是否够用，还得实测。
验证时，作者建议在临时项目执行 docker compose down -v && docker compose up --wait，并称这是一个约 30 秒的测试。down -v 会删除数据卷，应放在可丢弃的测试环境使用。--wait 能把运行或健康状态变成等待条件，但错误的探针照样可能让它提前通过。
我的判断
这篇最扎实的部分，是把「服务已启动」和「应用能使用服务」拆开验证，并拿出了时间戳、探针输出和冷启动条件。相比增加固定休眠，等待准确的健康信号更贴近实际状态；相比只靠容器自动重启，它也更容易暴露配置问题。
但作者把问题归因于模型继承旧教程，证据还不够直接。原文引用 arXiv:2506.20495，说明模型即使能访问新文档，也可能继续生成过时 API；另引 arXiv:2511.21022，称 GPT-3.5 的 API 预测中有 37.4% 已弃用。这些结果能支持「生成结果可能过时」，却不能直接证明 Compose 配置错误来自哪批教程。
作者没有给出多个 coding agent 的模型版本、提示词、生成次数和错误率对照。「模型容易写出这种配置」应当视为观察和推断，不能当成已测出的普遍比例。
实验本身也有边界：模拟应用用 nc -z -w 1 db 5432 测端口连通，尚未验证真实业务需要的认证、数据库对象或迁移状态。TCP 探针修复了这里的误报，不代表所有业务就绪条件都自动满足。
此外，原文没有用独立实验展示 restart: true 在各种重启场景下的结果。可以保留这项配置，但不能据此推导出「数据库任何时候重启，应用都会自动恢复」。启动门禁和运行期重试需要同时存在。
能拿来做什么
- 审查 AI 生成的 Postgres Compose 配置时，依次检查长格式
depends_on、condition: service_healthy、探针的-h 127.0.0.1和初始化时间预算，别只看有没有healthcheck。 - 给 coding agent 提需求时，明确要求「应用等待数据库健康，探针使用 TCP」，并提供当前规范内容。文档能减少猜测，生成后的审查仍然要做。
- 给 Node 或全栈项目补一次全新数据卷的启动验证，在可丢弃环境运行
docker compose down -v && docker compose up --wait，随后确认应用真正完成数据库连接。 - 保留应用层带退避的连接重试，并区分首次启动和运行中断连。Compose 的启动条件处理前者，连接池与应用恢复逻辑处理后者。