Golang使用Docker Compose教程

Go应用在docker-compose.yml中应采用多阶段构建，用alpine镜像运行编译后二进制，command指向./app，监听0.0.0.0:8080，通过environment/env_file注入变量，配合健康检查与重试机制处理依赖就绪问题。

docker-compose.yml 里怎么写 Go 应用的服务定义

Go 应用本身不依赖运行时容器化环境，但用 docker-compose 启动它时，核心是「把编译好的二进制放进轻量镜像里跑」，而不是挂源码 + go run。常见错误是直接 COPY main.go 进去再装 Go 环境，这会让镜像臃肿、启动慢、存在安全风险。

• 推荐用 FROM golang:1.22-alpine 做构建阶段，FROM alpine:latest 做运行阶段（多阶段构建）
• 服务定义中 command 不要写 go run main.go，应指向已编译的可执行文件，比如 ./app
• 如果 Go 程序监听 localhost:8080，记得改成 0.0.0.0:8080，否则容器内网络无法被其他服务访问
• volumes 在生产环境慎用——本地代码热重载适合开发，但会覆盖镜像里的二进制，导致 compose up 行为不可预期

Go 程序如何读取 docker-compose 的环境变量

Go 没有内置的“自动加载 compose env”机制，一切靠 os.Getenv 或第三方库（如 godotenv）手动处理。容易忽略的是：环境变量注入顺序和覆盖逻辑。

• environment: 下写的键值对会直接注入容器，优先级高于 .env 文件
• env_file: 支持加载 .env，但只在 compose 解析时生效，不会自动同步到 Go 进程的 os.Environ() —— 它只是让 compose 替你展开变量
• 若用 go build -ldflags="-X main.Version=${VERSION}" 注入编译期变量，那和 docker-compose 无关，得靠 build.args 配合 Dockerfile 的 ARG
• 建议统一用 os.LookupEnv 而非 os.Getenv，避免空字符串和未设置混淆

docker-compose up 启动后 Go 服务没响应？检查这几个点

最常见不是代码问题，而是网络或生命周期配置失配。Docker Compose 默认为每个服务建独立网络，但 Go 服务若连 DB 或 Redis，必须显式声明依赖和网络就绪时机。

• 用 depends_on: 只控制启动顺序，**不等待目标服务就绪**；DB 可能还在初始化，Go 就开始 dial，结果 panic
• 解决方法：在 Go 启动逻辑里加重试（例如用 backoff.Retry 连 DB），或者用 healthcheck 配合 condition: service_healthy
• ports: 暴露的是宿主机端口映射，若只写 - "8080"（不带冒号前缀），则随机分配宿主机端口，调试时很难 curl；建议写成 - "8080:8080"
• 日志卡住？确认 Go 没缓冲 log.Println 输出——加 log.SetOutput(os.Stdout) 和 log.SetFlags(0) 避免换行丢失，方便 docker-compose logs -f 实时看到

要不要在 docker-compose.yml 里配 restart 策略

Go 程序崩溃后是否该自动重启，取决于它是不是无状态长任务。盲目设 restart: unless-stopped 可能把 panic 日志盖掉，掩盖真正问题。

• 开发阶段建议 restart: "no"，配合 docker-compose logs -f 看第一手 panic trace
• 生产环境若设 restart: on-failure，务必限制 max_attempts（默认无限），否则反复崩溃会刷爆磁盘日志
• 注意：Go 的 os.Exit(0) 不触发 restart，但 panic 导致的非零退出会——如果你用 log.Fatal，它等价于 os.Exit(1)，会被重启策略捕获
• 更稳妥的做法是用 supervisord 或 tini 作为容器 PID 1，防止 Go 进程信号转发异常（尤其 SIGTERM 处理失败导致无法优雅退出）

Go 服务容器化真正难的不是写几行 YAML，而是搞清「谁在什么时候、以什么身份、向哪里暴露了什么」——网络、信号、标准流、环境变量，四者稍有错位，docker-compose up 就变成黑盒调试现场。