Go语言开发kubectl插件本质是构建符合协议的可执行命令，核心三点：命名规则（kubectl-xxx且小写连字符）、stdin/os.Args上下文处理（需判别管道输入）、输出规范（纯文本/YAML/JSON、错误输出到stderr）。
Go 语言开发 Kubernetes 插件，本质是构建符合 kubectl 插件协议的可执行命令，不是写 CRD 控制器或 Operator。它不依赖 client-go 的复杂调度逻辑，核心就三点：命名规则、标准输入输出、退出码语义。
插件可执行文件必须叫 kubectl-xxx
Kubernetes 通过文件名前缀识别插件。只要二进制在 $PATH 中，且名称以 kubectl- 开头（如 kubectl-ns、kubectl-df-pods），kubectl 就会把它当作子命令自动发现。
- 文件名不能带点或下划线以外的符号，比如
kubectl-my_plugin可用，但kubectl/my-plugin或kubectl@df不行 - 避免和内置命令冲突，比如不要命名为
kubectl-get—— 运行时会报command "get" already exists - 建议用小写字母 + 连字符，符合 Unix 命令习惯，也方便
kubectl completion bash自动补全
读取 stdin 和 os.Args 处理上下文
kubectl 插件默认把当前上下文对象（如 YAML/JSON）通过 stdin 传入，同时把用户输入的剩余参数放进 os.Args[1:]。你得自己解析，不能假设总有输入流。
- 先检查
stat(stdin)是否为 pipe：用fi, _ := os.Stdin.Stat(); (fi.Mode() & os.ModeNamedPipe) == 0判断是否有数据流 - 如果没 stdin，可能用户想查帮助，应打印 usage 并 exit 0；如果期待输入却没给，建议 exit 1 并提示 “no input from pipe”
- 不要硬编码
client-go加载~/.kube/config—— 插件本身不需 kubeconfig，除非你要主动调 API；多数场景只处理传入的资源数据即可
输出必须是纯文本或合法 YAML/JSON，且保持结构可管道传递
插件输出会被后续命令（如 grep、jq）消费，所以不能混杂提示文字、进度条或 ANSI 颜色（除非加 --color=auto 开关并检测 os.Stdout.Fd() 是否为终端）。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 错误信息写到
os.Stderr，成功结果写到os.Stdout - 如果输入是 JSON，输出也尽量保持 JSON 格式（哪怕只改字段），否则下游
jq会失败 - 避免使用
log.Fatal—— 它会输出额外堆栈并 exit 1，但用户无法捕获原始错误原因；改用fmt.Fprintln(os.Stderr, "error: ..."); os.Exit(1)
交叉编译和分发要考虑 CGO_ENABLED=0
插件最终要被不同环境的用户运行，静态链接最稳妥。Go 默认开启 CGO，导致生成的二进制依赖系统 libc，在 Alpine 容器或某些 macOS 环境里直接报 not found。
- 构建时必须加
CGO_ENABLED=0 go build -a -ldflags '-s -w' -o kubectl-foo -
-s -w去掉调试符号，减小体积；-a强制重编所有依赖（含 stdlib），确保完全静态 - 发布时提供 SHA256 校验值，因为用户常通过
curl | sh安装，安全性不能妥协
最容易被忽略的是 stdin 流状态判断 —— 很多插件直接 io.ReadAll(os.Stdin)，结果在没管道输入时卡住或读空，导致行为不一致。实际场景中，用户既会 kubectl get pod -o yaml | kubectl-xxx，也会单独敲 kubectl xxx --help，两种路径都要显式覆盖。
