最稳妥方式是监听 corev1.event 资源，禁用 eventsv1.event 和已废弃的 events.k8s.io/v1beta1；须用 corev1.eventlist/list 和 corev1.event/watch，初始化前调用 corev1.addtoscheme(scheme)，命名空间传 "" 需 clusterrole 权限；断连防丢需 list 获取并持久化 resourceversion 用于重连；firsttimestamp 才是真实发生时间，须判空；去重用 uid+reason+message 哈希；生产环境必须限流、加锁、二次确认状态，并设人工确认开关。
corev1.Event 资源是最稳妥的方式，别碰 eventsv1.Event 或已废弃的 events.k8s.io/v1beta1 —— 后者在 K8s 1.22+ 默认禁用，前者类型错配会导致 Watch 静默返回空结果。
必须用 corev1.EventList 和 corev1.Event 类型
client-go 对资源类型的绑定非常严格：clientset.CoreV1().Events(namespace).List() 返回的是 *corev1.EventList，Watch() 流中每个 watch.Event.Object 必须能反序列化为 *corev1.Event。若误导入 eventsv1 并用于解码，API Server 不报错，但字段全为零值，日志里也看不到明显异常。
- 初始化 client 前，务必调用
corev1.AddToScheme(scheme)，否则解码失败 - 不要写
clientset.EventsV1().Events(namespace).Watch()—— 这个路径根本不存在，编译都过不去 - 命名空间传
""表示监听全部命名空间，但 RBAC 必须授予clusterrole权限，仅role会静默漏事件
Watch 断连后怎么不丢事件
K8s 不保证事件持久化，Watch 长连接断开后默认从最新 ResourceVersion 重连，中间产生的事件就没了。这不是 bug，是设计如此。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 启动 Watch 前，先调一次
List()获取当前ResourceVersion，并把它存到本地文件或 etcd（比如路径/var/run/kube-eventer/rv） - 重连时读取该值作为
ListOptions.ResourceVersion参数，避免跳过增量 - 别依赖 apiserver 的
--watch-cache：默认只缓存 100 条事件，且事件本身生命周期短（通常 1 小时自动清理） - 如果对可靠性要求极高，需自己实现带时间窗口的本地缓冲（例如内存中保留最近 5 分钟的
UID+Reason+Message哈希）
FirstTimestamp 才是真实发生时间
CreationTimestamp 是事件写入 etcd 的时间，常比实际发生晚几秒甚至分钟；高负载下批量上报时偏差更大。告警逻辑若用它做“5 分钟内新事件”判断，大概率漏报。
- 优先用
event.FirstTimestamp.Time（首次上报时间）或event.LastTimestamp.Time（最后聚合时间） - 这两个字段可能为空（部分控制器不设置），必须先判空：
if !event.FirstTimestamp.IsZero() - 去重要组合
event.InvolvedObject.UID+event.Reason+event.Message做哈希，单靠时间戳或UID都不可靠
生产环境必须加锁限流执行告警
事件洪峰常见（如节点宕机触发上千 Pod 重建事件），不做控制会导致告警风暴、下游服务被打挂、甚至自身 goroutine 泄漏。
- 用
sync.Mutex或singleflight.Group防止同一事件被并发处理多次 - 对相同
InvolvedObject.UID做滑动窗口限流（例如 1 分钟最多触发 3 次告警） - 告警前务必二次确认真实状态：比如收到
PodFailed事件，再Get()一次 Pod 看Status.Phase是否真为Failed，避免被中间状态误导 - 所有运维操作（如自动驱逐、重启）必须加人工确认开关或灰度比例控制，不能全自动
ResourceVersion 持久化和 FirstTimestamp 判空，最容易在压测或上线后才暴露。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
