环境变量修改不生效主要因作用域和加载时机错误：需确认配置文件（如.bashrc或.zshrc）、手动source或重启终端，并注意export导出、path去重、不同环境（cron/systemd/gui）的独立性。
环境变量改了不生效？先看作用域和加载时机
改完 .bashrc 或 .profile 没反应，大概率是没重新加载，或者改错了文件。Shell 启动时只读一次配置，后续修改必须手动触发，或者新开终端。
-
source ~/.bashrc是最常用方式，但仅对当前 shell 有效；新打开的终端才读全局配置 - 登录 Shell（如 SSH 登录）读
/etc/profile→~/.profile；非登录 Shell（如终端里敲bash）默认只读~/.bashrc - 如果用的是
zsh，对应文件是~/.zshrc，不是.bashrc—— 混用会导致变量完全不加载 -
export PATH="/new/path:$PATH"要写在配置文件里，不能只在命令行执行后就以为“永久生效”
PATH 重复追加导致命令冲突或变慢
反复 source 同一个配置，PATH 会越叠越长，可能让旧版本命令被优先找到，甚至触发“command not found”却查不到原因。
- 避免无条件追加：
export PATH="/opt/mybin:$PATH"每次 source 都加一遍 - 改成带判断的写法：
[[ ":$PATH:" != *":/opt/mybin:"* ]] && export PATH="/opt/mybin:$PATH" - 用
echo $PATH | tr ':' '\n' | sort | uniq -c快速检查有没有重复路径 - 某些工具（如
pyenv、asdf）会动态插入 PATH，它们的初始化段落要放在配置文件末尾，否则可能被覆盖
不同用户、不同服务看到的环境变量不一样
root 和普通用户环境隔离；systemd 服务、cron job、GUI 应用（如从桌面启动的终端）各自有独立环境，不会自动继承你的 .bashrc。
Shell脚本编写基础 中文WORD版
下载
Shell本身是一个用C语言编写的程序，它是用户使用Linux的桥梁。Shell既是一种命令语言，又是一种程序设计语言。作为命令语言，它交互式地解释和执行用户输入的命令；作为程序设计语言，它定义了各种变量和参数，并提供了许多在高级语言中才具有的控制结构，包括循环和分支。它虽然不是Linux系统核心的一部分，但它调用了系统核心的大部分功能来执行程序、建立文件并以并行的方式协调各个程序的运行。因此，对于用户来说，shell是最重要的实用程序，深入了解和熟练掌握shell的特性极其使用方法，是用好Linux系统
- cron 执行脚本前几乎不加载任何用户配置，必须在 crontab 里显式
source ~/.bashrc或直接写全路径 - systemd 服务需在 unit 文件中用
Environment=或EnvironmentFile=显式声明，~/.bashrc完全无效 - GUI 环境（GNOME/KDE）通常只读
~/.profile，且只在登录时读一次；改完得注销重登，source没用 - 用
printenv或env查看实际生效的变量，别只信自己写的那行export
export 和不 export 的本质区别
不加 export 的变量只是当前 shell 的局部变量，子进程根本看不见 —— 这是绝大多数“脚本里用不了自定义变量”的根源。
-
MY_VAR="hello"：仅当前 shell 可用，./myscript.sh里$MY_VAR是空的 -
export MY_VAR="hello"：子进程（包括所有后续执行的命令、脚本）都能继承 - 导出变量名不能含
-或空格，export my-var=1会报错：bash: my-var=1: command not found - 敏感值（如 API key）尽量避免 export 到全局环境，尤其不要写进
.bashrc—— 任何子进程都能通过/proc/$PID/environ读到
环境变量不是“写进去就完事”，它像水流，有源头、有路径、有边界。漏掉加载时机、作用域或子进程继承规则中的任意一环，都会让变量消失得无声无息。
