getenv和putenv用于进程级环境变量的即时读写，putenv需确保字符串长期有效，setenv更安全；无法永久修改系统级环境变量，需借助安装脚本或配置文件。
如何用 getenv 和 putenv 读写当前进程环境变量
进程级环境变量的读写是即时、局部的，不影响父进程或系统其他进程。C++ 标准库不提供直接操作环境变量的接口，需依赖 C 标准库的 getenv、putenv 或 setenv（POSIX）。
注意：putenv 要求传入的字符串内存必须长期有效（不能是栈上临时变量），否则后续调用可能崩溃；setenv 更安全，会内部复制字符串。
-
getenv("PATH")返回指向当前进程环境块中值的 const char*，不可修改返回指针所指内存 -
putenv("MY_VAR=value")接收形如"KEY=VALUE"的完整字符串，且该字符串生命周期必须覆盖整个进程运行期 -
setenv("MY_VAR", "new_value", 1)第三个参数为 1 表示覆盖已有值，0 表示仅当键不存在时设置；它会分配并拷贝内容，更推荐 - 修改后调用
getenv("MY_VAR")可立即读到新值，但子进程是否继承取决于你是否在fork+exec前完成设置
为什么 putenv 改了却看不到效果？常见内存陷阱
最典型的问题是传递了栈上构造的字符串，比如：char buf[64]; sprintf(buf, "TMPDIR=%s", path); putenv(buf); —— 函数返回后 buf 失效，环境变量条目变成悬垂指针，后续 getenv 行为未定义，甚至导致段错误。
正确做法只有两种：
- 用
strdup分配堆内存：char *s = strdup("HOME=/tmp"); putenv(s);（记得不再需要时free(s)，但实际很少主动清理） - 改用
setenv("HOME", "/tmp", 1)，完全规避内存管理问题 - 全局/静态字符数组也可行，但灵活性差：
static char env_buf[] = "LANG=en_US.UTF-8"; putenv(env_buf);
Windows 下对应的是 GetEnvironmentVariableA / SetEnvironmentVariableA，行为更接近 setenv，无需手动管理字符串生命周期。
无法“永久写入系统级环境变量”：C++ 本身做不到
C++ 运行时没有权限、也没有机制去修改操作系统级别的环境变量持久配置。所谓“永久”，本质是让 shell 启动时自动加载的配置文件（如 Linux 的 /etc/environment、~/.bashrc，Windows 的注册表 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment）发生变更。
这意味着你需要：
- Linux/macOS：以 root 权限打开并追加文本到
/etc/environment，或写入用户 shell 配置文件（如~/.profile），然后提醒用户重载：source ~/.profile - Windows：调用
RegSetValueEx写注册表，并广播WM_SETTINGCHANGE消息通知 Explorer 刷新（否则新窗口仍看不到） - 所有操作都需管理员/root 权限，普通进程默认无权修改系统级配置
- 不要试图用
system("echo 'export X=Y' >> /etc/profile")—— 权限失败、shell 解析歧义、编码/换行问题多，且不可靠
跨平台写系统级变量？别硬扛，交给安装器或脚本
真正需要“永久生效”的场景（如软件安装），C++ 程序不该自己去碰系统配置文件或注册表。原因很实在：
- 权限提升流程复杂（Linux 的 polkit / Windows 的 UAC 提权对话框需单独实现）
- 不同发行版对环境变量加载顺序不一致（
/etc/environmentvs/etc/profile.d/*.sh） - Windows 注册表键值类型（REG_EXPAND_SZ vs REG_SZ）、是否需要重启资源管理器，都是易错点
- 用户可能使用 zsh/fish/powershell，硬编码 bash 逻辑会失效
更可行的做法是生成一个配置片段（如 myapp-env.sh），提示用户手动 source，或由安装脚本（Inno Setup、NSIS、deb/rpm 包管理器）在提权上下文中完成写入。C++ 进程只负责“本次运行时”的环境控制，边界要划清。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
