Docker容器中传入环境变量的可见性误区

嘿，这个问题其实是shell环境变量继承和配置文件加载逻辑的典型坑！我来给你拆解清楚两种最常见的场景：

1. 变量没加export，子shell根本拿不到它 #

假设你之前在当前shell里直接敲了：

XYZ=123

但没加export关键字——这时候这个变量只属于当前shell进程，不会被它启动的子shell继承。

比如你如果执行sh -c 'echo $XYZ'或者其他需要启动子shell的命令，子shell里根本没有这个变量，自然输出就是空行。

而当你输入bash进入新的交互式bash会话时，要是你刚好在~/.bashrc或者~/.bash_profile这类配置文件里已经写了export XYZ=123，那这个新会话加载配置文件后，变量就生效了，你自然能看到XYZ=123。

解决办法：要让变量能被子shell继承，设置时一定要加export：

export XYZ=123

2. 变量只定义在交互式shell的配置文件里 #

如果你把XYZ=123（哪怕加了export）只写在了~/.bashrc里，那麻烦就来了：

默认情况下，非交互式shell（比如脚本、bash -c '命令'这种形式）不会加载.bashrc，所以当你直接执行echo $XYZ（如果是在非交互式场景），变量根本没被设置，输出就是空的。

但当你输入bash进入交互式shell时，bash会自动加载.bashrc，变量被设置，你就能看到XYZ=123了。

解决办法：

• 要是想让非交互式shell也能读到这个变量，可以把变量定义移到~/.bash_profile或者~/.profile（这两个是登录shell会加载的文件，非交互式shell有时候也会读）；
• 或者执行非交互式命令时，显式加载.bashrc：

bash -c 'source ~/.bashrc && echo $XYZ'

小技巧：验证变量状态 #

想快速确认变量是否被导出，可以用：

env | grep XYZ

如果能输出结果，说明变量已经被导出；如果看不到，再用set | grep XYZ，能看到的话就是变量存在但没被导出。

内容的提问来源于stack exchange，提问作者Spring fancy