明明已经从 ~/.zshrc 把某个 环境变量 （像是 ANTHROPIC_BASE_URL）删掉了，但回到终端一查，它居然还在！
就算重新执行 source ~/.zshrc 也完全没用？
如何检查环境变量是否存在？又是被哪个配置文件写入的？
在动手清理之前，首先需要确认变量是否仍然留在目前的内存中，以及究竟是哪个配置文件在自动加载它。
1. 检查内存变量
检查目前 Terminal 的内存中是否依然残留该 环境变量
env | grep -i anthropic
2. 搜索配置文件来源
全面搜索 Zsh、Bash 及系统层级配置文件，找出究竟是哪个文件写入了该变量
grep -rn "ANTHROPIC_BASE_URL" ~/.zshrc ~/.zprofile ~/.zshenv ~/.zlogin ~/.bashrc ~/.bash_profile ~/.profile /etc/zshenv /etc/zprofile /etc/profile /etc/environment 2>/dev/null
为什么修改 .zshrc 后旧的环境变量还在？
其实，当你打开终端时，环境变量 就已经被加载到那一套连接的“内存”里了。
就算你修改了文件，或者重新执行 source ~/.zshrc，这只会“重新加载”配置文件里的内容，并不会自动把已经存在内存中的旧变量给清除掉。
source命令只会覆盖或新增变量，并不会帮你“删除”变量
这时候最简单的解决方法有以下几种：
| 清除方式 | 操作指令 / 动作 | 说明 |
|---|---|---|
| 开启新窗口 | 开启全新终端标签页 | 新的 Shell Process 会重新读取最新的 ~/.zshrc |
| 手动清除 | unset ANTHROPIC_BASE_URL |
直接从目前内存中删除指定的 环境变量 |
| 重置 shell | exec zsh -l |
重新加载目前 Shell 的内存状态 |
重开终端窗口还是没用？揪出排查三大元凶
那为什么有时候明明开了全新的终端窗口，旧的 环境变量 依然阴魂不散？
这时候问题就不在 ~/.zshrc 了，而是来自“父进程（Parent Process）”的继承！
当你从某个软件启动终端时，子进程会直接复制父进程当下的环境变量快照。
如果遇到这种顽固的 环境变量，通常是以下三个常见原因：
| 类型 | 触发原因 | 解决方式 |
|---|---|---|
| IDE 内置终端 | VS Code、Cursor 或 Antigravity 启动时记录了当时的环境变量快照 |
按下 Cmd + Q 彻底退出 IDE 后重新开启 |
| 终端软件未关闭 | Mac 上的 Terminal 或 iTerm2 仅关闭窗口（Cmd + W），主程序仍在后台运行 |
按下 Cmd + Q 彻底退出 Terminal 软件 |
| tmux | tmux 后台 Server 持续运作，新标签页会一直继承启动时的设置 |
执行 tmux kill-server 关闭后台服务 |
重开软件依然无效？检查第三方工具与系统层级设置
如果上面三招都试过了，环境变量 依然顽固地出现在 Terminal 中，那可能是更高层级的系统设置或第三方工具在幕后搞鬼。
更高的系统权限或包装脚本会让环境变量在每次启动时自动恢复
这时候可以使用以下两大检测命令：
| 检测目标 | 命令 | 说明 |
|---|---|---|
| 系统全局变量 | launchctl getenv ANTHROPIC_BASE_URL |
检查是否有第三方代理工具使用 launchctl setenv 写入全局变量 |
| 命令包装脚本 | type claude |
检查目前的命令是原始可执行文件，还是被包装成带有默认变量的 wrapper 脚本 |
彻底清除环境变量的标准排查步骤
下次在修改或删除 ~/.zshrc 中的 环境变量 时，记得先确认：目前的终端是不是继承了旧的 Parent Process 设置？
按照以下排查顺序，就能轻松找到源头并解决问题：
- 先执行
unset 变量名称或开启全新终端窗口。 - 若使用
VS Code或Cursor等IDE，按下Cmd + Q彻底重启IDE。 - 若使用
tmux，执行tmux kill-server重置后台服务。 - 检查
launchctl getenv与type命令，排查系统层级与包装脚本。