Informer 缓存性能差的根源在于默认配置未启用服务端过滤，导致全集群对象（如Pod超5k时）被拉入内存，单个Informer常驻内存超200MB，引发GC频繁、同步卡顿甚至OOM；必须通过fieldSelector在List/Watch阶段就限制命名空间等条件，避免客户端if过滤白费带宽与内存。
Informer 缓存性能差，不是 Informer 本身慢，而是默认配置把全集群对象都拉进内存了——尤其 Pod、Event、Node 超过 5k 条时，单个 Informer 常驻内存轻松破 200MB，GC 频繁、同步卡顿、甚至 OOMKilled。
为什么 cache.NewSharedIndexInformer 一启动就吃光内存
默认构造的 cache.NewSharedIndexInformer 不带任何过滤，ListFunc 会调用 clientset.CoreV1().Pods("").List()，也就是对所有命名空间发起 List 请求。API Server 返回的是整个集群的 Pod 列表（含 status、events、ownerReferences 等冗余字段），每个 *corev1.Pod 在 Go runtime 中占 400–800 字节，加上 indexer 的 map[string]interface{}、DeltaFIFO 队列、reflector 缓存，内存开销呈线性增长。
- Pod 数量 ≥ 10k 时，首次 ListWatch 同步常卡住 5–15 秒，
informer.HasSynced()长时间返回false - 即使你只关心
default命名空间，没加FieldSelector就等于让 API Server 把其他 99 个命名空间的 Pod 全部序列化发过来，再在本地用if obj.(*corev1.Pod).Namespace == "default"过滤——数据早已进内存，白费带宽和 GC 压力 - 自定义
Indexers（比如按 label 或 phase 索引）会额外复制对象引用，进一步放大内存占用
必须用 fieldSelector 从服务端掐断无关对象流入
不能靠 Go 层面 if 过滤，必须让 API Server 在 List 和 Watch 阶段就只返回你需要的对象。Kubernetes 1.21+ 默认支持 metadata.namespace 字段索引，直接生效。
- 构造
cache.ListWatch时，ListFunc和WatchFunc必须共用同一个fields.OneTermEqualSelector("metadata.namespace", "default") -
ListFunc中传入的命名空间参数必须是空字符串""（表示不限定命名空间），否则fieldSelector会被忽略 - 确保
options.FieldSelector = selector.String()在调用List()/Watch()前已赋值，顺序错了等于没设 - 验证是否生效：启动后查日志，看
GET /api/v1/pods?fieldSelector=metadata.namespace%3Ddefault是否出现在 client-go 请求 URL 中
ResyncPeriod=0 和 Indexers 是内存双刃剑
禁用 resync 能省下周期性全量重刷的内存抖动，但若用了自定义 Indexers，它们仍会在每次 Add/Update 时重建索引结构，带来额外分配。关键不是“要不要”，而是“要不要得当”。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
ResyncPeriod设为0表示禁用，这是生产环境推荐值；设为非零值（如30 * time.Minute）仅用于兜底防缓存 drift，但会每半小时触发一次全量 List，慎用 - 如果只按
namespace查询，别加cache.Indexers{"by-label": ...}—— 多数场景用不上，反而增加 map 开销和 GC 压力 - 真需要 label 索引，优先用
cache.MetaNamespaceKeyFunc+cache.ByNamespaceIndex，它复用已有 key 结构，不新增对象拷贝 - 避免在
AddFunc里做json.Marshal、strings.ToLower等操作：这些临时分配会留在堆上，直到下次 GC，加剧内存碎片
Workqueue 和 client-go QPS 必须配平，否则越并发越卡
很多人以为“加 goroutine 就能提速”，结果 workqueue.Get() 内部 mutex 争抢加剧，同时 client-go 因 rest.Config.QPS 限速被堵住，事件积压在 DeltaFIFO 里，缓存看似“同步完成”，实际处理延迟飙升。
- worker 数量别硬写
runtime.NumCPU()，应匹配容器resources.limits.cpu：2 核容器设 2–3 个 worker 即可 -
rest.Config.QPS默认是 5，必须显式提高（如设为 20），否则 workqueue 消费再快也拿不到新事件 - 用
workqueue.NewRateLimitingQueue(workqueue.DefaultControllerRateLimiter())，别用裸chan—— 它自带失败退避，防止瞬时错误导致队列爆炸 - 每个
processNextWorkItem()处理完必须调用queue.Done(key)，漏掉会导致 key 永久阻塞，后续同 key 事件全丢
真正难的不是写对那几行 cache.NewSharedIndexInformer，而是理解每一步过滤发生在哪一层：fieldSelector 是服务端裁剪，ResyncPeriod 控制同步节奏，Indexers 决定缓存结构，workqueue 管理消费水位——少一个环节，缓存就不是“轻量本地视图”，而是“全量集群镜像”。
