kubectl插件需显式加载kubeconfig：用clientcmd.NewDefaultClientConfigLoadingRules()和NewInteractiveDeferredLoadingClientConfig()获取rest.Config，再调config.Namespace()和config.CurrentContext；交叉编译应设CGO_ENABLED=0避免Alpine兼容问题。
直接用 go 编写的 kubectl 插件，只要可执行文件名以 kubectl- 开头、放进了 $PATH，就能被 kubectl plugin list 识别并调用。但绝大多数人卡在第一步：插件根本连不上集群——报错 error: the server doesn't have a resource type "pod" 或 no configuration has been provided，不是代码逻辑问题，是配置加载没走对路。
为什么 clientcmd.BuildConfigFromFlags("", "") 总失败
很多人照着 client-go 官方示例写 clientcmd.BuildConfigFromFlags("", *kubeconfig)，本地调试能跑，一打包成插件就崩。因为 kubectl 启动插件时不会自动透传 KUBECONFIG 环境变量，子进程里 os.Getenv("KUBECONFIG") 是空的，而 BuildConfigFromFlags 第二个参数为 "" 时不会 fallback 到默认路径。
正确做法是显式构造标准加载规则：
- 用
clientcmd.NewDefaultClientConfigLoadingRules()获取默认查找逻辑（先查KUBECONFIG环境变量，再查~/.kube/config） - 再套一层
clientcmd.NewInteractiveDeferredLoadingClientConfig()，确保交互式提示（比如证书过期时）可用 - 最后调
config.ClientConfig()拿到 *rest.Config，别跳步
如何复用 kubectl 当前上下文和 namespace
插件不该自己解析 ~/.kube/config 文件去读 current-context 或 namespace。client-go 提供了现成方法，但容易被忽略：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 加载完 config 后，调
config.Namespace()获取当前上下文的 namespace，不是硬读default - 如果要获取当前 context 名字，用
config.CurrentContext字段，它来自 config 文件本身，不是环境变量 - 别在 flag 里暴露
--namespace却不跟 context 联动——用户切了 context 但忘了改 flag，结果查错 namespace
交叉编译后 Alpine 镜像里 panic 怎么办
Go 默认静态链接，但一旦用了 net 包（比如 DNS 解析）或 os/user（比如查 HOME），CGO 就会启用，导致二进制依赖宿主机 libc。Alpine 镜像里没 glibc，直接 panic: standard_init_linux.go:228: exec user process caused: no such file or directory。
两个实操选择：
- 编译时加
CGO_ENABLED=0 go build -a -ldflags '-extldflags "-static"'，强制纯静态链接（注意：某些云厂商 SDK 可能不兼容） - 改用
gcr.io/distroless/static:nonroot或debian:slim基础镜像，避开 Alpine - 检查是否真需要
os/user.Lookup——用os.Getenv("HOME")更轻量，且不触发 CGO
最常被跳过的细节是：插件内调用 exec.Command("kubectl", "get", "pod") 时，子进程完全不继承父进程的 kubeconfig 加载结果，必须手动把 KUBECONFIG 环境变量塞进去，或者干脆别调外部 kubectl，直接用 client-go 走 API——后者更可控，也避免 shell 注入风险。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
