应配置 healthcheck 并用 condition: service_healthy 代替 depends_on；Go 连 DB 的 host 写服务名（如 postgres）而非 localhost；用多阶段构建+GOPROXY 加速镜像构建；环境变量需显式加载，日志输出到 stdout。
docker-compose.yml 里 DB 和 Go 服务怎么写才不连不上
Go 应用启动时频繁报 connection refused 或超时，大概率不是代码问题，而是容器启动顺序没控住。Docker Compose 默认并行启所有服务，postgres 容器网络通了、端口开了，但 PostgreSQL 进程还没完成初始化（比如 WAL replay、system catalog 加载），这时 Go 的 sql.Open 就会失败。
- 别依赖
depends_on的“启动完成”语义——它只等容器状态为running，不等服务就绪 - 在 Go 侧加重试逻辑比在 compose 里硬等更可靠：用
sql.Open+db.PingContext配合指数退避（例如 100ms → 200ms → 400ms） - 如果必须用
depends_on，搭配condition: service_healthy，并在 DB 服务里定义healthcheck（如pg_isready -U postgres -d mydb） - PostgreSQL 镜像默认监听
localhost，容器内必须改listen_addresses = '*'，否则 Go 服务 ping 不通
Go 应用镜像体积大、构建慢？关键在多阶段构建和 GOPROXY
直接 go build 出来的二进制塞进 golang:alpine 镜像，容易漏 libc 依赖；全量复制 /go 目录又让镜像膨胀到 800MB+。根本原因是没分清构建环境和运行环境。
- 第一阶段用
golang:1.22-alpine编译，第二阶段用alpine:latest或scratch运行——确保最终镜像只有可执行文件和必要 CA 证书 - 务必在
Dockerfile开头加ENV GOPROXY=https://proxy.golang.org,direct，国内环境换成https://goproxy.cn，否则go mod download卡死或拉错版本 - 避免
COPY . .，用COPY go.mod go.sum ./+go mod download再COPY *.go ./，利用 Docker 层缓存加速重复构建 - 编译时加
-ldflags="-s -w"去掉调试信息，二进制体积能减 30%～50%
数据库连接字符串里的 host 别写 localhost
Go 容器里写 host=localhost，连的是自己容器的 loopback，不是 PostgreSQL 容器。这是最常被忽略的网络配置错误。
- Compose 默认为每个服务创建 DNS 记录，DB 服务名是啥，Go 里
host就写啥，比如host=postgres（对应services.postgres） - 端口写容器内端口（
5432），不是宿主机映射端口（5433） - 连接字符串建议用
url.Parse解析，而不是字符串拼接——避免user或password含特殊字符时出错 - 密码里有
@或/？必须用url.PathEscape编码，否则sql.Open解析失败
本地开发 vs 生产环境的配置差异藏在哪
本地跑得好，上 Docker 就挂，往往因为环境变量没透传或路径不对。Go 应用不会自动读 .env 文件，所有配置得显式加载。
立即学习“go语言免费学习笔记（深入）”；
- Compose 中用
environment或env_file注入变量，但 Go 里必须调os.Getenv或用godotenv.Load主动读取 - 数据库迁移脚本路径在容器里是相对
/app，不是项目根目录；别写./migrations，改用filepath.Join(os.Getenv("APP_ROOT"), "migrations") - 日志输出别写死
/var/log/app.log——容器里该写 stdout，由 Docker 捕获，方便docker logs查看 - HTTPS 证书路径在容器里通常是
/etc/ssl/certs，不是 macOS 的/etc/ssl/cert.pem，CA 信任链要重新验证
网络就绪、镜像瘦身、DNS 名称、环境变量透传——这四点卡住，服务就起不来。其他都是锦上添花。
