bash 启动时按登录/非登录、交互/非交互组合加载配置文件：登录 shell 读 /etc/profile → ~/.profile 或 ~/.bash_profile，非登录交互式 shell 只读 ~/.bashrc；脚本默认不读任何配置，需显式 source。
bash 配置文件加载顺序搞不清？先看这 4 个文件谁生效
你改了 ~/.bashrc 却发现新终端没反应，或者加了 export PATH 在脚本里不生效——大概率是搞错了 bash 启动时到底读哪个配置文件。
bash 分「登录 shell」和「非登录 shell」，还分「交互式」和「非交互式」，组合起来决定加载哪几个文件。实际开发中最常踩坑的是：以为所有终端都走 ~/.bashrc，其实 GUI 终端（如 GNOME Terminal）默认启的是「非登录 + 交互式」shell，只读 ~/.bashrc；而 SSH 登录、bash -l 这类才是「登录 shell」，优先读 /etc/profile → ~/.profile（或 ~/.bash_profile），再手动 source ~/.bashrc。
-
/etc/profile：系统级，所有用户登录时执行一次 -
~/.profile：用户级登录配置，Ubuntu 默认用它，不自动读~/.bashrc -
~/.bash_profile：同上，但某些发行版（如 CentOS）优先用它；如果存在，~/.profile就被跳过 -
~/.bashrc：仅非登录交互式 shell 加载（比如日常开的每个新终端），适合 alias、函数、PS1 等
为什么改了 ~/.bashrc 不生效？3 种常见失效场景
不是改错，而是没触发重载或没匹配到启动模式。
- 新开终端仍无效：确认该终端是否为「登录 shell」——运行
shopt login_shell，输出login_shell off表示是非登录 shell，应确保修改在~/.bashrc；若输出on，则要改~/.bash_profile并在里面加source ~/.bashrc - SSH 登录后命令找不到：因为 SSH 是登录 shell，只读
~/.bash_profile或~/.profile，PATH 修改必须放在这两个文件里，不能只放~/.bashrc - 脚本中环境变量丢失：bash 脚本默认是非交互 + 非登录 shell，完全不读任何
~/.xxx文件；要么显式source ~/.bashrc，要么用bash -i强制交互式（不推荐）
source ~/.bashrc 和 exec bash 有什么区别？别乱用
两者都能“刷新”当前 shell，但机制完全不同，选错会丢掉当前 shell 上下文。
-
source ~/.bashrc：在当前 shell 进程里重新执行文件内容，保留所有已定义变量、当前目录、job 状态；最安全，日常首选 -
exec bash：用新 bash 进程替换当前进程，旧 shell 彻底消失；会导致cd -历史清空、后台 job 断开、未保存的 shell 函数丢失 - 别用
bash（不带 exec）：会起子 shell，改完变量只在子 shell 里有效，退出就回退，容易误以为“没生效”
顺手记一句：source 等价于 .，所以 . ~/.bashrc 完全合法且更短。
PATH 重复追加、alias 覆盖、函数污染：这些隐性 bug 怎么防？
配置文件反复 source（比如 ~/.bash_profile 里 source ~/.bashrc，而 ~/.bashrc 又 source 自己）会导致 PATH 越叠越长、alias 被覆盖、函数重复定义——表面正常，实则浪费内存、引发诡异行为。
- PATH 去重追加：
export PATH="/new/path:$PATH"改成[[ ":$PATH:" != *":/new/path:"* ]] && export PATH="/new/path:$PATH" - alias 安全定义：加
unalias foo 2>/dev/null再alias foo='...'，避免重复报错 - 函数只定义一次：
if ! declare -f myfunc >/dev/null; then myfunc() { ... }; fi - 检查是否已被 source：
[[ "${BASH_SOURCE[0]}" == "${0}" ]] || return放在文件开头，防止被 source 两次
真正麻烦的不是写错，而是这些逻辑在不同 shell 启动路径下表现不一致——比如某次 CI 环境用 bash -c 执行，PATH 就莫名多出三遍 /usr/local/bin，查半天才发现是 ~/.profile 和 ~/.bashrc 都追加了同一段。
