改了 ~/.bashrc 不生效是因为它仅被交互式非登录 shell 自动加载，而 ssh、桌面终端等 login shell 优先读 ~/.profile；需在 ~/.profile 中显式 source ~/.bashrc 才能生效。
为什么改了 ~/.bashrc 还是不生效
因为 ~/.bashrc 只在「交互式非登录 shell」里自动加载，比如你点开 GNOME 终端、iTerm2，或者执行 bash 启动子 shell。但 SSH 登录、桌面环境首次启动的终端、sudo -i 切换用户——这些都触发的是 login shell，优先读 ~/.profile 或 ~/.bash_profile，压根不碰 ~/.bashrc。
常见现象：你在 ~/.bashrc 里加了 export PATH="/opt/mytool/bin:$PATH"，新开一个终端能用，但 VS Code 里打开的集成终端、SSH 上去后却找不到命令。
- 先确认当前 shell 类型：
echo $SHELL，是/bin/bash还是/bin/zsh - 如果是 bash，检查
~/.profile是否已source ~/.bashrc：grep "source.*bashrc" ~/.profile - 没找到？就手动加一行：
if [ -f ~/.bashrc ]; then source ~/.bashrc; fi（注意空格和分号） - 别直接复制粘贴到
~/.bash_profile——某些发行版会跳过它，只认~/.profile
/etc/environment 里写 $PATH 为什么报错
/etc/environment 是 PAM 直接读取的纯文本文件，不经过 shell 解析，所以不支持任何变量展开、命令替换或 export 关键字。写 PATH="/usr/local/bin:$PATH" 会被当成字面量，$PATH 不会被展开，结果就是 PATH 被设成带美元符的字符串，后续所有命令基本瘫痪。
- 正确写法只有：
PATH="/usr/local/bin:/opt/myapp/bin:/usr/bin:/bin"（全路径、冒号分隔、双引号包裹） - 不能用
$HOME，不能拼接，不能条件判断 - 改完必须重新登录（不是重启终端，也不是
source），否则无效 - 适合加固系统基础路径，不适合日常追加；要动态拼接，就别选它
给所有用户加 PATH，为什么推荐 /etc/profile.d/ 而不是直接改 /etc/profile
直接改 /etc/profile 看似简单，但系统升级时可能被包管理器覆盖，多人协作时容易冲突。而 /etc/profile.d/ 下的 .sh 文件是被 /etc/profile 自动 source 的，天然解耦、易维护、易卸载。
- 新建文件：
sudo tee /etc/profile.d/mytools.sh export PATH="/opt/mytools/bin:$PATH"<br>EOF
- 确保权限：
sudo chmod 644 /etc/profile.d/mytools.sh - 不要用
$HOME—— 它在 root 下展开为/root，对普通用户无效；一律用绝对路径 - 新用户登录、新终端启动都会自动加载；删掉这个文件就等于卸载，不留痕迹
GUI 应用（如 VS Code、HBuilderX）里环境变量还是不对
图形界面应用通常由桌面环境（GNOME/KDE）启动，它们的环境变量继承自 display manager（如 gdm3），而 display manager 默认不读 ~/.bashrc，甚至不一定读 ~/.profile（取决于发行版和 session 类型）。这时候靠 shell 配置文件已经不够了。
- 最稳妥的做法：把关键变量写进
/etc/environment（静态路径）或/etc/profile.d/（支持拼接） - 如果只是个人开发，且用的是 GNOME，可尝试在
~/.profile末尾加：export MY_VAR="value"，并确保该文件被 display manager 加载（Ubuntu 22.04+ 一般支持） - HBuilderX 这类 Electron 应用尤其容易漏掉环境变量，启动前建议验证：
env | grep MY_VAR，而不是只信终端里的echo $MY_VAR - 脚本里要用环境变量？别依赖
~/.bashrc—— 非交互式 shell 默认不读它，要么显式source ~/.bashrc，要么把变量挪到系统级位置
