GORM本身不处理网络通信，延迟根源在底层数据库连接；容器中常见坑包括DNS解析慢、bridge网络NAT开销大、连接池与容器生命周期不匹配。
GORM 本身不处理网络通信，延迟一定出在底层数据库连接上——容器环境里最常踩的坑是 DNS 解析慢、bridge 网络 NAT 开销大、或连接池配置与容器生命周期不匹配。
查清 GORM 实际连的是哪个地址
很多团队误以为 GORM 连的是服务名（如 postgres），但没确认容器是否真能解析它。用 docker exec -it <app-container> nslookup postgres 直接验证；若失败，说明 Docker 内置 DNS 没生效，不是 GORM 的锅。
- 优先用自定义 bridge 网络：
docker network create app-net，启动时指定--network app-net，确保postgres容器和应用容器在同一网络 - 避免硬编码 IP：容器重启后 IP 可能变，
GORM连接字符串里写host=postgres，别写host=172.18.0.3 - 检查
/etc/resolv.conf是否被覆盖：有些基础镜像会删掉 Docker 注入的 nameserver，导致 fallback 到宿主机 DNS，而宿主机 DNS 可能不可达或响应慢
确认数据库连接是否复用成功
GORM 默认启用连接池，但容器里若没显式调优，容易出现“每次查询都新建连接”的假象。重点看两个指标：db.Stats().OpenConnections 和 db.Stats().WaitCount —— 后者非零就说明连接池已满，请求在排队。
- 在 Go 应用启动后加一段健康检查逻辑，每 10 秒打印一次：
fmt.Printf("open: %d, wait: %d\n", db.Stats().OpenConnections, db.Stats().WaitCount) - 容器内
netstat -an | grep :5432 | wc -l查实际 TCP 连接数，若远高于MaxOpenConns，说明有连接泄漏（比如 defer db.Close() 漏写） - 别信默认值：
MaxOpenConns默认是 0（无限制），在容器资源受限场景下必须设为合理值（如 20–50），否则可能触发宿主机 OOM killer
绕过 bridge 网络 NAT 的实操路径
当 postgres 和应用容器部署在同一宿主机，且对延迟敏感（如高频事务），bridge 模式下 5–15ms 的额外延迟不可忽视。这时应直接切到 host 网络，但要注意适配方式。
- 启动命令改用：
docker run --network=host -e DB_HOST=localhost ...—— 注意此时DB_HOST必须是localhost，不是容器名 -
GORM初始化时不能依赖host=postgres，要根据环境变量动态切换：if os.Getenv("NETWORK_MODE") == "host" { dsn = strings.Replace(dsn, "host=postgres", "host=localhost", 1) } - PostgreSQL 配置需放开本地连接：
pg_hba.conf加一行host all all 127.0.0.1/32 md5，并确认listen_addresses = 'localhost'
真正卡住的往往不是 GORM.Open()，而是第一次 db.First() 触发的 DNS 解析 + TCP 握手 + TLS 协商。把这三步拆开测（用 time nslookup、time timeout 3 bash -c 'echo > /dev/tcp/postgres/5432'、openssl s_client -connect postgres:5432 -quiet），比盯着 GORM 日志有效得多。
