clientv3.new初始化失败主因是endpoints格式错误（缺协议/端口）、tls配置缺失或未加grpc.withblock()，错误常延迟至put/get时才暴露为context.deadlineexceeded或rpc error: code = unavailable。
clientv3.New 初始化失败，大概率不是网络不通，而是 endpoints 格式错、TLS 配置缺失或没加 grpc.WithBlock()。连不上 etcd 的错误往往藏在初始化阶段，等你调 Put 或 Get 时才暴露为 context.DeadlineExceeded 或 rpc error: code = Unavailable。
clientv3.New 初始化必须带协议、端口和阻塞模式
etcd 客户端不会自动补协议或端口，传 []string{"127.0.0.1:2379"} 会被静默降级为 http://127.0.0.1:2379；若服务端只开 https，连接就彻底失败。
- 正确写法是显式带上协议：
[]string{"http://127.0.0.1:2379"}（测试）或[]string{"https://127.0.0.1:2379"}（生产） - 启用 TLS 必须传
tls.Config，哪怕只是跳过校验：&tls.Config{InsecureSkipVerify: true} - 务必加
grpc.WithBlock()，否则clientv3.New可能立即返回“成功”，但底层连接还在后台拨号，后续操作全卡住 - 别忘了
defer cli.Close()，长期运行程序不关 client 会导致 fd 耗尽
Put 写入不报错但值没进去，问题出在 context 和 error 判断
clientv3.Put 是强一致写入，但它不重试、不抛连接异常，只依赖 context 状态和 gRPC 底层反馈。写不进去却没报错，说明你没检查 err，或者用了 context.Background()。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 永远用带超时的 context：
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second) - 必须显式判断
err != nil—— 即使resp不为 nil，err为真就代表写入失败 - key 路径严格区分大小写和前缀：
/config/db/host和config/db/host是两个 key，少开头的/就读不到 - etcd v3 不要求父路径存在，
Put自动创建中间层级，不用先“mkdir”
Get 返回空或旧值，别怪 etcd，先看读选项和切片访问
默认 Get 是 linearizable 读（走 leader），延迟高但强一致；配置类场景更常用 clientv3.WithSerializable()，从任意节点读，更快也够用。
- 高频读配置建议加
clientv3.WithSerializable()：性能好，跨机房部署不易抖动 - 绝对不能对
resp.Kvs直接取[0]—— key 不存在时它是空切片，会 panic - 别把
Get结果缓存在全局变量里长期复用，etcd 不推变更，得靠Watch或轮询 - 刚
Put完立刻Get却读不到？检查是否用了WithSerializable()且 follower 有延迟；临时调试可去掉该 option 强制走 leader
Watch 收不到变更，不是接口坏了，是流没消费或上下文断了
clientv3.Watch 是长连接流式响应，不是注册一次就完事。它返回一个 chan clientv3.WatchResponse，缓冲区默认 100 条，一旦满就会阻塞后续事件。
- watch 启动后必须立刻起 goroutine 消费：
go func() { for wr := range watchChan { /* 处理 */ } }() - watch 默认从“当前 revision + 1”开始监听，如果配置在
Watch建立前已变更，就会漏掉 —— 更稳妥的是先Get一次拿到resp.Header.Revision，再用clientv3.WithRev(rev)启动 -
WatchChan关闭时不会报错，需检查ok == false并主动重建 watch - ctx 生命周期决定 watch 存活时间，别用短命的
context.WithTimeout包着整个 watch 循环
真正难的不是写几行 Put 或 Watch，而是让这套机制在服务长期运行中不丢事件、不卡死、不耗尽资源——这取决于你对 context 控制粒度、channel 消费节奏、revision 连续性以及 lease 绑定的理解。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
