当前Shell是否读取~/.bashrc取决于是否为登录shell：登录shell（如shopt login_shell显示on或$0为-bash）优先加载~/.bash_profile或~/.profile，若其中未source ~/.bashrc则不生效；非登录shell才自动加载~/.bashrc。
确认当前 Shell 是否真在读 ~/.bashrc
很多用户改完 ~/.bashrc 并执行 source ~/.bashrc，以为万事大吉，但新开终端仍不生效——根本原因是：图形界面终端（如 GNOME Terminal、Konsole）默认启动的是非登录式 shell，确实会自动加载 ~/.bashrc；但如果你的系统里存在 ~/.bash_profile 或 ~/.profile，且其中没有显式 source ~/.bashrc，那么某些桌面环境或 SSH 登录时走的是登录 shell 路径，~/.bashrc 就被跳过了。
验证方法：
- 运行
shopt login_shell，输出login_shell on表示当前是登录 shell，不会自动加载~/.bashrc - 运行
echo $0，若显示-bash（开头带短横），大概率是登录 shell - 在
~/.bashrc末尾加一行echo "Loaded .bashrc"，新开终端看有没有这行输出
检查 ~/.bash_profile 或 ~/.profile 是否覆盖 PATH
~/.bash_profile 或 ~/.profile 中如果出现形如 PATh="/new/path"（没带 $PATH）的赋值，就会清空原有路径，导致你加在 ~/.bashrc 里的 export PATH=$PATH:/my/bin 完全失效——因为登录 shell 先加载了那个全量覆盖的 PATH，后续 ~/.bashrc 根本没机会执行，或者执行了但已晚于变量定义时机。
常见错误写法：
-
export PATH="/usr/local/bin:/opt/myapp/bin"→ 覆盖全部，丢弃系统默认路径 -
PATH="/opt/myapp/bin:$PATH"→ 缺少export，变量不导出给子进程 -
export PATH=$PATH:/opt/myapp/bin→ 如果前面有语法错误（比如引号不闭合），整行会被跳过
注意 /etc/environment 不支持变量展开
有些用户试图在 /etc/environment 里写 PATh="/usr/local/bin:$PATH"，结果发现新登录后 $PATH 字面量没展开，反而让 PATH 变成包含字符串 $PATH 的非法值。这是设计限制：/etc/environment 由 PAM 模块直接加载，不经过 shell 解析，只认 KEY=VALUE 硬编码格式。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
正确写法只能是：
-
PATH="/usr/local/bin:/opt/myapp/bin:/usr/bin:/bin"（所有路径必须绝对、完整、无变量） - 不能用
$HOME、$PATH、$(which xxx)等任何 shell 特性 - 该文件对 systemd 用户服务、GUI 应用生效，但和
~/.bashrc无关，别混用
systemd 用户服务和 GUI 程序压根不读 ~/.bashrc
VS Code、JetBrains IDE、或你自己写的 systemctl --user start myapp 服务，都不会执行 ~/.bashrc。它们要么继承桌面会话环境（来自 ~/.profile 或 /etc/environment），要么完全绕过 shell 初始化流程。
所以即使 ~/.bashrc 在终端里工作完美，这些场景下依然找不到命令或读不到变量。解决方案不是硬塞进 ~/.bashrc，而是：
- GUI 应用：把 PATH 或其他变量写进
~/.profile，并确保桌面环境登录时加载它 - systemd 用户服务：在
.service文件中用Environment=PATH=/opt/myapp/bin:$PATH（注意：这里$PATH是 systemd 支持的变量展开，不是 shell 的） - 或使用
~/.config/environment.d/*.conf（systemd 249+），例如myapp.conf写MYAPP_HOME=/opt/myapp
最常被忽略的一点：改完 ~/.profile 后，必须完全退出桌面会话（不是关终端，是登出重进），否则 GUI 程序仍用旧环境。
