环境变量修改不生效主因是未重载配置或未作用到当前shell；需source ~/.bashrc或新开终端，/etc/environment仅登录时由pam加载，不同shell读取不同配置文件，path重复追加易致命令冲突，systemd用户服务需显式声明environment。
环境变量为什么改了不生效？
改完 ~/.bashrc 或 /etc/environment 后，echo $PATH 还是老样子——不是配置写错了，大概率是没重载或没作用到当前 shell。Shell 启动时只读一次配置文件，后续修改必须手动触发加载，或者新开终端。
-
source ~/.bashrc是最常用方式，但仅对当前 shell 有效；子进程（比如你从终端里启动的 VS Code）不一定继承它 -
/etc/environment是 PAM 系统级配置，只在登录 shell（如图形界面登录、SSH 登录）时由pam_env.so加载，source它完全无效 - 用
export VAR=value临时设置的变量，退出 shell 就消失；想持久化，必须写进对应配置文件且确保该文件被正确加载
不同 shell 用哪个配置文件？
不是所有 shell 都读 ~/.bashrc。你执行 sh、zsh 或脚本时，加载逻辑完全不同，硬塞变量进去可能白忙活。
-
bash登录 shell：读/etc/profile→~/.bash_profile（存在则跳过~/.bash_login和~/.profile） -
bash非登录 shell（比如终端里敲bash）：只读~/.bashrc—— 所以 GUI 终端默认走这里 -
zsh：优先读~/.zshrc，登录时还可能读~/.zprofile；~/.bashrc对它完全没用 - 纯 POSIX
sh脚本：不读任何用户配置，只认#!/bin/sh上下文里的export
PATH 重复追加导致命令冲突
常见操作：export PATH="$PATH:/my/tool" 写进 ~/.bashrc，每次开新终端都执行一遍，PATH 里就堆出一串重复路径。结果可能是 which python 返回错的版本，或 command -v 行为异常。
- 检查是否已存在：
[[ ":$PATH:" != *":/my/tool:"* ]] && export PATH="/my/tool:$PATH" - 更稳妥的做法是统一用
~/.profile设置 PATH（登录 shell 只加载一次），再让~/.bashrcsource ~/.profile（前提是它不带交互逻辑） - 别在循环或 alias 里动态改 PATH，shell 函数调用时也容易意外叠加
systemd 用户服务看不到你的环境变量
用 systemctl --user start myapp 启动的服务，根本不会读 ~/.bashrc 或 ~/.profile。systemd 用户实例有自己的环境初始化机制，和终端 shell 完全隔离。
- 用户级服务默认只继承 minimal 环境（
LANG、HOME等几个基础变量），PATH 是/usr/local/bin:/usr/bin:/bin - 在 service 文件里显式声明：
Environment="PATH=/my/tool:$PATH"，或用EnvironmentFile=/home/user/.env引入变量文件 -
systemctl --user import-environment可以把当前 shell 的部分变量导入 systemd 用户 session，但只对之后启动的服务生效，已运行的服务不受影响
环境变量不是“写进去就全局可用”的魔法开关，它的传播路径依赖 shell 类型、启动方式、进程父子关系，还有 systemd 这类独立 init 系统的规则。最容易漏掉的是：你在终端里验证成功的配置，在 cron、GUI 应用、systemd 服务甚至 ssh 命令中很可能根本没加载。
