Go微服务容器化部署需三要素协同：alpine镜像+CGO_ENABLED=0编译+显式healthcheck；生产用scratch或alpine:latest基础镜像，禁用debian/ubuntu；Dockerfile中须指定GOOS/GOARCH并静态链接；健康检查应设超时重试且接口仅做内存态校验；日志必须输出到os.Stdout/Stderr并确保行尾换行。
Go 微服务容器化部署本身不难，难点在于镜像体积、启动速度、日志输出和健康检查的协同——alpine 镜像 + CGO_ENABLED=0 编译 + healthcheck 显式声明，这三者缺一不可。
用什么基础镜像？别直接用 golang:latest
开发阶段可以用 golang:1.22-alpine，但生产镜像必须用纯静态二进制 + scratch 或 alpine:latest。否则镜像里塞进整个 Go 工具链，动辄 900MB+，且存在未打补丁的 libc 风险。
实操建议：
- 构建阶段用
golang:1.22-alpine编译，设置CGO_ENABLED=0 - 运行阶段 COPY 二进制到
scratch（最小）或alpine:latest（需调试时用） - 避免使用
debian或ubuntu基础镜像，哪怕只加一个curl，体积就翻倍
Dockerfile 中如何正确编译 Go 二进制？
Go 的交叉编译能力很强，但默认开启 CGO 会导致依赖系统库，无法在 scratch 运行。必须显式关闭并指定目标平台。
立即学习“go语言免费学习笔记（深入）”；
常见错误：漏设 GOOS 和 GOARCH，导致本地编译的二进制在 ARM 容器里 panic。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
FROM golang:1.22-alpine AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -a -ldflags '-extldflags "-static"' -o /app/myapi . FROM scratch COPY --from=builder /app/myapi /myapi EXPOSE 8080 ENTRYPOINT ["/myapi"]
健康检查（HEALTHCHECK）怎么写才不误判？
很多团队用 curl -f http://localhost:8080/health，但没加超时和重试，导致容器刚启动就被 kill。更糟的是，把 /health 实现成查 DB 连接——DB 慢半秒，整个服务就反复重启。
实操建议：
HEALTHCHECK --interval=10s --timeout=3s --start-period=30s --retries=3- 健康接口只做内存态检查（如
http.StatusOK+ 时间戳响应），不碰外部依赖 - 如果必须检查 DB，单独暴露
/readyz，和/healthz分开 - Go 服务内建议用
net/http/pprof或自定义 handler，不要依赖第三方中间件做健康路由
日志输出为什么进不了 Docker logs？
Go 默认 stdout/stderr 是行缓冲，但容器里没 TTY，容易卡住。更常见的是用了 log.Printf 却没 flush，或者用 fmt.Println 混合输出，导致日志延迟几秒甚至丢失。
关键点：
- 所有日志必须输出到
os.Stdout或os.Stderr，不能写文件 - 禁用任何带缓冲的日志封装（比如某些 zap logger 配置了
WriteSyncer但没设Buffered） - 简单服务直接用
log.SetOutput(os.Stdout)，并确保每条日志以\n结尾 - 若用
zerolog，启用zerolog.ConsoleWriter{Out: os.Stdout}；若用zap，选zapcore.Lock(os.Stdout)
真正卡住上线的，往往不是编译失败，而是健康检查超时后反复重启、日志看不到、OOM 被 kill 却没留 trace——这些都得在 Dockerfile 和 Go 主程序里显式控制，不能靠“应该没问题”蒙混过关。
