终端、SSH、launchd、tmux：zsh 启动文件到底读了哪些
内容提要
文章探讨了macOS终端、SSH、launchd和tmux等场景下zsh启动文件的读取机制，指出环境变量继承差异导致工具找不到的问题。作者实测各场景，强调.zshrc仅交互shell读取，.zshenv则普遍适用，并建议将PATH和密钥配置于.zshenv，launchd服务需显式设置环境，以统一环境配置。
延伸解读
环境变量继承的常见误区
许多用户误以为所有终端场景都会读取 .zshrc，但实际只有交互式 shell 才会读取。SSH 执行命令、cron、launchd 服务等非交互场景只读取 .zshenv 或完全不读。这导致在终端中正常工作的工具（如 brew、node）在其他场景下找不到。理解 login 和 interactive 标志是定位环境问题的关键。
tmux 环境继承的复杂性
tmux 的环境继承分为三层：server 本体、新窗口和带命令的 pane。server 的环境来自启动它的客户端，因此第一个启动 tmux 的进程决定了所有窗口的初始环境。带命令的 pane 只读取 .zshenv，且 PATH 可能来自发命令的进程而非 server，这常导致守护进程通过 tmux 启动的 CLI 工具环境异常。
CLI 工具的环境依赖
像 fnm、nvm 等版本管理工具依赖 shell 钩子，在非交互场景下不会生效。而 npm run 和 Claude Code 的 Bash 工具会启动子 shell，但环境仍继承自父进程。因此，工具能否找到依赖，取决于其启动进程的环境，而非用户当前 shell 的配置。
配置建议：以 .zshenv 为统一入口
文章建议将 PATH 和密钥等环境变量放在 .zshenv 中，因为它是唯一在所有 zsh 场景下都会读取的文件（除 launchd 外）。对于 launchd 服务，需在 plist 中显式设置环境变量或通过 zsh -c 启动。这样能确保不同场景下环境一致，减少“终端有、别处无”的问题。
Q&A
为什么在SSH进入tmux后，Claude Code找不到node和brew？
因为Claude Code不读.zshrc，它只继承启动它的进程的环境。在SSH进入tmux的场景中，启动Claude Code的进程环境可能不包含node和brew的路径，而这些路径通常配置在.zshrc中，但.zshrc只在交互式shell中读取，SSH命令或tmux的某些启动方式不会读取它。
zsh启动文件的读取顺序是什么？
zsh启动文件读取顺序为：首先读取/etc/zshenv和~/.zshenv（永远读取），如果是登录shell则读取/etc/zprofile和~/.zprofile，如果是交互式shell则读取/etc/zshrc和~/.zshrc，最后如果是登录shell则读取/etc/zlogin和~/.zlogin。
在macOS的终端、SSH、launchd、tmux等场景下，zsh分别读取哪些启动文件？
在macOS终端新标签中，zsh作为登录交互式shell，读取所有八个文件；SSH交互登录也读取所有八个文件；SSH执行命令（如ssh host command）时，zsh以非登录非交互方式运行，只读取.zshenv；launchd服务不经过shell，不读取任何启动文件；tmux新窗口启动zsh时读取所有八个文件，但带命令的pane（如new-session 'cmd'）只读取.zshenv。
为什么在非交互SSH命令中cargo可用而brew不可用？
因为cargo的路径被添加到了~/.zshenv中，而.zshenv在非交互SSH命令中会被读取；而Homebrew的路径通常按照官方指引配置在.zprofile中，但.zprofile只在登录shell中读取，非交互SSH命令不会读取它，所以brew不可用。
launchd服务如何设置环境变量？
launchd服务不读取任何shell启动文件，因此需要在plist文件中通过EnvironmentVariables键显式设置环境变量，或者将服务入口改为/bin/zsh -c 'exec ...'，使其经过zsh并读取.zshenv。
如何解决tmux中环境变量不一致的问题？
tmux server的环境来自启动它的客户端，因此第一个启动tmux的进程决定了所有窗口的初始环境。如果从launchd启动tmux，则所有窗口只有最简环境。建议将PATH等环境变量配置在.zshenv中，因为tmux新窗口和带命令的pane都会读取.zshenv（除了launchd直接启动的情况）。另外，从tmux外部发送命令时，pane的PATH可能来自发命令的进程，需要注意。
为什么在launchd服务中找不到fnm、nvm等工具？
因为fnm、nvm等工具依赖shell钩子（如eval "$(fnm env)"）在交互式shell启动时执行，而launchd服务不经过shell，所以这些钩子不会运行，导致工具不可用。解决方法是将工具的固定路径（如fnm的别名路径）添加到.zshenv中，或使用direnv exec等显式方式。
如何验证.zshenv中的配置在最简环境下是否有效？
可以使用命令：env -i HOME=$HOME PATH=/usr/bin:/bin zsh -c 'command -v node' 来模拟最简环境，检查node是否可找到。另外，也可以模拟守护进程启动tmux，使用env -i HOME=$HOME PATH=/usr/bin:/bin "$(command -v tmux)" -L probe new-session -d 'print -r -- $PATH > ~/probe.txt' 来检查pane中的PATH。
