Golang Fiber部署Google Cloud Run后容器自动退出问题

核心原因分析 #

Container called exit(0)说明容器进程是正常终止而非崩溃，结合你的场景，常见原因如下：

1. 主goroutine未被阻塞 #

Fiber的Listen方法默认是同步阻塞的，但如果你的代码中误将其放在异步goroutine中执行（比如go app.Listen(":8080")），主goroutine会在完成初始化、打印监听日志后直接执行完毕，导致整个进程正常退出。

2. 端口配置未适配Cloud Run规则 #

Cloud Run要求容器监听$PORT环境变量指定的端口，而非固定的8080。虽然硬编码8080会让日志显示监听成功，但如果后续服务因无法接收Cloud Run的请求触发了某种内部正常退出逻辑（比如健康检查超时后的主动退出），也会出现exit(0)。

3. Dockerfile启动命令存在问题 #

如果Dockerfile使用shell形式的启动命令（如CMD ./main），而非exec形式（CMD ["./main"]），shell进程会成为容器的PID 1。若shell在启动二进制后意外退出，会直接导致容器终止。另外，若未编译成二进制而是直接用go run main.go启动，也可能因go进程执行完后触发退出。

4. 代码存在隐藏的正常退出逻辑 #

检查main函数是否在启动监听后，有其他goroutine调用了os.Exit(0)，或是某些初始化逻辑完成后触发了主动退出流程。

解决步骤 #

• 确认app.Listen()是同步调用，没有用go关键字包裹，确保主goroutine被持续阻塞。
• 修改代码读取PORT环境变量，避免硬编码端口：

import "os"

func main() {
    // ...其他初始化逻辑
    port := os.Getenv("PORT")
    if port == "" {
        port = "8080"
    }
    log.Printf("Api started listening in port %s", port)
    if err := app.Listen(":" + port); err != nil {
        log.Fatal(err)
    }
}

• 调整Dockerfile使用exec形式启动编译后的二进制，确保其成为容器PID 1进程：

FROM golang:1.21-alpine AS builder
WORKDIR /app
COPY . .
RUN go build -o main .

FROM alpine:latest
WORKDIR /app
COPY --from=builder /app/main .
CMD ["./main"]

• 排查代码中所有可能触发os.Exit(0)的逻辑，确认服务启动后无主动退出的代码分支。

内容的提问来源于stack exchange，提问作者mike