Iris项目自动化部署需显式控制二进制体积、交叉编译、环境变量和健康检查；go build失败主因是Runner无os.Getenv所需变量，且缺失-ldflags导致体积大、启动慢；gitlab-ci.yml必须分编译验证、静态检查、推送镜像三阶段；K8s部署需配置structured日志、/healthz探针及ConfigMap路径一致。
Go 项目用 Iris 框架时，自动化部署不是“配个 gitlab-ci.yml 就完事”，关键在于：Iris 本身不带构建时长依赖（比如前端打包），但它的二进制体积、交叉编译目标、环境变量注入和健康检查点，必须在流水线里显式控制，否则上线后常出现 panic: runtime error: invalid memory address 或服务监听失败。
为什么 go build 直接跑会失败？
Iris 项目通常依赖 os.Getenv 读取配置，而 GitLab Runner 默认环境里没有这些变量。更常见的是：本地 GOOS=linux GOARCH=amd64 go build 成功，但流水线里没指定 -ldflags 去 strip 符号或设置主版本号，导致二进制体积翻倍、启动变慢，甚至触发 Kubernetes 的 initContainer 超时。
- 必须显式设置
GOOS和GOARCH，不能依赖 Runner 宿主机系统 -
go build -ldflags="-s -w -X main.version=$(git describe --tags 2>/dev/null || echo dev)"是最小安全构建命令 - 若用
iris.New()后立刻调用.Listen()，需确保端口未被 Runner 共享环境占用（建议改用.Serve()+http.Server显式传入Addr）
gitlab-ci.yml 必须包含的三个阶段
GitLab 流水线不能只分 build 和 deploy 两步。Iris 项目至少要拆成：编译验证 → 静态检查 → 推送镜像。否则 iris.Run() 中的 panic 会在部署后才暴露。
用大白话操作当前项目的 Git/GitHub——配置 GitHub（装 gh CLI + 登录 + 建仓库）、备份、拉取下载、查询历史、回滚代码、管理分支。当用户用日常语言表达 git 意图时触发（例如"git备份一下""git下载项目""git拉下来""git看看我改了啥""git回退到上一个版本""git新建个分支搞新功能""git合并到主分支""git
-
test阶段：运行go test -v ./...，重点覆盖app := iris.New()初始化逻辑 -
build阶段：用golang:1.22-alpine镜像，执行带-ldflags的构建，并chmod +x输出文件 -
push阶段：用docker:dind服务构建多架构镜像（如需支持 ARM），标签用$(git rev-parse --short HEAD)而非latest
部署到 Kubernetes 时最易忽略的两点
Iris 默认不输出 structured 日志（如 JSON），K8s 的 livenessProbe 很容易误判。另外，iris.Configuration().DisableStartupLog = true 在 CI 中关掉日志，上线后却忘了开，会导致故障时无从排查。
-
livenessProbe必须指向/healthz这类 Iris 自定义路由，不能只靠端口存活检测 - 在
main.go里用if os.Getenv("ENV") == "prod" { app.Logger().SetLevel(iris.LogInfo) }动态控制日志等级 - ConfigMap 挂载的配置文件路径，要和
iris.YAML("./config.yaml")中的硬编码路径一致，否则app.Run()启动直接 panic
真正卡住人的从来不是怎么写 .gitlab-ci.yml，而是 Iris 的 app.Run() 在容器里启动失败时，错误堆栈被 exec.LookPath 或 net.Listen 层吞掉，只剩 exit code 1。建议在 before_script 里加一行 set -x，让每条命令回显，否则你永远不知道是 go build 没成功，还是 ./myapp 启动时读不到 config.yaml。
