go mod仅负责依赖管理，高可用取决于运行时设计：需真实健康检查、分层超时重试熔断、原子热配置、多阶段极简镜像构建。
go mod 本身不提供高可用能力，它只是依赖管理工具。真正决定模块能否在极端环境下存活的，是设计决策与运行时行为——比如是否容忍网络抖动、是否规避单点故障、是否能快速失败并恢复。
服务注册必须带真实健康校验，不能只靠 HTTP /health
很多团队把 go.mod 依赖写全、go run 跑通就以为模块“可用”，结果上线后注册中心一直显示 UP，但 DB 连接池已空、Redis ping 超时、HTTP client 被阻塞在 http.DefaultClient 上。
- 注册逻辑里必须定期调用
PassTTL()或UpdateHealthStatus()，间隔 ≤15s；K8s 场景下livenessProbe和readinessProbe必须分离 - 健康检查项要真实反映服务能力：
db.Pool().Stats().Idle > 0、redis.Ping(ctx).Err() == nil、http.Client的连接池是否仍有可用连接 - 避免只做
http.Get("/health")这类无意义探针——它不验证下游依赖，也不反映 goroutine 阻塞或内存泄漏状态
客户端调用必须分层控制超时 + 重试 + 熔断
直接用 http.DefaultClient 或 gRPC 默认 round_robin 负载均衡，在网络抖动时会迅速堆积请求、触发级联超时，最终雪崩。
-
context.WithTimeout()控制单次业务逻辑耗时，http.Client.Timeout控制连接+读写总耗时，gRPC 需显式设grpc.WaitForReady(false) - 重试必须带退避且有限次：HTTP 推荐
github.com/hashicorp/go-retryablehttp，gRPC 用grpc.RetryPolicy；禁止无限重试或固定间隔重试 - 熔断器需双指标触发：
sony/gobreaker中设MaxRequests: 10（最小采样窗口） +Timeout: 60 * time.Second，并手动包装context.Canceled错误，避免误判为失败
配置热更新必须原子，且运行时变量替换不可裸写
改个限流阈值还要发版重启？这等于在故障期间主动放弃响应能力。热更新不是监听文件变化就行，它涉及并发安全与状态一致性。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 禁止直接赋值全局变量：
limit = newLimit不是原子操作，goroutine 可能读到中间态 - 推荐用
sync/atomic或sync.RWMutex包裹可变配置；更稳妥的是用结构体指针替换 +atomic.StorePointer - 验证方式：在更新前后分别调用
atomic.LoadUint64(¤tLimit)，确认值变更无竞态、无丢失
Docker 多阶段构建必须用 FROM scratch 或 alpine:latest，禁用 debian 基础镜像
Go 静态编译二进制 + 容器化是高可用部署的物理基础。镜像体积大、攻击面宽、启动慢，本身就是极端环境下的单点风险。
- 生产镜像必须基于
scratch（无任何 shell、无 libc）或极简alpine:latest；严禁使用debian:slim或ubuntu类镜像 - Dockerfile 第一阶段用
golang:1.22-alpine编译，第二阶段 COPY 二进制进scratch，确保镜像 - 验证方式：运行
docker run --rm -it your-image ls /，输出应为空或仅含你的二进制文件；strace -e trace=connect,openat your-binary应无系统库调用失败
真正难的不是写一个能跑的模块，而是让这个模块在 CPU 打满、网络分区、DB 拒绝新连接、etcd 集群脑裂时，依然能给出明确失败信号、拒绝新请求、释放资源、不拖垮邻居——这些细节藏在健康检查的判定逻辑里、藏在熔断器的采样窗口设置里、藏在配置更新的原子性实现里，而不是 go mod init 的第一行。
