最可靠方式是监听 core/v1.Event；需调用 corev1.AddToScheme(scheme) 否则反序列化失败；断连后通过持久化 ResourceVersion 并重试 Watch 补漏；告警应优先用 FirstTimestamp/LastTimestamp 而非 CreationTimestamp；空命名空间字符串 "" 表示默认 NS，全集群需 RBAC 授权且传 ""；去重用 UID+Reason+Message 哈希；需结合 Kind 和 Message 正则识别真实异常。
直接监听 core/v1.Event 资源是最可靠方式
别用 eventsv1.Event 或 events.k8s.io/v1beta1，它们在 1.22+ 版本已弃用或默认禁用；core/v1.Event 是长期稳定、权限收敛、解码兼容性最好的选择。初始化 clientset 后，必须显式调用 corev1.AddToScheme(scheme)，否则 Watch 返回的 JSON 无法反序列化成结构体，静默失败且无报错。
Watch 连接断开后事件丢失怎么补
client-go 的 Watch 是长连接，网络抖动或 apiserver 重启会导致中断。Reflector 默认重连后从最新 ResourceVersion 开始同步，中间事件就丢了。
- 启动 Watch 前先
List()一次，拿到当前ResourceVersion并持久化（比如写入本地文件或 etcd） - 重连时用这个持久化的
ResourceVersion发起新 Watch，避免跳过变更 - Watch 中收到
watch.Error事件时，触发完整List()补漏——不是所有错误都可重试，有些需强制回滚到上一个已知版本
告警逻辑别依赖 CreationTimestamp
Event.CreationTimestamp 是 API Server 写入 etcd 的时间，常比实际发生晚数秒甚至分钟，尤其在高负载批量上报时。用它做“5 分钟内新事件”判断，大概率漏报。
- 优先用
event.FirstTimestamp.Time或event.LastTimestamp.Time做时间窗口过滤 - 这两个字段可能为空（部分控制器不设置），必须先判空再比较：
if !event.FirstTimestamp.IsZero() - 去重要组合
event.InvolvedObject.UID + event.Reason + event.Message哈希，单靠时间戳不可靠
命名空间传空字符串不是“全部”，而是“默认命名空间”
很多人误以为 clientset.CoreV1().Events("").Watch() 能监听全集群事件，其实它只查 default 命名空间。要覆盖所有命名空间，必须传 ""（空字符串），但前提是 RBAC 权限已授予 clusterrole 级别的 list/watch 权限，否则会静默返回空结果或 403。
立即学习“go语言免费学习笔记（深入）”；
- 生产中建议按需指定命名空间，比如只监听
mcp-system或业务关键 NS，降低资源消耗 - 若真需全集群，RBAC 规则里
resources: ["events"]必须配verbs: ["list", "watch"]，且resourceNames不要限制 - 注意：
corev1.EventList的Items是指针切片，遍历时别漏掉解引用：for _, e := range eventList.Items { fmt.Println(e.Reason) }
真正难的不是监听，是区分噪声和异常——比如 Reason=Pulling 是正常流程，Reason=FailedScheduling 才该触发告警；而 Reason=Unhealthy 可能来自不同控制器，得结合 InvolvedObject.Kind 和 Message 正则匹配才能准确定义“异常”。
