goland 不解析或切换 kubeconfig context，完全依赖启动时继承的 shell 环境变量（如 kubeconfig 和 current-context）；必须从已配置好的终端启动，或在 run configuration 中显式指定 --kubeconfig 参数。
GoLand 本身不解析或切换 kubeconfig context
GoLand 没有内置的 kubeconfig 管理器，也不会读取 current-context 或响应 kubectl config use-context。它调用 kubectl 时，完全依赖系统环境——也就是说，它只认你 shell 中当前生效的那个 context。
所谓“在 GoLand 中配置 kubeconfig”，本质是确保 GoLand 启动时继承了正确的 shell 环境变量（尤其是 KUBECONFIG 和 shell 的当前 context 状态），而不是在 IDE 里点几下就自动切集群。
必须让 GoLand 继承 shell 的 KUBECONFIG 和 context 状态
GoLand 默认启动方式（如桌面图标、Spotlight）通常不加载你的 shell 配置（~/.zshrc、~/.bash_profile），导致它看不到你用 export KUBECONFIG=... 设置的多文件路径，也读不到 kubectl config use-context 切换后的结果。
解决方法只有一个：从已正确配置的终端中启动 GoLand：
- 在终端中先完成 context 切换：
kubectl config use-context dev-cluster - 确认生效：
kubectl config current-context输出应为dev-cluster - 再运行：
open -a GoLand（macOS）或goland（Linux，需 PATH 正确）
这样 GoLand 就会复用该终端的环境变量和当前 context。如果你用的是 JetBrains Toolbox，也要确保它是从同一终端启动的，否则 Toolbox 自身进程不继承 shell 环境。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
在 Run Configuration 中硬编码 --kubeconfig 是最稳的兜底方案
当你无法控制启动方式（比如 CI/CD 脚本、远程开发容器），或需要为某个特定调试任务绑定固定集群时，不要依赖环境继承——直接在 GoLand 的 Run Configuration 中显式传参：
- 编辑 Run Configuration → Program arguments 栏
- 加上：
--kubeconfig /path/to/your/dev-config - 或者对 kubectl 命令行工具本身加参数：
kubectl --kubeconfig ~/.kube/config-dev get pods
注意：--kubeconfig 参数优先级最高，会完全忽略 KUBECONFIG 环境变量和默认 ~/.kube/config；多个 --kubeconfig 不被支持，只接受单个路径。
别信插件说能“可视化切换 context”
目前没有任何 GoLand 插件能真正接管 kubeconfig context 切换逻辑。有些插件（如 Kubernetes 或 Cloud Code）可以读取 kubectl config get-contexts 并列出选项，但点击切换后，只是帮你执行一条 shell 命令——它不会刷新 GoLand 内部状态，也不影响后续 kubectl 调用，除非你同时从终端重启 GoLand。
更关键的是：这些插件无法感知你是否用了 KUBECONFIG 多路径合并，也无法处理 base64 编码的 certificate-authority-data 解析失败等底层问题。它们展示的 context 列表，只是 kubectl config view --raw 的静态快照。
真正的隔离靠的是配置文件分离 + 显式参数，不是 UI 点击。
