本地构建镜像后需通过docker run --rm -it --network none等命令模拟最小运行环境，验证时区、证书、健康检查端点、配置错误反馈、信号处理等关键行为，避免静默失败。
本地构建镜像后，怎么验证它真能跑起来
别信 docker build 成功就完事了。很多 Go 镜像在本地 docker run 一启动就 panic，原因五花八门：缺失环境变量、时区没挂载、/tmp 权限不对、甚至 Alpine 镜像里少了个 ca-certificates 导致 HTTPS 请求直接失败。
自测第一步是模拟最小运行环境：
- 用
docker run --rm -it --network none启动，关掉网络强制暴露 DNS 或 HTTP 依赖问题 - 加
-v /etc/localtime:/etc/localtime:ro检查时区敏感逻辑（比如日志时间戳、定时任务） - 用
strace -e trace=openat,connect,write跟踪启动瞬间的系统调用，快速定位缺文件或连不上服务 - 对 Alpine 镜像，务必跑一次
curl -I https://httpbin.org，确认 TLS 根证书可用
HTTP 服务类应用，必须检查的三个端点
Go 应用常带健康检查，但很多人只写了 /healthz，却忘了它在容器里是否真被正确暴露和响应。K8s 的 livenessProbe 和 readinessProbe 就靠它活命。
自测时手动 curl 这三个路径（假设服务监听 :8080）：
立即学习“go语言免费学习笔记（深入）”；
-
curl -v http://localhost:8080/healthz—— 状态码必须是200，且响应体不能为空（有些实现返回""，K8s 会认为失败） -
curl -v http://localhost:8080/metrics—— 如果用了 Prometheus，这里应返回文本格式指标，且无 panic 或 500 -
curl -v http://localhost:8080/debug/pprof/goroutine?debug=1—— 确认 pprof 已启用，且不因未授权访问直接 panic（建议用net/http/pprof默认路由，别自己重写 handler）
配置加载失败时，错误信息能不能让人看懂
生产镜像最怕静默失败：配置项拼错、环境变量名大小写不一致、JSON 配置文件缩进错了——Go 程序可能直接 exit(1)，但日志里只打印 "failed to load config"，没有具体哪一行、哪个字段出问题。
自测要故意触发配置错误，看反馈是否可定位：
- 删掉必需的
DB_URL环境变量，启动容器，检查日志是否明确提示"missing required env DB_URL"，而不是泛泛的"config init failed" - 传入非法 YAML（比如把
timeout_ms: 5000写成timeout_ms: "5000"），确认解析失败时输出字段路径，如"config.server.timeout_ms: expected int, got string" - 如果用了
viper，确保调用了viper.SetEnvKeyReplacer(strings.NewReplacer(".", "_"))，否则log.level这种嵌套键无法从LOG_LEVEL映射
信号处理是否真正生效
容器停止时发 SIGTERM，你的 Go 程序得在几秒内优雅退出，释放数据库连接、关闭 listener、刷完 pending 日志。但很多代码只写了 signal.Notify(c, syscall.SIGTERM)，却没等子 goroutine 结束就直接 return。
验证方法很直接：
- 启动容器：
docker run -d --name testapp your-image - 立刻发停止信号：
docker stop -t 5 testapp（指定 5 秒超时） - 立即
docker logs testapp，确认最后一行是类似"shutting down gracefully, waiting for 3 workers..."，而不是突然中断或卡住 - 再跑一次，加
strace -p $(pgrep -f 'your-binary')，观察是否收到SIGTERM后真在清理，而不是被 kernel 强杀
真正容易被忽略的是：Alpine 镜像里 syscall.SIGQUIT 和 SIGUSR1 行为和 glibc 不同，调试信号（比如触发 pprof）在生产镜像里可能压根不生效，别依赖它做关键诊断。
