数字基带传输系统：从码间串扰到升余弦滚降的MATLAB仿真
2026/9/18 17:56:48
1. 先从一次JDK环境变量配置失败聊起
大约一个月前，同事兴冲冲地跑来告诉我，JDK 17 终于装好了，环境变量也配上了，java -version输出正常。我随口问了一句：“你是写进哪个文件了？”他说：“/etc/profile啊，教程里不都这么写的吗？然后source /etc/profile。”我让他关掉终端重新开一个再试一下，他敲完java -version，屏幕上直接提示command not found。
他当场愣住了：“我明明配了环境变量，为什么重启终端就失效？”
这句话我平均每个月都能听到一次。很多人对 Linux 环境变量的理解停留在“照着教程写几行到文件里，然后 source 一下”的层面，一旦遇到“改了不生效”“重启就丢”“只有某个终端能看到变量”这类问题，就完全不知道从哪排查。这其实不是因为 Linux 环境变量有多玄学，而是因为整个机制里有三个关键点经常被跳过：配置文件加载顺序、登录 shell 和非登录 shell 的区别、以及export 的“单向传递”特性。
这篇文章不打算讲那种“复制粘贴即可”的傻瓜教程，而是想把你拉到环境变量的底层逻辑上，把全局环境变量、局部环境变量、PATH 环境变量、数组变量这几个东西一次讲透。看完之后你会发现，那些网上流传的“配置失败”案例，基本都能自己定位了。
2. 环境变量的底层逻辑：局部与全局的边界在哪里
2.1 shell变量和环境变量，差的是一个export
很多初学者刚接触环境变量时，会有一个误解：以为在终端里执行FOO=bar就是把环境变量设置好了。实际上，你只是定义了一个shell 变量，它只存在于当前这个 bash 进程里，既不会被子进程继承，也不会被其他终端看到。想要让它变成真正的环境变量，必须执行export FOO=bar。
这里有个很实用的实验，你可以立刻在终端里验证：
# 终端1：定义一个Shell变量，不导出 FOO=hello # 同一个终端里能看到 echo $FOO # 输出 hello # 启动一个子shell bash # 子shell里打印，会发现FOO为空 echo $FOO # 输出空行更直观的验证方式是用env命令：
FOO=hello env | grep FOO # 没有输出，因为FOO还在shell变量里 export FOO env | grep FOO # 输出 FOO=helloexport干的事情，本质上是把这个变量标记为“需要传递给之后创建的子进程”。注意是“之后创建的”，如果你先启动了子进程，再在父 shell 里 export，这个子进程里永远看不到新增变量。这也是为什么在一个终端里 export 了变量，另一个开着的终端不受影响——每个终端是一个独立的进程树，环境变量只在创建子进程的那一刻被拷贝过去。
2.2 从父进程到子进程的单向继承
环境变量的传递是严格单向的：父进程创建子进程时，把自己的环境变量表复制一份交给子进程。子进程对这份拷贝做的任何修改，都无法回传给父进程。
这个概念听起来简单，但实际工作中经常有人踩坑。比如我以前看到过有人在脚本里写了这样一段：
# test.sh export MY_ENV=123 echo "脚本内设置了MY_ENV"然后在终端执行：
./test.sh echo $MY_ENV # 输出为空执行脚本的时候，./test.sh是启动了一个新的子进程，脚本里的export只是修改了子进程的环境变量表。脚本执行完，进程退出，修改就跟着消失了。想要让脚本的修改影响当前 shell，唯一的方式是用source或.来执行脚本，让脚本在当前 shell 进程内运行：
source ./test.sh echo $MY_ENV # 输出 123这就是为什么我们去修改~/.bashrc、/etc/profile之后，必须重新登录或者手动source才能生效——因为那些文件里的 export 需要在当前 shell 进程里重新执行一遍，才会更新当前进程的环境变量表。
2.3 所谓的“全局”，其实只在进程树中成立
英文里环境变量经常被分成global environment variable和local environment variable，中文翻译成“全局”和“局部”。这个翻译其实有误导性。它并不是编程语言里那种“整个系统全局可见”的概念，而是针对当前进程树来说的。
一个变量被 export 之后，它对这个 shell 以及它下面创建的所有子孙进程都是可见的，看起来像“全局”。但只要走到这个进程树之外，它就是不可见的。你在这个终端导出的变量，另一个终端永远看不到；你在用户 A 登录会话里导出的变量，用户 B 登录之后也看不到。真正能做到“所有用户、所有会话”可见的，只有写在系统级配置里的变量，而且必须是在会话初始化阶段被加载。
所以我想强调一个判断方法：当你说“我要配置一个全局环境变量”时，先问自己三个问题：
- 这个变量需要给哪些用户用？当前用户，还是所有用户？
- 需要给登录 shell 用，还是包括非登录 shell？
- 是永久生效，还是临时在当前会话里用一下？
这三个问题的答案，基本就决定了你该把变量写进哪个文件，或者需不需要 export。后面第五章我会详细展开配置文件的选择。
3. PATH变量拆解：命令查找的完整链路与修改姿势
3.1 当你敲下ls时，系统到底做了什么
PATH 是 Linux 环境变量里最特殊、也最常用的一个。它不是某个软件需要的配置，而是 shell 用来定位命令的查找路径。你可以把它理解成一张“门牌号列表”：当你在终端输入一个命令名时，shell 会按照 PATH 里目录的先后顺序，依次去这些目录里找对应的可执行文件。
echo $PATH输出可能是这样的：
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin当你敲ls，shell 先看/usr/local/sbin/ls是否存在，不存在；再看/usr/local/bin/ls，不存在；继续往后找，直到在/usr/bin/ls或/bin/ls里找到，然后执行它。如果所有目录都找不到，就会提示command not found。
这也解释了另一个常见问题：为什么你明明安装了某个软件，却提示找不到命令。要么是安装目录不在 PATH 里，要么是你安装的命令名字和默认查找的路径不一致。
还有一个很容易被忽略的点：shell 会缓存命令的查找结果，缓存在一个叫 hash 表的东西里。你用which ls找到的是/usr/bin/ls，shell 记住之后，下次直接从这个路径执行。如果你把新的可执行文件放到了 PATH 更靠前的目录，shell 可能还记着老位置。遇到这种“明明加了路径，重启也重启了，还是执行老版本”的情况，执行一下hash -r清空缓存，往往就好了。
3.2 修改 PATH 的几种方式，以及各自的生效范围
改 PATH 本质上就是重新给 PATH 这个变量赋值。最常见的需求是“追加一个新目录，同时保留原有内容”，写法是：
export PATH=$PATH:/opt/mytool/bin这句话的意思是把原 PATH 的值取出来，加上冒号，再接上/opt/mytool/bin，重新赋值给 PATH，并导出。这里的冒号是 PATH 列表的分隔符，和ls -l输出里的冒号没有半点关系。
根据生效范围不同，修改方式可以分成四类，它们之间的区别我用一个表总结：
| 写法 | 生效范围 | 是否永久 | 适用场景 |
|---|---|---|---|
export PATH=/opt/bin:$PATH | 当前 shell 及子进程 | 否，关闭终端失效 | 临时测试某个工具 |
FOO=bar command | 仅这一次命令 | 否 | 给单个命令传环境变量 |
写入~/.bashrc | 当前用户所有交互 shell | 是 | 个人常用工具路径 |
写入/etc/profile或/etc/environment | 所有用户登录会话 | 是 | 系统级安装的软件路径 |
这里特别想提醒一点：很多教程喜欢让新手把路径追加到 PATH 末尾，但我个人的习惯是，如果我希望某个目录里的命令优先于系统命令，就放到最前面，比如export PATH=/opt/mytool/bin:$PATH；如果只是希望系统找不到的时候才去这个目录找，就放到最后面，比如export PATH=$PATH:/opt/mytool/bin。这个顺序在你想“覆盖系统自带版本”的时候非常关键。
3.3 追加 PATH 时最常见的三个坑
第一个坑：重复追加。每次 source 一次~/.bashrc，都会往 PATH 里多追加一份。多 source 几次之后，echo $PATH会看到一连串重复的路径。虽然一般不影响功能，但会让排查问题变得很痛苦。如果你发现自己 PATH 里同一个目录出现了三五遍，大概率是这个原因。
第二个坑：用相对路径。export PATH=./bin:$PATH看起来是加了一个相对路径，但 PATH 里的相对路径是相对于“当前工作目录”解析的。你在这个目录下命令能执行，换一个目录就全部失效了。更危险的是，如果 PATH 里有一个空字符串的项（比如PATH=:/usr/bin:/bin），它等价于“把当前目录加入查找范围”，如果你碰巧在一个被人放了恶意可执行文件的目录里敲ls，命中的可能不是系统那个ls，而是当前目录下的同名文件。所以在任何涉及权限的机器上，我都不推荐把当前目录加进 PATH。
第三个坑：把 PATH 覆盖了。新手最容易犯的错误是直接写export PATH=/opt/jdk/bin，把原来那一长串路径全丢了。命令倒是能执行，前提是你只敲绝对路径——因为这时候连ls、find都找不到了。一旦你登录之后发现“所有命令都消失了”，不用慌，用/bin/echo $PATH、/bin/ls这种绝对路径方式临时调用命令，把 PATH 修复回去就行。
4. 数组变量：环境变量家族里最不受重视的工具
4.1 数组的声明、追加和遍历
聊环境变量的时候，很少有人会把数组变量扯进来，但 bash 里数组确实是个非常趁手的变量类型，尤其是写脚本处理一组路径、一组 IP、一组文件名的时候。声明一个数组很简单：
# 用空格分隔元素 server_list=(192.168.1.1 192.168.1.2 192.168.1.3) # 取出第0个元素（注意bash数组下标从0开始） echo ${server_list[0]} # 取出所有元素 echo ${server_list[@]} # 追加元素 server_list+=(192.168.1.4) # 遍历数组 for ip in "${server_list[@]}"; do ping -c 1 "$ip" >/dev/null 2>&1 && echo "$ip is up" || echo "$ip is down" done这段代码里值得抠一下的是${server_list[@]}外面那个双引号。如果你不加引号，数组元素里有空格或特殊字符时会被 shell 重新分词；加了双引号，才能保证每个元素作为一个整体被传入循环。这一点在处理文件名时尤其重要，比如：
file_list=("my document.txt" "report final.doc") for f in "${file_list[@]}"; do echo "处理: $f" done如果不写双引号，my document.txt会被拆成my和document.txt两个元素，程序就乱了。
4.2 数组到底能不能导出为环境变量
这个问题我查过不少次，也做过实验。答案是可以导出，但跨进程传递之后，行为可能和你预期不太一样。在 bash 里执行export arr之后，子 shell 中确实能看到这个变量，但它在环境变量表里被存成了字符串形式，和普通变量一样：
arr=(a b c) export arr bash -c 'echo ${arr[0]}'在一些 bash 版本里能正常输出a，在另一些版本或 dash 里可能根本报错。这主要是因为环境变量本质上是一张“字符串键值对表”，数组本身并不是 POSIX 标准里的类型。所以我的建议是：不要依赖“导出数组”这个特性。
如果你真的需要把一组数据传给子进程，更稳的做法是折成字符串，到子进程里再还原：
# 父进程：把数组转成冒号分隔的字符串 export SERVER_LIST="192.168.1.1:192.168.1.2:192.168.1.3" # 子进程脚本里：按冒号拆分还原 IFS=':' read -r -a server_array <<< "$SERVER_LIST" for ip in "${server_array[@]}"; do echo "目标: $ip" done这种折字符串的方式，还能规避“环境变量值里包含换行符”引发的各种怪问题。Linux 环境变量的值可以包含空格、下划线、数字，但不建议把换行符放进环境变量里，很多程序解析环境变量时根本没考虑过换行符的存在。
4.3 使用数组处理脚本参数的真实场景
数组在实际脚本里还有一个常见用法，就是处理位置参数。你把所有参数收集到一个数组里，再配合shift逐个消费。比如我写过一个批量部署脚本的开头：
# 把脚本的所有参数放到数组里 args=("$@") # 第0个参数就是脚本名 echo "脚本名: ${args[0]}"更常见的场景是配合shift做参数解析：
while [ $# -gt 0 ]; do case "$1" in -h|--host) host="$2" shift 2 ;; -v|--verbose) verbose=1 shift ;; *) echo "未知参数: $1" exit 1 ;; esac done这里$@在 bash 里其实就是一个“位置参数数组”，只是它的下标从 1 开始，$0是脚本名。搞清楚这一点之后，你再看很多 shell 脚本里的“魔法”，就不会觉得费解了。
5. 配置文件加载顺序，以及“改了不生效”的完整排查链路
5.1 登录shell、非登录shell读的文件不一样
回到开头同事的问题：为什么写进/etc/profile之后，新开的终端里java依然找不见？因为 Linux 的 shell 分成了好几种形态，每种形态启动时加载的配置文件不一样。常见的情况里，一个用户打开终端，绝大多数时候得到的是一个“交互式非登录 shell”，它启动时不会读/etc/profile，而是去读当前用户家目录下的~/.bashrc。
这里把最常见的 Ubuntu、CentOS 系列 bash 行为整理一下：
| Shell 类型 | 启动时主要加载的文件 |
|---|---|
| 交互式登录 shell | /etc/profile，然后按顺序读~/.bash_profile、~/.bash_login、~/.profile，读到一个就停 |
| 交互式非登录 shell | /etc/bash.bashrc（有的发行版），然后读~/.bashrc |
| 非交互 shell（脚本） | 读取$BASH_ENV指定的文件，未设置就不读 |
所以在/etc/profile里配了 JAVA_HOME，你执行ssh user@host这种登录式会话能看到，但双击打开一个图形终端，不一定会看到。正确做法是把用户级别的环境变量写进~/.bashrc，如果要系统级生效，写/etc/profile之余还得确认你的终端是不是登录 shell。
另一个常见的坑是：很多人在~/.bash_profile里配了环境变量，但新建终端时根本不会加载这个文件。我见过一个特别典型的案例：用户把 JAVA_HOME 写进了~/.bash_profile，用 IDE 启动终端时能识别 Java，直接开系统终端时却不行。原因就是 IDE 的终端模拟器启动的是非登录 shell，不读~/.bash_profile。我通常建议“用户级环境变量优先写~/.bashrc”，因为它覆盖的场景更广。
5.2 不要忽略/etc/environment和其他底层入口
除了上面那几个文件，还有一个很多人不太熟的：/etc/environment。它不是 shell 脚本，而是一个简朴的“键=值”文件，由 PAM 在用户登录时读取并写入进程环境。它不执行命令、不支持 shell 变量展开，但对于设置那种“整个系统从登录一开始就要看见”的变量很合适。不过它也有一些限制，比如不推荐在里面写含有动态命令替换的内容。
另外还有个容易被忽略的细节：~/.profile和~/.bash_profile能不能加载~/.bashrc，取决于文件里有没有显式写source ~/.bashrc。某些发行版的默认~/.profile里带了这段逻辑，某些没有。所以你在~/.bashrc里加的东西，登录 shell 里看不到，很可能是你的~/.profile或~/.bash_profile里根本没有触发对~/.bashrc的加载。排查的时候别盯着一个文件看，要沿着执行链一路看下去。
5.3 一条完整的排查链路
我现在遇到环境变量不生效的问题，基本按照下面这条链路走，一般都能定位：
- 确认变量在当前 shell 里有没有值：
echo $JAVA_HOME。 - 查看它是怎么进来的：
type -a java可以看到命令解析路径；env | grep JAVA查看环境变量表。 - 判断当前 shell 类型：
echo $0如果输出的是-bash，表示登录 shell；如果是bash，表示非登录 shell。 - 模拟重新读取配置文件：
bash -l开一个登录 shell 验证，再bash开一个普通子 shell 验证。 - 分开排查系统配置和用户配置：先
grep -n JAVA /etc/profile /etc/environment，再看~/.bashrc、~/.profile。 - 注意文件的读取顺序：如果同一个变量在多个文件里被赋值，后执行的覆盖先执行的。例如
~/.bashrc里的 export 会覆盖~/.profile里先加载的值。
有一次我帮别人排查一个奇怪的“环境变量时有时无”的问题，最后发现是他的~/.bash_profile里先 source 了~/.bashrc，而~/.bashrc里又有[ -z "$PS1" ] && return这种针对非交互 shell 的短路逻辑，导致某些场景下加载就被截断了。这种问题不看执行链，单纯搜配置是搜不出来的。
6. 脚本里的环境变量工程化实践与我的避坑习惯
6.1 临时修改环境变量的三种正确姿势
写脚本时经常要临时改变环境变量，最常见的手段有三种。第一种是“脚本内部统一设置”，在脚本开头用 export 设置好，脚本结束自动废弃，不影响外部环境。第二种是“临时给单条命令设置环境变量”，语法是VAR=value command：
# 这条命令启动时能看到 MY_CONFIG，命令结束后环境变量消失 MY_CONFIG=/etc/myapp/config ./start.sh这种写法比“export 完再执行命令，最后 unset”要安全得多，不会污染当前 shell。第三种是用env命令显式指定环境变量，适合你想清除某个变量或者批量设置多个变量的场景：
env -i PATH=/usr/bin:/bin HOME=/root ./start.sh-i表示从空环境启动，把可控性拉到最满。在脚本里跑一些不太信任的程序时，我经常会用这种方式严格控制它能看到的变量。
6.2 带空格路径和特殊字符的处理
环境变量的值可以包含空格，但这不代表你在使用它的所有地方都得带引号。常见的问题是配置了一个带空格的路径，比如MY_HOME=/opt/My Softwares/App，然后在脚本里写cd $MY_HOME，shell 会把它拆成两个词，导致目录找不到。正确的写法是cd "$MY_HOME"。
还有一个很容易被忽略的点：环境变量名本身也有限制。POSIX 规范里环境变量名只能由字母、数字和下划线组成，而且不能以数字开头。你写export 123=abc大概率会报错，但写export MY-APP=abc在某些 shell 里可能不报错，实际却无法正常传给子进程，因为-会被当成减号操作符，产生很隐蔽的 bug。所以我给自己定了一条规矩：环境变量名一律用大写字母加下划线，比如MY_APP_HOME。
另外，命令替换$(...)的值里如果有空格，同样要用双引号包住。我在脚本里经常看到这样的写法：
# 错误示范：当前目录名如果有空格，目录就会不存在 export PROJECT_PATH=$(pwd)# 正确示范 export PROJECT_PATH="$(pwd)"6.3 环境变量管理的三个小技巧
最后分享几个我长期保留的环境变量操作习惯。
第一，用set -u防未定义变量。写 shell 脚本时，在开头加上set -u，任何引用到未定义变量的地方都会直接报错，而不是静默地当成空字符串。环境变量拼写错了，第一时间就能暴露出来，而不是等到程序运行到一半才报一个莫名其妙的错。
第二，用单独的配置文件承载复杂环境变量。当环境变量特别多、变量值特别长时，不建议全部堆在~/.bashrc里。我会写一个~/.env_custom，在里面做各种 export，然后在~/.bashrc里加一行source ~/.env_custom。这样改配置的时候只需要动一个文件，而且万一出问题，注释掉那一行就回到原样。
第三，修改重要变量之前先备份一行。尤其在调试 PATH 这类关键变量时，我会先把原始值输出到一个临时文件：
echo "$PATH" > /tmp/path_backup_$(date +%F).txt这看起来像多此一举，但真有几次我在调整 PATH 后把系统命令搞“丢”了，全靠这个备份恢复。给自己留后路的习惯，在 Linux 环境变量这个领域里，永远不会多余。
我在实际项目中见过太多环境变量配置问题，归根结底都不是某条命令背不下来，而是没搞懂环境变量的作用范围和加载链路。把“当前 shell”“子进程”“登录 shell 还是非登录 shell”这几点理解透了，遇到问题时按着链路去排查，比记住十个八个教程实在得多。