看起来你已经做了不少路径配置的工作，但gcloud-cli安装过程还是“偷偷”调用了系统的Python3.8，这种情况我也碰到过，主要是brew cask执行安装脚本时的环境继承问题，或是gcloud内部virtualenv初始化的小坑。下面给你几个针对性的解决办法，按优先级从高到低来：

1. 显式导出环境变量后重新安装，确保变量被正确传递 #

虽然你已经在.zshrc里设置了CLOUDSDK_PYTHON，但brew的cask安装过程可能在新的无配置shell环境中执行，没读到你的用户级配置。可以试试在同一个命令行会话里直接导出变量再重装：

# 直接写死brew Python的绝对路径，避免路径解析歧义
export CLOUDSDK_PYTHON=/usr/local/opt/python@3.13/libexec/bin/python3
brew reinstall --cask gcloud-cli

这里建议统一用同一个Python版本（比如要么全用3.13，要么全用3.14），你当前which python指向3.14，但安装命令里用的是3.13路径，这种版本混杂也可能引发解析问题。

2. 跳过自动初始化，手动指定Python完成gcloud配置 #

gcloud安装时的自动virtualenv创建步骤最容易出问题，你可以先强制完成安装，再手动初始化：

• 先忽略错误强制安装gcloud-cli：

brew install --cask gcloud-cli --force

• 手动调用gcloud的virtualenv创建命令，明确指定brew的Python路径：

/usr/local/share/google-cloud-sdk/bin/gcloud config virtualenv create --python-to-use /usr/local/opt/python@3.13/libexec/bin/python3

• 最后验证是否生效：

gcloud --version

看输出里的Python版本是否为你brew安装的版本。

3. 系统级配置路径优先级，确保brew Python全局可用 #

有时候即使改了用户级的.zshrc，子进程还是会优先读取系统路径。可以把brew Python的路径加到系统级的路径配置里：

1. 用编辑器打开系统路径配置文件（需要sudo权限）：

sudo nano /etc/paths

2. 把/usr/local/opt/python@3.13/libexec/bin移到文件最顶部，保存退出。
3. 重启终端，再重新执行gcloud-cli的安装命令。

4. 直接修改gcloud全局配置文件，硬指定Python路径 #

如果上面的方法都不行，可以直接修改gcloud的配置文件，强制它使用指定的Python：

1. 打开gcloud的全局配置文件：

nano ~/.config/gcloud/properties

2. 添加或修改以下内容：

core/python_location = /usr/local/opt/python@3.13/libexec/bin/python3

3. 保存后验证配置：

gcloud info

查看输出里的Python location字段是否已经变成你指定的路径。

为什么之前的配置没生效？ #

你提到安装命令里明明显示了--python-to-use /usr/local/opt/python@3.13/libexec/bin/python3，但还是报错用了系统Python，大概率是gcloud创建virtualenv的子进程没有继承当前shell的环境变量——brew cask的安装脚本可能以无shell或sudo的方式运行，跳过了用户级的.zshrc配置，导致系统路径被优先读取。

另外你当前which python指向3.14，但安装命令里用的是3.13的路径，这种版本混杂也可能让gcloud的初始化逻辑混乱，建议先统一用同一个brew安装的Python版本再尝试。

可以先试试第一个方法，我之前碰到类似问题就是这么解决的，要是不行再往下试其他办法。