必须手动将kubectl.exe所在目录加入path，否则系统无法识别kubectl命令；常见错误是执行kubectl version报“not recognized”，验证需新开powershell运行get-command kubectl和kubectl version --client。
为什么kubectl安装脚本里要手动设置$PATH
因为Windows默认不把下载目录加入系统路径，kubectl.exe放哪它就只在那能运行。不加到PATH，你每次执行都得敲完整路径，比如C:\Users\Alice\Downloads\kubectl.exe version --client——没人这么干。
常见错误现象：执行kubectl version --client报错'kubectl' is not recognized as an internal or external command，就是PATH没生效。
- PowerShell中临时生效用
$env:PATH += ";C:\path\to\kubectl"，但关掉窗口就丢 - 永久生效必须改系统或用户级环境变量，且需重启终端或新开PowerShell才能识别
- 如果用
choco或scoop安装，这步自动完成；二进制方式必须自己动手
如何验证PATH配置是否真正生效
别只看“环境变量编辑器里填了”，很多用户填完没重启终端，或者填错了路径（比如漏了kubectl.exe所在文件夹，填成C:\Users\Alice\Downloads\却忘了该目录下实际是C:\Users\Alice\Downloads\kubectl.exe）。
正确验证顺序：
- 打开全新PowerShell窗口（不是旧窗口点“重新运行”）
- 运行
Get-Command kubectl—— 有输出说明系统能找到可执行文件 - 再跑
kubectl version --client，看到版本号才算通过 - 如果
Get-Command没结果，用echo $env:PATH检查路径是否拼写正确、有无多余空格或中文字符
kubectl安装脚本中容易忽略的权限与校验环节
跳过校验直接运行下载的kubectl.exe，等于把未知二进制扔进系统PATH——它可能被中间人篡改，或下载中断导致损坏。官方提供.sha256就是为了防这个。
PowerShell里校验命令看似简单，但有两个坑：
-
$(Get-Content .\kubectl.exe.sha256)读出来是带换行符的字符串，而Get-FileHash输出的.Hash是纯十六进制字符串，直接-eq比对会失败；正确写法是(Get-FileHash .\kubectl.exe -Algorithm SHA256).Hash.Trim() -eq (Get-Content .\kubectl.exe.sha256).Trim() - 如果用
curl.exe下载但没加-L参数，遇到重定向会失败，返回HTML而不是二进制；务必用curl.exe -LO - 版本号硬编码（如
v1.28.0）不如动态获取：$ver = (Invoke-RestMethod https://dl.k8s.io/release/stable.txt).Trim()，避免脚本过期失效
多版本共存时环境变量怎么不打架
开发/测试环境常需切换不同kubectl版本（比如集群是v1.27，但CI要用v1.26测试兼容性）。全靠PATH顺序硬拼不是办法——谁在前面谁生效，改PATH太糙。
更可控的做法：
- 把不同版本放在不同目录，例如
C:\k8s\kubectl-v1.26\kubectl.exe、C:\k8s\kubectl-v1.27\kubectl.exe - 不把它们加进全局PATH，而是用别名：
Set-Alias kubectl26 "C:\k8s\kubectl-v1.26\kubectl.exe"，需要时调kubectl26 version --client - 或者用
scoop reset kubectl快速回退到指定版本（前提是用scoop管理）
PATH本身没有“版本感知”能力，所谓“配置环境变量”本质只是告诉系统去哪找可执行文件——找哪个，取决于你让它找哪个。
