必须使用 client-go 的 clientcmd 包解析 kubeconfig；本地用 buildconfigfromflags("", abspath) 传绝对路径，集群内用 inclusterconfig() 自动加载服务账户凭证。
Go 程序直接读取或操作 Kubernetes 配置（kubeconfig 文件）时，不能靠自己解析 YAML，必须用 client-go 提供的 clientcmd 包——它负责加载、合并、验证和构建可连接集群的 *rest.Config。
如何从本地 kubeconfig 文件构建 rest.Config
本地开发调试最常见路径是读取 ~/.kube/config 或自定义路径。关键不是“打开文件”，而是调用 clientcmd.BuildConfigFromFlags("", kubeconfigPath)：
-
BuildConfigFromFlags第一个参数是masterURL，通常留空（""），让 client-go 从配置里自动提取server地址 - 第二个参数必须是绝对路径；相对路径（如
"./config/kubeconfig"）在某些工作目录下会失败，建议用filepath.Abs()显式转义 - 如果文件不存在、格式错误或证书过期，
err会非空，且错误信息通常含invalid configuration或x509字样，不要忽略
示例片段：
config, err := clientcmd.BuildConfigFromFlags("", "/home/user/.kube/config")
if err != nil {
log.Fatal("failed to load kubeconfig:", err)
}
如何在 Pod 内使用 InClusterConfig
部署到集群后，程序应改用 rest.InClusterConfig()，它不读文件，而是从 /var/run/secrets/kubernetes.io/serviceaccount/ 下自动加载 token 和 CA 证书：
- 这个函数只在 Pod 内有效；本地运行时会返回
open /var/run/secrets/...: no such file or directory - 不需要传任何参数，但必须确保 ServiceAccount 有对应 RBAC 权限，否则后续
Get()或List()会报Forbidden - 别把它和
BuildConfigFromFlags混用——二者返回的*rest.Config结构一致，但来源和认证方式完全不同
多个 kubeconfig 文件怎么合并
client-go 原生支持合并多个配置文件（比如多集群管理场景），靠的是 clientcmd.NewNonInteractiveDeferredLoadingClientConfig + 自定义 clientcmd.ClientConfigLoadingRules：
- 设置
LoadingRules.ExplicitPath为""，再把多个文件路径塞进LoadingRules.Precedence切片（顺序决定优先级） - 合并后，
current-context仍生效，但所有clusters、users、contexts都被扁平合并；重名 context 会覆盖，不是报错 - 注意：合并不解决权限冲突，比如两个 config 里同名 user 使用不同证书，最终用的是后加载的那个
为什么 rest.Config 构建成功了，但 clientset 操作仍失败
常见陷阱不在配置加载，而在后续使用：
-
rest.Config缺少Timeout字段？默认是 0（无限等待），网络卡顿时会 hang 死，建议显式设config.Timeout = 30 * time.Second - 没启用 TLS SNI 或跳过证书校验？生产环境严禁设
Insecure: true；测试可用，但必须配TLSClientConfig.Insecure = true，且仅限BuildConfigFromFlags场景 - token 过期或 serviceaccount 被删？
InClusterConfig下的 token 是 secret 挂载的，有效期默认 1 年，但可能被管理员提前轮换
真正难排查的，往往是 config 看似构建成功，但 clientset.CoreV1().Pods("default").List() 返回 Unauthorized 或 Forbidden——这时要回头检查 ServiceAccount 绑定的 Role/ClusterRole，而不是重读 kubeconfig。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
