Go Fiber项目上线核心在于环境隔离、构建可控、进程守护、可观测性四点；需用多阶段Docker构建、显式绑定0.0.0.0、适配systemd/K8s生命周期、输出结构化日志至stdout/stderr。
Go Fiber 项目上线不是“写完 app.Listen() 就扔进服务器”，核心在于：环境隔离、构建可控、进程守护、可观测性这四点没做实，哪怕性能再高，也会在线上崩得悄无声息。
构建 Docker 镜像时必须用多阶段构建
本地 go run 能跑 ≠ 容器里能跑。Fiber 应用依赖 Go 编译产物，但运行时不需要 Go 工具链和源码——直接拷贝二进制进去最干净。
- 第一阶段用
golang:1.24-alpine（或你项目实际版本）编译，CGO_ENABLED=0 GOOS=linux go build -a -o /app/main . - 第二阶段用
alpine:latest，只 COPY 第一阶段生成的/app/main，再暴露端口、设置非 root 用户 - 别漏掉
WORKDIR /app和USER 65532:65532，否则容器启动后可能因权限问题无法绑定端口或写日志 - 镜像体积能从 900MB+ 压到 15MB 左右，启动更快，攻击面更小
监听地址必须显式绑定 0.0.0.0 而非 localhost
这是线上部署最常踩的坑：app.Listen(":3000") 在容器里默认绑定 localhost:3000，导致 Kubernetes Service 或宿主机 curl 全部超时，日志里却看不到任何错误。
- 正确写法是
app.Listen("0.0.0.0:3000")或app.Listen(":3000")（v2/v3 默认已改为此行为，但旧版 v2.38 之前仍需显式指定） - 如果用了
fiber.Config{ServerHeader: "Fiber"}等配置，确保它在fiber.New()时传入，而不是漏掉 - Kubernetes 中若用
livenessProbe，探针路径必须是应用实际响应的路由（比如/healthz），不能只靠端口通就认为健康
进程管理不能依赖前台命令，要适配 systemd 或 Kubernetes lifecycle
线上没有终端，go run main.go 这种方式会随 shell 退出而终止；Docker 容器里用 ENTRYPOINT ["./main"] 是对的，但还要处理信号。
- Fiber 默认会捕获
SIGINT和SIGTERM并优雅关闭，但前提是你的二进制没被sh -c包裹——避免写成ENTRYPOINT ["sh", "-c", "./main"] - 在 Kubernetes 中，加
terminationGracePeriodSeconds: 30给 Fiber 留出连接 draining 时间 - 如果用 systemd 部署，Unit 文件里必须设
Type=simple（不是forking），并配Restart=always和RestartSec=5
日志必须输出到 stdout/stderr，且禁用颜色和时间戳格式干扰
Kubernetes 和大多数日志采集器（如 Fluentd、Loki）只认标准流。带 ANSI 颜色或自定义时间格式的日志，会被当成乱码或解析失败。
- 关掉 Fiber 自带的颜色输出：
fiber.New(fiber.Config{DisableStartupMessage: true}) - 所有中间件里的
fmt.Printf或log.Println改为log.New(os.Stdout, "", 0).Println(...)，去掉前缀 - 数据库 SQL 日志（GORM）、Redis 调用日志等，统一走结构化 JSON 输出（用
zerolog或zap），字段包含level、time、trace_id、method、path - 别把日志写进容器内文件（如
logs/app.log），Kubernetes 无法自动收集，还会撑爆容器磁盘
真正卡住上线的，往往不是 Fiber 性能，而是容器网络模型理解偏差、信号传递被中间层截断、日志格式和采集工具不兼容这些细节——它们不会报错，只会让服务看起来“活得好好的”，却收不到请求、查不到日志、杀不干净进程。
