必须使用corev1.event而非eventsv1.event，因后者在k8s 1.22+已弃用且scheme隔离导致静默失败；watch断连需持久化resourceversion重连，用firsttimestamp判时间，去重用uid+reason+message组合哈希，集群级监听须配clusterrole权限。
直接监听 corev1.Event 是最稳妥、兼容性最好的方式，尤其适用于告警和轻量运维响应；用错类型（比如误用 eventsv1.Event）会导致 Watch 静默失败或返回空结果。
为什么必须用 corev1.Event 而不是 eventsv1.Event
events.k8s.io/v1beta1 在 K8s 1.22+ 已默认禁用，而 core/v1.Event 作为原生资源长期受支持。client-go 对这两类事件的 scheme 注册是隔离的：若初始化时只调了 eventsv1.AddToScheme，却用 corev1.EventList 去解码 Watch 流，会因类型不匹配导致静默失败——不会报错，但 ResultChan() 永远收不到事件。
- 务必在构建
scheme时显式调用corev1.AddToScheme(scheme) - Watch 接口必须配对使用：
clientset.CoreV1().Events(namespace).Watch()+corev1.EventList+corev1.Event - 不要依赖 IDE 自动补全选型——
eventsv1包下也有Event类型，但它是不同 API 组，不可互换
Watch 断连后如何避免丢事件
K8s 不保证事件持久化，Watch 长连接中断后，默认从最新 resourceVersion 重连，中间产生的事件就丢了。这不是 client-go 的 bug，而是设计使然。
- 生产环境必须持久化上一次成功消费的
resourceVersion（例如写入本地文件或 etcd），重启后从该值继续 Watch - 断连恢复时，先用该
resourceVersion发起 Watch；若返回 410 Gone，则退回到List()获取全量并更新resourceVersion - 别指望
--watch-cache：apiserver 默认只缓存 100 条事件，且需手动开启，不可靠
FirstTimestamp 才是真实发生时间，CreationTimestamp 不可靠
CreationTimestamp 是事件写入 etcd 的时间，高负载时可能比实际发生晚数秒甚至分钟；告警逻辑若用它做“5 分钟内新事件”判断，极易漏报。
- 过滤时间窗口请用
event.FirstTimestamp.Time或event.LastTimestamp.Time - 这两个字段可能为空（部分控制器未设置），必须先判空再比较：
if !event.FirstTimestamp.IsZero() - 去重要组合
event.InvolvedObject.UID + event.Reason + event.Message哈希，单靠时间戳或UID都不准
命名空间参数不能传空字符串来监听集群级事件
clientset.CoreV1().Events("").Watch() 看似想监听所有命名空间，但实际行为取决于 RBAC 和 server 实现：多数集群中它只返回 default 命名空间事件，或直接报错 Forbidden。
- 要监听全部命名空间，明确传
""（即空字符串），但必须确保 ServiceAccount 绑定的是ClusterRole，权限包含events资源的list/watch，而不仅是命名空间级Role - 更安全的做法是按需指定命名空间，比如只监听
monitoring或default，降低权限爆炸面 - 注意：集群级事件（如 node 事件）也归属某个 namespace，通常为
default或kube-system，并非游离于 namespace 外
真正难的不是写通 Watch，而是处理好断连续传、时间判定、去重和权限收敛这四点——它们不出现在示例代码里，但每一条都会在凌晨三点让你收到告警。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
