Beego启动时需在beego.Run()前用clientv3.LeaseGrant+Put向etcd写入带TTL的服务key（如/services/beego-api/10.0.1.5:8080），值为JSON元数据；退出时监听SIGTERM主动Delete或依赖lease自动过期。
Beego 启动时如何向 etcd 写入服务实例信息
Beego 本身不内置服务注册逻辑，必须手动在 main.go 的启动流程中插入 etcd 写入操作。关键点是：不能在路由注册前写，也不能在监听端口后才写——得卡在服务已就绪、但尚未接收请求的临界点。
推荐做法是在 beego.Run() 调用前，用 etcd 客户端（如 go.etcd.io/etcd/client/v3）写入带 TTL 的 key，例如 /services/beego-api/10.0.1.5:8080，值为 JSON 格式的服务元数据（host、port、version、weight 等）。
- TTL 建议设为 10–30 秒，太短易误删，太长故障发现延迟高
- key 路径需带服务名和实例唯一标识（IP+端口最稳妥），避免多个实例覆盖
- 务必使用
clientv3.LeaseGrant+clientv3.Put绑定 lease，否则 key 不会自动过期 - 写入失败要 panic 或阻塞启动，否则服务“活着却不可发现”
如何用 etcd Watch 实现 Beego 进程退出时自动注销
Beego 没有优雅退出钩子，直接监听 os.Interrupt 或 syscall.SIGTERM 是唯一可靠方式。重点不是“注册”，而是“反注册”——进程挂掉前必须显式删除或让 lease 过期。
实际中更推荐“不主动删，靠 lease 自毁”：只要进程崩溃，lease 到期后 key 自动消失。但为减少发现延迟，建议在信号捕获后主动调用 clientv3.Delete 清理 key，并同步关闭 etcd client。
- 别依赖 defer —— Beego 的 panic 恢复机制可能绕过 defer 执行
- Watch 本身不用于注销，它是消费者行为；注销是生产者（本实例）的责任
- 若用 systemd 管理，确保
KillMode=process，避免主进程被杀而子 goroutine 继续跑导致 lease 续约
Beego 中间件里怎么读取 etcd 配置并热更新
配置热更新不能靠每次请求都查 etcd，必须结合 clientv3.Watch 监听 key 变更，再更新内存变量。典型场景是限流阈值、开关、路由规则等。
常见错误是把 Watch 放在 controller 里——每个请求都起一个 Watch，连接爆炸。正确位置是全局初始化阶段，在 init() 或 main() 开头启动一个长期 goroutine，用 clientv3.WithPrefix 监听配置目录（如 /configs/beego-api/），变更时更新 sync.Map 或加锁 struct。
- Watch 返回的
clientv3.WatchChan必须持续 range，中断会导致漏事件 - 首次读配置要用
clientv3.Get拉全量，再启动 Watch，避免启动窗口期丢失初始值 - 变更回调里避免阻塞，复杂逻辑扔进缓冲 channel 处理，防止 Watch goroutine 卡住
- Beego 的
AppConfig是只读快照，无法热更新，别试图替换它
为什么 etcd key 设计要避免用 Beego 的 AppName 当前缀
beego.AppConfig.String("appname") 返回的是配置文件里的字符串，不是运行时唯一标识。多个实例如果共用同一份配置（比如容器镜像没改 appname），就会往同一个 key 写，造成覆盖或竞争。
真正需要的是实例维度隔离：服务名（固定）+ 环境（dev/staging/prod）+ 实例 ID（动态）。etcd key 应该类似 /services/api-prod/10-0-1-5-8080，而不是 /services/myblog/...。
- 环境字段必须显式传入，不能从 Beego 配置硬编码，否则 dev 和 prod 共用一套 etcd 时互相干扰
- IP+端口比 hostname 更可靠，K8s 下 hostname 可能重复，且 DNS 解析失败时不可用
- 不要把版本号放在 key 路径里（如
/v2/services/...），升级时旧实例还在，新旧 key 并存难清理 - prefix 末尾不加斜杠，
clientv3.WithPrefix对/services/和/services行为不同，后者会匹配到/services-api
