github actions或gitlab ci配置fiber项目ci/cd的核心是确保构建产物干净、镜像可复现、部署幂等；必须禁用cgo、采用多阶段docker构建、注册/healthz健康端点，并严格校验git tag格式以保障k8s滚动更新与回滚可靠。
GitHub Actions 或 GitLab CI 配置 Fiber 项目 CI/CD 流水线，核心不是“能不能跑”，而是“构建产物是否干净、镜像是否可复现、部署是否幂等”——这三点没对齐，后续 K8s 滚动更新或回滚就会出问题。
Go 编译阶段必须用 CGO_ENABLED=0 和静态链接
Fiber 基于 fasthttp，默认启用 CGO 会导致二进制依赖系统库（如 libc），在 Alpine 镜像中直接运行会报 no such file or directory 错误。即使你用 golang:alpine 基础镜像，也得显式禁用 CGO。
- 正确编译命令：
CGO_ENABLED=0 go build -a -ldflags '-extldflags "-static"' -o fiber-app . - 错误写法：
go build -o fiber-app .（默认启用 CGO，产物不可移植） - CI 中建议统一加到
build步骤的 script 里，避免本地开发环境和 CI 环境行为不一致
Dockerfile 要分阶段构建，且最终镜像不能含 Go 工具链
生产镜像体积大、攻击面宽，本质是安全与启动性能双输。Fiber 是纯二进制服务，不需要 go、git、bash 等任何开发工具。
- 推荐多阶段写法：
FROM golang:1.23-alpine AS builder→ 编译；FROM alpine:3.20→COPY --from=builder /workspace/fiber-app /usr/local/bin/fiber-app - 别用
scratch：虽然最小，但缺失/dev/proc导致fiber的某些日志或健康检查行为异常（比如runtime.NumGoroutine()在 scratch 下可能 panic） - 最终镜像应只含一个可执行文件 + 必要配置（如
config.yaml），用ls -la检查根目录下不该有go、pkg、src
Kubernetes 部署时，livenessProbe 和 readinessProbe 必须走 Fiber 内置健康端点
Fiber 默认不暴露健康检查接口，需手动注册。若直接照搬其他框架（如 Gin）的 /healthz 路径，K8s 会持续报 503 Service Unavailable 并反复重启 Pod。
- 在 main.go 中添加：
app.Get("/healthz", func(c *fiber.Ctx) error { return c.SendStatus(fiber.StatusOK) }) - Deployment 中 probe 配置示例：
livenessProbe: { httpGet: { path: "/healthz", port: 3000 }, initialDelaySeconds: 10, periodSeconds: 15 } - 别用
exec类型 probe：Fiber 是单进程，ps aux | grep fiber在容器内不可靠，且增加 shell 启动开销
GitHub Actions 中触发部署前，必须校验 git tag 格式并提取版本号
Fiber 应用本身无版本元数据，但镜像标签（your-registry/fiber:v1.2.3）和 K8s Deployment 的 image 字段必须严格对应。硬编码版本号或用 GITHUB_RUN_NUMBER 会导致镜像不可追溯。
- 推荐做法：只允许
v\d+\.\d+\.\d+格式的 tag 触发部署，例如v2.1.0，拒绝release-2.1或2.1.0（缺v前缀） - 提取版本命令：
echo "${GITHUB_REF#refs/tags/}"，再用sed 's/^v//'去掉前缀供后续使用 - 关键陷阱：GitLab CI 的
CI_COMMIT_TAG和 GitHub Actions 的GITHUB_REF行为不同，不要直接抄配置
真正卡住人的从来不是“怎么写 pipeline”，而是构建产物在本地能跑、CI 里能构建、K8s 里却 CrashLoopBackOff —— 大概率是 CGO、probe 路径、或镜像 tag 解析这三个环节之一没对齐。
