go docker镜像体积大、启动慢、时区错位、sidecar连接失败等问题，可通过多阶段构建、合理probe配置、tz环境变量设置、http客户端超时与dns调优解决。
Go 二进制体积太大，Docker 镜像动辄 800MB？用多阶段构建砍掉 95%
Go 编译出的二进制本身是静态链接的，但如果你直接 FROM golang:1.22 并把源码 COPY 进去构建，最终镜像会带上整个 Go 工具链、$GOROOT、/usr/local/go 下所有东西——这不是运行时需要的，纯属浪费。
多阶段构建的核心就一条：构建环境和运行环境彻底分离。第一阶段用完整 golang 镜像编译，第二阶段只拿编译结果，扔进极简的 alpine:latest 或 scratch 里跑。
-
scratch镜像没有 shell、没有ls、没有/bin/sh，所以你的 Go 程序必须是静态编译（默认就是），且不能依赖 libc 外的动态库（比如 cgo 开启后连libpthread都可能出问题） - 如果用了
cgo（比如连接 PostgreSQL 的pgx默认启用），得显式关掉：CGO_ENABLED=0 go build -o app .，否则第二阶段跑不起来，报错类似standard_init_linux.go:228: exec user process caused: no such file or directory - 别在第二阶段 COPY 整个
/go目录或go.mod——没用，只 COPY 编译好的二进制和必要配置文件（如config.yaml）
K8s Pod 启动就 CrashLoopBackOff，检查 livenessProbe 和 readinessProbe 的超时设置
Go 微服务冷启动慢是常见现象：加载配置、连 DB、初始化 gRPC client、注册到 Consul……这些都发生在 main() 里。K8s 默认的 initialDelaySeconds: 0 + timeoutSeconds: 1，等于还没等你 http.ListenAndServe 就判定失败，反复重启。
真实场景下，一个带 DB 连接池和中间件初始化的 Go 服务，首启耗时 3–8 秒很常见。Probe 不是越严越好，而是要匹配实际启动节奏。
立即学习“go语言免费学习笔记（深入）”；
-
initialDelaySeconds至少设为 10，给足初始化时间；timeoutSeconds别低于 3，HTTP 探针走网络，1 秒太激进 - Probe 路径别写成
/healthz却在代码里没实现——Go 标准库net/http不自动提供该 endpoint，得自己注册http.HandleFunc("/healthz", ...) - 如果用了
fasthttp或gin，确保 probe handler 不依赖未就绪的组件（比如 probe 里查 DB，但 DB client 还没初始化完）
容器里 time.Now() 返回 UTC，但日志/监控需要本地时区？别改宿主机，改 Go 程序行为
Docker 容器默认时区是 UTC，time.Now() 返回的就是 UTC 时间。你在日志里看到 2024-05-22T03:12:44Z，看着没错，但和运维看的 Grafana 面板（设的是 Asia/Shanghai）对不上，排查时间线容易错乱。
别碰 docker run -v /etc/localtime:/etc/localtime 或在 Dockerfile 里 RUN apk add --no-cache tzdata && cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime——这会让容器内 date 命令显示对了，但 Go 的 time.Now() 仍走 UTC，因为 Go 默认读 TZ 环境变量，不是系统时区文件。
- 启动容器时加
-e TZ=Asia/Shanghai，Go 运行时会识别并切换默认time.Location - 或者在代码里显式指定：
loc, _ := time.LoadLocation("Asia/Shanghai"); t := time.Now().In(loc)，但注意所有日志、metric timestamp 都得统一走这个loc - 如果用了第三方日志库（如
zap），确认其EncoderConfig.EncodeTime是否硬编码了time.RFC3339——它默认用本地时区，而“本地”在容器里就是 UTC，得改成func(t time.Time, enc zapcore.PrimitiveArrayEncoder) { enc.AppendString(t.In(loc).Format("2006-01-02T15:04:05.000-0700")) }
Service Mesh（如 Istio）注入 sidecar 后，Go HTTP client 出现 connection refused？检查 dialer 超时和 DNS 缓存
Istio 注入 Envoy sidecar 后，所有出向流量被重定向到 localhost:15001。Go 的 http.Client 默认复用连接，但如果第一次请求因 sidecar 启动慢失败，连接池里缓存的坏连接不会自动剔除，后续请求继续复用，就一直 connection refused。
这不是 Go bug，是连接复用机制和 sidecar 启动时序的冲突。Envoy 启动比主容器慢几百毫秒很常见，尤其在资源紧张的节点上。
- 给
http.Client显式设置Timeout和Transport的IdleConnTimeout、MaxIdleConnsPerHost，避免死连接卡住 - 禁用 Go 的 DNS 缓存（默认 0 秒，但某些版本或 CGO 环境下可能异常）：
os.Setenv("GODEBUG", "netdns=go")，防止 DNS 解析结果（如localhost）被错误缓存 - 关键 HTTP client（比如调其他微服务）别复用全局
http.DefaultClient，单独 new 一个，配好超时和重试逻辑
