k8s.io/client-go 的 Scheme 需手动注册所有资源类型，因默认仅注册 core/v1，apps/v1 等扩展组及 CRD 必须显式调用 AddToScheme；否则 runtime.Decode() 会 panic。
为什么 k8s.io/client-go 的 Scheme 需要手动注册所有资源类型
因为 client-go 默认只注册核心 API 组（core/v1），而 CustomResourceDefinition（CRD）或扩展 API 组（如 apps/v1、networking.k8s.io/v1）不会自动加载——不显式 AddToScheme，runtime.Decode() 会直接 panic 报 no kind "Deployment" is registered for version "apps/v1"。
实操建议：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 每个要检查的资源类型，都得调用对应包的
AddToScheme(scheme)，比如：appsv1.AddToScheme(scheme)、networkingv1.AddToScheme(scheme) - CRD 资源必须提前安装到集群，且你的 Scheme 要能识别其 GroupVersionKind；否则
Unstructured解码后无法转成结构体做字段校验 - 别依赖
scheme.Default()自动补全——它不解决注册缺失问题，只影响默认值填充
用 Unstructured 还是强类型 struct 做 lint 规则校验
取决于规则粒度和维护成本：Unstructured 灵活但易出错，struct 安全但需同步更新类型定义。
常见错误现象：用 map[string]interface{} 手动递归取 spec.replicas，结果遇到 int64 和 float64 类型混用，== 比较永远 false。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 简单存在性/字符串匹配（如 label 格式、name 命名规范）→ 用
Unstructured.UnstructuredContent()配合gjson或原生 map traversal - 数值范围、嵌套结构约束（如
resources.limits.cpu必须 ≤requests.cpu）→ 必须转成*appsv1.Deployment等强类型，靠编译器和DeepEqual避免类型误判 - 混合场景下，先用
Unstructured做快速预筛（比如跳过非 Deployment 对象），再对目标对象转 struct —— 减少 decode 开销
ValidateAdmissionPolicy 不能替代你写的 Lint 工具
因为 ValidateAdmissionPolicy 是集群级准入控制，运行在 apiserver 中，只对 live state 生效；而 Lint 是离线静态检查，跑在 CI 或本地，面向 YAML 文件或 Git 仓库。
使用场景差异明显：
- Lint 工具能查
deployment.yaml里写了image: latest，但 admission policy 很难可靠解析镜像 tag 是否为latest（没 runtime context） - Lint 可以跨多文件分析（比如 Service 和 EndpointSlice 是否匹配），admission 是单对象粒度
- 如果你在 CI 里用
kubectl apply --dry-run=client -o yaml输出再喂给 Lint，注意--dry-run=client不触发 CRD schema validation，可能漏掉字段类型错误
如何让 Lint 规则支持用户自定义配置（比如允许某些命名空间跳过检查）
硬编码规则 = 维护噩梦。必须把策略和逻辑分离，否则每加一个例外就要改代码、发版、重启 CI。
实操建议：
- 用
config.yaml定义规则开关和参数，例如：skipNamespaces: ["kube-system", "monitoring"]，加载时用gopkg.in/yaml.v3解析到 struct - 规则函数接收
*unstructured.Unstructured和*Config两个参数，而不是闭包捕获全局变量——方便单元测试 mock 配置 - 避免在规则里写
if ns == "default" { return nil }，改成if config.ShouldSkipNamespace(obj.GetNamespace()) { return nil }，后续加正则或前缀匹配也容易
最常被忽略的是配置热加载：CI 流水线一般不重用进程，所以不用搞 fsnotify 监听；但如果你做成 long-running webhook 服务，就得小心 os.ReadFile 同步阻塞和并发读写冲突。
