std::getenv 是 C++ 中唯一可移植读取环境变量的方式，但需判空、注意大小写、配合 std::filesystem::path 拼接路径，并警惕 IDE 环境隔离与 std::putenv 内存安全问题。
用 std::getenv 读取环境变量最直接，但返回值可能为空
系统路径类环境变量（比如 PATH、HOME、USERPROFILE）本质就是字符串，std::getenv 是 C++ 标准库中唯一可移植的读取方式。它不区分“路径”或“普通变量”，只管键名。
常见错误是拿到返回指针后直接解引用，没检查是否为 nullptr——尤其在 Windows 上访问 HOME 或 Linux 上访问 USERPROFILE 时必然失败。
- 始终用
if (auto* val = std::getenv("PATH")) { /* 安全使用 */ }判断非空 -
std::getenv返回的是const char*，不能直接赋给std::string而不判空，否则触发未定义行为 - 环境变量名大小写敏感：Linux/macOS 用
HOME，Windows 习惯用HOMEPATH+HOMEDRIVE拼接，别硬套一个名字跑所有平台
拼接路径时别手写 / 或 std::filesystem::path
读到 PATH 后通常要拆分成多个目录再逐个检查是否存在，这时容易手动拼接路径分隔符，导致跨平台出错。
比如把 std::string("/usr/bin") + "/" + "gcc" 写死在代码里，在 Windows 上就失效；反过来用 "C:\Program Files" + "\foo.exe" 在 Linux 下编译都过不了。
立即学习“C++免费学习笔记（深入）”；
- C++17 起用
std::filesystem::path自动处理分隔符：std::filesystem::path p = std::getenv("HOME"); p /= ".config"; p /= "app.conf"; -
std::filesystem::path构造时接受const char*，所以可直接传std::getenv结果（仍需先判空） - 注意：MSVC 19.28+、GCC 10+、Clang 10+ 才完整支持
std::filesystem，老版本需链接-lstdc++fs或启用实验性开关
读不到 PATH？可能是子进程继承问题或 IDE 环境隔离
本地终端里 echo $PATH 显示正常，但 C++ 程序里 std::getenv("PATH") 返回空，大概率不是代码问题，而是运行上下文不对。
典型场景：在 VS Code 或 CLion 里点 ▶️ 运行，IDE 启动的进程没继承 shell 的完整环境变量；或者用 fork+exec 启子进程时，显式清空了 envp。
- Linux/macOS 下调试时，在终端执行
env | grep PATH确认当前环境确实有该变量 - VS Code 中需在
launch.json里加"environment": [{"name":"PATH","value":"${env:PATH}"}] - CLion 默认继承 shell 环境，但若用了 “Run with Python console” 或远程解释器，环境可能被重置
- 避免在
main()之前调用std::getenv——静态初始化顺序不确定，某些极端情况会返回空
需要修改环境变量？std::putenv 不安全，优先用启动参数或配置文件
有人想在程序里临时改 PATH 让后续 system() 或 std::filesystem::exists() 生效，但 std::putenv 有严重陷阱：它不复制字符串，要求传入的内存生命周期必须长于进程运行时间。
常见崩溃写法：std::string new_path = "/opt/bin:" + std::string(std::getenv("PATH")); std::putenv(const_cast<char>(new_path.c_str()));</char> ——new_path 一出作用域，putenv 就指向了野指针。
- 真要改环境变量，用
setenv("PATH", new_cstr, 1)（POSIX）或_putenv_s("PATH", new_cstr)（MSVC），它们会做内存拷贝 - 但更推荐绕开修改：把路径作为命令行参数传入，或写进配置文件，由逻辑层解析，而非依赖全局环境变量
-
std::getenv读的是进程启动时快照，后续父进程改环境变量不影响已运行的子进程
环境变量不是路径专用通道，它的值只是字符串；真正麻烦的是跨平台路径拼接、IDE 环境继承差异、以及修改时的内存生命周期管理——这三处最容易卡住人。
