Golang应用迁移到Kubernetes的核心卡点是healthz探针配置、静态资源路径处理和os.Getenv读取时机：未暴露/healthz端点或返回非200导致livenessProbe失败重启；Docker镜像未显式COPY静态资源或路径写错致os.Stat失败；环境变量在init阶段读取后不再更新，需延迟到实际使用处获取。
直接说结论：Golang 应用迁移到 Kubernetes 不是“打包就完事”，核心卡点在 healthz 探针配置、静态资源路径处理、以及 os.Getenv 读取环境变量的时机——这三处出错，90% 的 Pod 会反复 CrashLoopBackOff。
为什么你的 Go 服务启动后立刻被 kill？
Kubernetes 默认启用 livenessProbe，而很多 Go 项目用 http.ListenAndServe 启动后没暴露健康端点，或健康接口返回非 200（比如没加 /healthz 路由、或路由写了但没注册到 mux）。Pod 启动成功后几秒就被 kubelet 杀掉重试。
- 必须显式提供一个低开销的健康检查端点，比如
/healthz，且 handler 只做内存/协程状态检查，不要查 DB 或外部服务 - 避免把
livenessProbe和readinessProbe指向同一个路径；readinessProbe可以稍重（如检查 DB 连接），但livenessProbe必须轻量且稳定 - Go 程序启动慢（比如加载 config、初始化连接池）时，务必设置
initialDelaySeconds，否则 probe 在程序 ready 前就开扫，必然失败
Go 编译的二进制在容器里找不到 static 文件？
本地 go run main.go 能读 ./assets，但 Docker 镜像里 os.Stat("./assets") 报 No such file or directory——因为 Go 二进制是静态编译的，不依赖当前工作目录；而镜像里你可能只 COPY 了二进制，没 COPY 静态资源，或者 WORKDIR 设错了。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 构建镜像时，用
COPY ./assets /app/assets显式复制资源目录，别依赖相对路径 - 代码里改用绝对路径读取：
fs := http.Dir("/app/assets")，而非http.Dir("./assets") - 更稳妥的方式是 embed（Go 1.16+）：
//go:embed assets/*+embed.FS，这样资源打到二进制里，彻底规避路径问题
ConfigMap 更新后，Go 服务里的 env 没变？
os.Getenv("DB_HOST") 在 init() 或 main() 开头调用，值是容器启动那一刻的快照。ConfigMap 更新后，Pod 不重启，env 就不会刷新——这不是 Kubernetes 的 bug，是进程生命周期决定的。
立即学习“go语言免费学习笔记（深入）”；
- 不要在 init 阶段缓存环境变量值；把
os.Getenv放到实际使用位置（比如每次 HTTP handler 中），或封装成 lazy getter - 若需热更新（如日志级别、超时时间），改用
watchConfigMap 文件挂载路径（如/etc/config/db.yaml），用fsnotify监听变更 - 注意：env 方式适合启动参数，不适合运行时可变配置；后者优先走文件挂载 + 主动 reload
最常被忽略的一点：Go 默认不设 GOMAXPROCS，在多核节点上跑单个 Pod 时，它可能只用 1 个 OS 线程，CPU 利用率永远卡在 100% × 1 core；加上 resources.limits.cpu: "2" 却没调 GOMAXPROCS，等于白配。真要压测或高并发，得在容器启动命令里加 GOMAXPROCS=2。
