环境变量覆盖由加载顺序决定，后加载文件中的同名变量会覆盖前面的值；用户级配置（如~/.bashrc）最常用且易生效，系统级文件（如/etc/profile）加载早、易被覆盖。
环境变量的优先级由加载顺序决定，不是“设置得越靠前越优先”
Linux 中环境变量没有全局统一的“优先级数值”，它的覆盖行为完全取决于 shell 启动时读取配置文件的先后顺序：后读取的文件中 export 的同名变量，会直接覆盖前面已定义的值。比如你在 ~/.bashrc 里写 export PATH=/a:$PATH，又在 ~/.bash_profile 里写 export PATH=/b:$PATH，最终生效的是后者——前提是它被加载且执行得更晚。
常见误区是以为“系统级 > 用户级”，其实恰恰相反：用户级配置（尤其是 ~/.bashrc）通常在每次新开终端时都会加载，而系统级的 /etc/profile 只在登录 shell 启动时读一次，且可能被用户文件覆盖。
-
~/.bashrc：交互式非登录 shell（如日常打开的 GNOME 终端）必读，**最常用、最易生效的位置** -
~/.bash_profile：仅登录 shell（如 SSH 登录、图形界面首次登录）读取；若存在，它常会主动source ~/.bashrc，否则两者互不影响 -
/etc/profile和/etc/environment：系统级，所有用户共享，但加载早、易被用户文件覆盖；/etc/environment不支持export或变量展开，只认KEY=VALUE格式 - 命令行直接
export VAR=value：**最高优先级**，仅当前 shell 及其子进程可见，关窗即丢
为什么 source ~/.bashrc 后 echo $PATH 没变？
这通常不是优先级问题，而是加载时机或语法错误导致变量根本没被设进去。最常见原因：
- 写错了变量名，比如把
PATH拼成PATHH或大小写混用（path≠PATH） - 漏了
export，只写了PATH=$PATH:/my/bin—— 这只是 shell 变量，不会传给子进程 - 路径拼接用了单引号：
export PATH='$PATH:/my/bin'，导致$PATH不展开 -
~/.bashrc被其他逻辑跳过：某些发行版（如 Ubuntu）的默认~/.bashrc开头有[ -n "$PS1" ] || return，在非交互式 shell 中直接退出，不执行后续
验证是否真生效：运行 grep -n "export.*PATH" ~/.bashrc 看语句是否存在且未被注释；再执行 set | grep "^PATH="，确认输出里包含你加的路径。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
如何安全追加 PATH 而不破坏原有值？
直接覆盖 PATH=... 是高危操作，会导致 ls、cd 等基础命令找不到。必须保留原值并拼接：
- 正确写法：
export PATH="$PATH:/home/user/myapp/bin"（推荐双引号，防空格路径出错） - 避免写成：
export PATH="/home/user/myapp/bin:$PATH"—— 虽然语法合法，但会把自定义路径放在最前，可能意外屏蔽系统命令（比如你本地编译了个python放 bin 下，就可能绕过系统 Python） - 如果要确保某路径一定在最前（如调试用的 mock 工具），用
export PATH="/tmp/mockbin:$PATH"，但务必清楚后果 - 临时测试可用：
PATH="/tmp/testbin:$PATH" command，只影响单条命令，不污染当前环境
systemd 服务或 crontab 里环境变量为啥不生效？
因为它们不走你的 ~/.bashrc。systemd 服务默认只有极简环境（PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin），crontab 也类似。
- systemd：在 service 文件的
[Service]段用Environment="PATH=/usr/local/bin:/usr/bin:/bin:/my/app/bin"显式覆盖，或用EnvironmentFile=/path/to/env.conf - cron：在 crontab 条目开头直接写环境变量，例如：
PATH=/usr/local/bin:/usr/bin:/bin:/my/app/bin * * * * * /my/app/script.sh - 切勿依赖
source ~/.bashrc—— cron 默认用/bin/sh，不一定支持 bash 特性，且~在非交互环境下可能解析失败
真正容易被忽略的点：不同场景下 shell 类型不同（bash/zsh/sh），加载的初始化文件完全不同；不要假设“我在终端里能跑，服务里就一定能”。验证方式永远是，在目标上下文里直接运行 printenv PATH 或 env | grep MYVAR。
