环境变量入门：什么是环境变量、为什么需要环境变量、环境变量的分类
说实话，我刚开始接触嵌入式开发那会儿，对「环境变量」这东西完全没概念。那时候我还在用 Keil 点灯，觉得把代码写对就行了，管什么环境变量？直到有一次，我帮同事调试一个工程，他电脑上编译好好的代码，到我这儿就报错——找不到头文件、链接器路径不对、烧录工具死活连不上。折腾了一下午，最后发现是 PATH 变量里少了个路径。
嗯，从那以后，我再也不敢小看环境变量了。
什么是环境变量？
说白了，环境变量就是操作系统维护的一组键值对。它告诉系统：去哪里找可执行文件、临时文件放哪儿、当前用户是谁、用什么语言显示界面。
你可以把它想象成一张「小纸条」，系统每次启动程序时都会掏出来看一眼。比如你在终端里敲 gcc，系统就去 PATH 变量里列出的目录挨个找，找到了就执行，找不到就报错。
核心概念：环境变量 = 操作系统给进程的「上下文信息」。每个进程启动时，都会继承父进程的环境变量副本。
我个人的习惯是，把环境变量理解成「全局配置参数」。它不藏在代码里，而是挂在系统上。换一台电脑，只要把环境变量配好，代码就能跑起来。这一点在嵌入式开发中尤其重要——你想想看，交叉编译工具链、烧录工具、SDK 路径，哪个不得靠环境变量来定位？
为什么需要环境变量？
你可能会问：把这些路径写死在代码里不行吗？行，但后果很严重。
举个例子。我在做一个 STM32 项目时，用了 arm-none-eabi-gcc 工具链。如果我把工具链的绝对路径 C:\tools\gcc-arm\bin\arm-none-eabi-gcc.exe 硬编码在 Makefile 里，那同事拉代码后必须把工具链装到一模一样的路径，否则编译就炸。更麻烦的是，如果公司统一升级了工具链版本，我得改所有工程里的路径。
用环境变量就简单了：
# 在 .bashrc 或系统设置中定义
export TOOLCHAIN_PATH=/opt/gcc-arm-none-eabi/bin
export PATH=$PATH:$TOOLCHAIN_PATH
# 在 Makefile 中引用
CC = arm-none-eabi-gcc
这样，工具链路径只在一个地方维护。换版本？改一行环境变量就行。换电脑？配一次环境变量，所有工程都能用。
环境变量的核心价值就三点：
- 解耦配置与代码——路径、参数不写死在源码里
- 跨环境一致性——开发机、CI 服务器、同事电脑用同一套配置逻辑
- 运行时动态调整——不用改代码，改个变量就能切换行为
我的经验：在嵌入式项目中，我习惯把 TOOLCHAIN_PATH、SDK_PATH、FLASH_TOOL_PATH 这三个变量单独拎出来配。这样不管是换编译器版本、升级 SDK，还是换烧录工具，都只需要改一处。
环境变量的分类：系统级 vs 用户级
环境变量不是铁板一块。它分两级：系统级和用户级。这两者的区别，我当年踩过坑才真正搞明白。
| 特性 | 系统级环境变量 | 用户级环境变量 |
|---|---|---|
| 作用范围 | 所有用户、所有进程 | 仅当前用户及其启动的进程 |
| 修改权限 | 需要管理员/root 权限 | 普通用户即可修改 |
| 生效时机 | 重启系统或重新登录 | 重新登录或 source 配置文件 |
| 典型用途 | 全局工具链路径、系统默认库路径 | 个人开发工具路径、用户自定义别名 |
| 配置文件 | /etc/environment, /etc/profile | ~/.bashrc, ~/.profile, ~/.zshrc |
我个人的建议是：能用用户级就别用系统级。为什么呢？因为系统级变量一旦配错，影响的是所有用户。我曾经在公司的共享开发服务器上，不小心把系统级 PATH 写漏了一个关键目录，结果所有同事的终端都找不到基本命令——ls、cd 倒是还能用，但 gcc、make 全挂了。那场面，别提多尴尬了。
用户级变量只影响你自己。配错了，顶多自己折腾一下，不会连累别人。而且用户级配置文件的修改不需要管理员权限，灵活得多。
避坑指南：我曾经在 /etc/environment 里加了一行 PATH=/my/custom/path，结果把系统原来的 PATH 覆盖了。正确的做法是 PATH=/my/custom/path:$PATH，把新路径追加在前面。系统级变量修改前，一定先备份！
知识体系总览
下面这张图，把本章的核心逻辑串起来了。你可以把它当作环境变量的「脑图」来用。
这张图从左到右梳理了三个核心问题：环境变量是什么、为什么需要它、以及它怎么分类。你可以看到，系统级和用户级下面还挂了各自的配置文件路径——这些文件，就是你实际动手配环境变量时要操作的地方。