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 日志盖掉，掩盖真正问题。
立即学习“go语言免费学习笔记（深入）”；
- 开发阶段建议
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 就变成黑盒调试现场。
