启动后须立即验证http/grpc端口真实监听，避免静默失败；容器需用livenessProbe探活；路径/环境变量差异要求绝对路径与工作目录打印；健康检查须覆盖真实依赖并带超时降级；必需配置禁止静默降级；检查逻辑需响应context取消。
启动后立刻检查 http.Server 和 grpc.Server 是否真正监听
很多服务看似“启动成功”，日志里写着 start http server at [::]:8080，但实际端口没绑上或被其他进程占了。Go 的 http.ListenAndServe 和 grpc.NewServer().Serve 都是阻塞调用，一旦失败会直接 panic 或静默退出——而你的主 goroutine 可能已经结束了，进程就退了，根本没机会打日志。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在
http.ListenAndServe前加net.Listen("tcp", addr)主动探测端口可绑定性，失败时提前退出并打印明确错误 - 对 gRPC 服务，用
lis, err := net.Listen("tcp", addr)+srv.Serve(lis)拆开写，避免grpc.NewServer().Serve(net.Listen(...))这种“黑盒”调用掩盖底层失败 - 容器环境务必在
livenessProbe中用curl -f http://localhost:8080/healthz或grpc_health_probe，不能只依赖进程存活
go run 和 go build 启动行为差异导致的自测盲区
本地用 go run main.go 跑得通，线上 ./myapp 启动就卡住或 panic，常见原因是：路径、工作目录、环境变量加载时机不同。比如 os.Getwd() 在 go run 下返回的是 main.go 所在目录，而二进制运行时默认是启动路径（可能是 / 或 /tmp）；又比如 .env 文件读取逻辑若依赖相对路径，就会失效。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有配置文件路径统一用绝对路径，或基于
os.Executable()推导根目录：execPath, _ := os.Executable(); rootDir := filepath.Dir(execPath) - 启动时强制打印当前工作目录：
wd, _ := os.Getwd(); log.Printf("working dir: %s", wd)，上线前必加 - 用
go build -ldflags="-X 'main.buildTime=$(date -u +%Y-%m-%d_%H:%M:%S)'"注入构建时间，便于区分是哪个版本在跑
健康检查端点必须覆盖真实依赖，不能只返回 OK
写个 /healthz 返回 {"status":"ok"} 是最常见也最危险的自测方式。它完全不验证数据库连接、Redis 是否可写、下游 gRPC 服务是否可达——等真出问题时，K8s 已经把流量切过去了。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- HTTP 健康检查分两级：
/healthz（轻量，只检查自身状态）、/readyz（重载，查 DB、Redis、关键下游） - 每个依赖检查加超时和降级：比如 Redis Ping 超过 300ms 就标记为不可用，但不导致整个
/readyz失败 - gRPC 服务必须集成
grpc-health-probe，且在main()中注册health.RegisterHealthServer，否则 K8s 的grpcHealthProbe会永远返回NOT_SERVING
环境变量和配置加载失败时，程序不该静默降级
很多 Go 项目用 viper 或手写配置解析，遇到 config.yaml 缺失或字段类型错（比如把 port: "8080" 写成字符串），就 fallback 到默认值。线上环境用默认值可能连 DB 地址都错了，但进程照常启动，日志里连 warning 都没有。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有必需配置项（如
DB_DSN,REDIS_ADDR）在init()或main()开头显式校验，缺失或非法就log.Fatal - 禁用 viper 的自动 fallback：
viper.SetDefault只用于非关键字段；关键字段一律用viper.GetString("DB_DSN")+if val == ""报错 - 用
go run -gcflags="all=-l" main.go启动调试版，确保init()里的校验逻辑不会被编译器优化掉
线上自测最易忽略的一点：你写的检查逻辑本身是否在信号中断（如 SIGTERM）下仍能完成执行。比如 /readyz 正在查 DB，此时收到终止信号，handler 被强制退出，返回了 503，但你误以为是依赖故障。真正可靠的自测，得让检查逻辑带 context 并响应 cancel。
