环境变量入门：先分清三类变量，再谈怎么安全地用

刚学编程时，很多人都遇到过这样的场景：同一段代码，在自己的电脑上能跑，换一台电脑就报错；或者本地运行正常，一部署到服务器就找不到数据库。很多时候，问题不在代码本身，而在代码运行的“环境”里。环境变量，就是程序和运行环境之间传递信息的一种常用方式。理解它，能帮我们少踩很多部署和配置的坑。

一、什么是环境变量

环境变量是操作系统提供给程序的一组“键值对”，名字通常由大写字母和下划线组成，例如 PATH、HOME、NODE_ENV。程序启动时，操作系统会把这些键值对交给程序，程序再按名字读取。

可以把它想象成一张贴在门口的告示：进门的人不用到处打听，直接看告示就知道今天的安排。环境变量的优点是，同一份代码不用改动，就能在不同环境里表现出不同的行为。比如开发环境连接本地数据库，生产环境连接线上数据库，区别只在于环境变量的值不同。

二、先分清三类变量

很多人把环境变量混为一谈，其实它们的作用范围并不一样。

第一类是系统级变量，由操作系统或管理员设置，对这台机器上的所有用户和程序生效，例如系统自带的 PATH，告诉系统去哪些目录找可执行程序。

第二类是会话级变量，只在当前终端或当前登录会话里有效。在终端里用 export 设置的变量就属于这一类，关掉终端窗口，它就消失了，适合临时调试。

第三类是进程级变量，只属于某一个正在运行的程序。程序启动时从父进程继承一部分变量，也可以由启动它的脚本单独指定。子进程能看到父进程传下来的变量，但反过来不行：子进程改了自己的变量，不会影响父进程。

除此之外，开发中常见的还有一种“配置文件式”的做法，就是把变量写进项目根目录下的环境配置文件里，由启动工具在运行前读入。这类文件本身不是操作系统机制，只是一种约定，用起来方便，但要特别注意保管。

三、怎么查看和设置

在 Linux 或 macOS 的终端里，可以用 echo 加上变量名查看单个变量，用 env 或 printenv 列出当前会话的全部变量。临时设置一个变量，只在当前终端里生效，直接写 export 变量名=值就可以；想让它每次打开终端都生效，就需要把它写进 Shell 的启动配置文件里，再重新打开终端或者重新加载配置。

在 Windows 上，可以用系统设置里的“环境变量”面板添加或修改，改完之后，已经打开的程序需要重新启动才能读到新值；也可以在命令行里用 set 命令临时设置一个只在当前窗口有效的变量。

一条新手常忽略的经验是：改了环境变量，先确认生效范围。只改了当前终端，却去另一个终端里验证，自然验证不到；只改了某个窗口，却指望整个系统都用上，也一样会落空。

四、优先级与覆盖

同一个变量名可能在多个地方被设置，于是就有了优先级问题。一般规律是：离程序越近的设置，优先级越高。也就是说，启动命令里临时指定的值，会覆盖启动脚本里的值；启动脚本里的值，又会覆盖系统级默认值。

明白这一点，排查问题就有了方向：当程序读到的值和预期不一样时，可以沿着“系统、会话、启动脚本、启动命令”这条链，从近到远逐个检查，看到底是哪一层把值改掉了。不要一上来就怀疑代码，而是先把变量的实际值打印出来看一看。

五、四个最常见的坑

第一个坑是空格和引号。值里面如果带空格，要用引号把整个值包起来，否则系统会把空格后面的部分当成别的内容。第二个坑是大小写，在多数系统里，变量名是区分大小写的，Path 和 PATH 是两个完全不同的名字。第三个坑是“改了不生效”，很多程序只在启动那一刻读取一次变量，改完变量必须重启程序，正在运行的程序不会自动更新。第四个坑最危险：把密码、密钥、令牌这类敏感信息直接写进代码或随代码提交到仓库。正确的做法是只在运行环境里配置这些值，代码里只按名字读取，不把真实值写进仓库。

六、安全使用的三条清单

第一，分开存放：普通配置可以写进配置文件，敏感信息只放在运行环境里，两种东西不要混在一起提交。第二，分环境管理：开发、测试、生产各用一套值，上线前核对一遍，不要把开发环境的值原样带到生产。第三，定期检查：看看项目里还有没有残留的旧密钥，看看配置文件有没有被不小心提交，看看离职或换岗人员的访问是否已经收回。

环境变量本身并不复杂，难的是分清它的层次和范围。先弄清系统级、会话级、进程级这三类变量的区别，再记住“离程序越近优先级越高、改完要重启验证”这两条规律，配置问题就解决了一大半。下次部署时，不妨先把关键变量的值确认一遍，再启动程序，这一步，往往就是省下半天排查时间的关键。