必须先判空再解码：if pair == nil || pair.value == nil，否则json.unmarshal(nil, &v)会panic；推荐封装统一入口函数处理key不存在、value为空、解析失败三类情况。
Consul KV读取时nil panic怎么防
直接用kv.Get拿到*api.KVPair后不判空就解码，十有八九panic。Consul的KV接口对不存在的key或空值返回pair == nil或pair.Value == nil，不是错误，但json.Unmarshal(nil, &v)会直接崩溃。
- 必须先检查：
if pair == nil || pair.Value == nil，再决定是报错、用默认值还是跳过 - 推荐封装统一入口函数
GetConfig(key string, v interface{}) error，内部处理三种失败：key不存在（404）、value为空、JSON解析失败 - 别在日志里只写“get config failed”，要带key和具体错误，比如
consul kv get /services/user/timeout: value is nil
viper + Consul热更新为什么没生效
常见假象：监听回调执行了，日志也打了“reloaded”，但业务代码读到的还是旧值。根本原因通常是结构体字段没被正确反序列化。
- 字段必须首字母大写（导出），私有字段即使加
json:tag也不会被mapstructure解析 - YAML里写
redis_url: 127.0.0.1，结构体字段叫RedisUrl，就得显式加mapstructure:"redis_url"，不能只靠json:"redis_url" - 启用下划线转驼峰：
viper.SetEnvKeyReplacer(strings.NewReplacer("_", "."))，否则db_host匹配不到DbHost - 每次重载都用
viper.ReadConfig(bytes.NewReader(data))，不是UnmarshalKey——后者不触发全局重置
Watch回调里该不该重建数据库连接池
热更新不是改完变量就完事。配置变了，底层资源得跟着动，否则更新等于白更。
-
MaxOpenConns变了？必须调db.SetMaxOpenConns(newVal)，否则连接池大小卡在启动时的值 -
ConnMaxLifetime或ConnMaxIdleTime变了？同样要调对应Set*方法 - gRPC客户端KeepAlive参数变了？得重建
grpc.Dial连接，不能只改配置变量 - 所有这类响应逻辑必须写在Watch回调里，且加锁保护——避免并发读配置时结构体正被写入
Consul Watch超时导致连接堆积怎么办
Consul默认long poll超时5分钟，如果客户端没及时处理完回调，下次Watch又发起，连接数会缓慢上涨，最终耗尽fd。
- 初始化Consul client时显式设置
WaitTime: 30 * time.Second，别依赖默认值 - Watch路径用前缀（如
/services/order/），不用单key——单key监听漏变更，前缀能捕获新增/删改所有子项 - 回调函数必须快进快出，耗时操作（如DB重连）扔进goroutine，但注意并发安全
- 首次加载失败必须阻塞启动或panic，带空配置跑起来比启动失败更难排查
配置中心真正的复杂点不在读取，而在“哪些组件要响应”和“怎么安全地响应”。没人替你写db.SetMaxOpenConns，也没人帮你加锁或判空——这些都得自己埋进去，而且得在第一次Watch回调就验证到位。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
