Zsh vs Bash 的配置檔載入順序

理解配置檔的載入順序是結構化拆分的前提。不知道哪個檔案在什麼時機被讀取，就無法判斷設定該放在哪。

Bash 的載入順序

Bash 區分 login shell 和 non-login shell，兩者讀取的檔案不同：

• Login shell（SSH 進來、bash --login）：讀 ~/.bash_profile（如果不存在，依序嘗試 ~/.bash_login → ~/.profile）
• Non-login interactive shell（開一個新終端機視窗）：讀 ~/.bashrc
• 常見做法：在 ~/.bash_profile 裡 source ~/.bashrc，確保設定不管怎麼進來都一致

Zsh 的載入順序

Zsh 的載入鏈比 Bash 更細緻：

1. ~/.zshenv — 每次都讀（login、non-login、script 都會），放環境變數
2. ~/.zprofile — 只有 login shell 讀，對應 Bash 的 ~/.bash_profile
3. ~/.zshrc — interactive shell 讀，放 alias、function、prompt、plugin
4. ~/.zlogin — login shell 在 .zshrc 之後讀（少用）
5. ~/.zlogout — logout 時讀（少用）

實務上 90% 的設定都進 .zshrc，環境變數（PATH、EDITOR）放 .zshenv。

結構化拆分：從單一巨檔到模組化

一個典型的失控 .zshrc 長這樣：PATH 設定、alias、function、plugin 載入、prompt 配置、各種工具的 eval/source 全混在一起，改一個東西要在五百行裡找位置。

模組化的目標是依職責拆檔，.zshrc 本身只負責 source 這些模組：

 1# ~/.zshrc — 只做 source，不放具體設定
 2
 3# 環境變數（PATH 在 .zshenv，這裡放其他 interactive 專用的）
 4source "$HOME/.config/zsh/env.zsh"
 5
 6# Alias
 7source "$HOME/.config/zsh/aliases.zsh"
 8
 9# Function
10source "$HOME/.config/zsh/functions.zsh"
11
12# Plugin manager
13source "$HOME/.config/zsh/plugins.zsh"
14
15# Prompt / theme
16source "$HOME/.config/zsh/prompt.zsh"
17
18# 工具整合（fzf, nvm, pyenv, etc.）
19source "$HOME/.config/zsh/tools.zsh"
20
21# 機器專屬設定（不進 Git）
22[[ -f "$HOME/.config/zsh/local.zsh" ]] && source "$HOME/.config/zsh/local.zsh"

各模組的職責

aliases.zsh — 短指令對映

 1# 檔案操作
 2alias ll='ls -alF'
 3alias la='ls -A'
 4
 5# Git 常用
 6alias gs='git status'
 7alias gd='git diff'
 8alias gco='git checkout'
 9alias gp='git push'
10
11# 導航
12alias ..='cd ..'
13alias ...='cd ../..'

判讀準則：alias 適合「不帶參數的簡單替換」。如果需要參數處理或條件判斷，改用 function。

functions.zsh — 帶邏輯的常用操作

1# 建目錄並進入
2mkcd() {
3    mkdir -p "$1" && cd "$1"
4}
5
6# 在 Git repo 根目錄搜尋
7ggrep() {
8    git grep "$@" "$(git rev-parse --show-toplevel)"
9}

tools.zsh — 第三方工具的初始化

1# fzf
2[[ -f ~/.fzf.zsh ]] && source ~/.fzf.zsh
3
4# nvm
5export NVM_DIR="$HOME/.nvm"
6[[ -s "$NVM_DIR/nvm.sh" ]] && source "$NVM_DIR/nvm.sh"
7
8# pyenv
9command -v pyenv >/dev/null && eval "$(pyenv init -)"

每個工具的 init 前面加存在性檢查（command -v 或 [[ -f ]]），避免在沒裝該工具的機器上報錯。

local.zsh — 機器專屬、不進 Git

1# 公司 VPN 設定
2export CORP_PROXY="http://proxy.corp:8080"
3
4# 只有這台機器需要的 PATH
5export PATH="$HOME/corp-tools/bin:$PATH"

在 dotfile repo 的 .gitignore 裡排除這個檔案。.zshrc 裡用 [[ -f ... ]] && source 確保不存在也不報錯。

PATH 管理

PATH 是最容易腐化的環境變數——每裝一個工具就加一條，最後 PATH 變成一長串看不懂的路徑，順序還會互相影響。

管理原則：

• PATH 設定集中在一個地方（.zshenv 或 env.zsh），不散落在多個檔案
• 新增前先想：這個路徑是所有機器都需要、還是特定機器才需要？共用的進 env.zsh，特定的進 local.zsh
• 用 typeset -U PATH (Zsh) 自動去除重複項目，避免多次 source 導致 PATH 不斷加長

1# ~/.config/zsh/env.zsh
2typeset -U PATH  # 去重
3
4# 自己的 script
5export PATH="$HOME/.local/bin:$PATH"
6export PATH="$HOME/bin:$PATH"

Plugin Manager 選型

Zsh plugin manager 的選擇很多，差異主要在載入速度和功能豐富度：

• 無 plugin manager：直接 git clone plugin 到某個目錄，手動 source。最簡單、最透明、但更新要自己管
• zinit（原 zplugin）：載入速度最快（turbo mode 延遲載入）、功能最多、但配置語法學習曲線高
• antidote：宣告式（一個 .zsh_plugins.txt 列出所有 plugin），概念簡單
• sheldon：Rust 寫的、速度快、設定用 TOML

常用 plugin：

• zsh-autosuggestions：根據歷史指令自動補全建議（灰色字，按右箭頭接受）
• zsh-syntax-highlighting：指令行即時語法高亮
• zsh-completions：額外的 tab 補全定義

Prompt 設計

Prompt 是每次按 Enter 都會看到的東西，值得花時間設計但不需要複雜。

基本款（不用框架）：

1# 顯示目錄 + git branch
2autoload -Uz vcs_info
3precmd() { vcs_info }
4zstyle ':vcs_info:git:*' formats ' (%b)'
5PROMPT='%F{blue}%~%f%F{green}${vcs_info_msg_0_}%f %# '

框架款：Starship（跨 shell、用 TOML 設定、Rust 寫的速度快）是目前最常被推薦的 prompt 工具。它的配置進 ~/.config/starship.toml，也是 dotfile 的一部分。

Dotfile 結構對應

管理工具與目錄結構裡的 stow 目錄結構，shell 配置的對應：

 1~/dotfiles/
 2└── zsh/
 3    ├── .zshenv
 4    ├── .zshrc
 5    └── .config/
 6        └── zsh/
 7            ├── aliases.zsh
 8            ├── functions.zsh
 9            ├── plugins.zsh
10            ├── prompt.zsh
11            ├── tools.zsh
12            └── env.zsh

stow zsh 會在家目錄建立 .zshenv 和 .zshrc 的 symlink，在 .config/zsh/ 下建立各模組檔案的 symlink。local.zsh 不在 repo 裡，各機器自己建。

章節文章

跨分類引用

• → 模組一：管理策略：stow 的 package 概念怎麼對應 shell 配置的目錄結構
• → 模組一：跨平台共用一個 Repo：path.zsh 和 tools.zsh 裡的 OS 分流做法
• → 模組三：終端機與編輯器：terminal emulator 的配色跟 shell prompt 的配色協調