getenv 读取失败时，先检查环境变量是否真存在
很多情况下 getenv 返回 nullptr，不是代码写错了，而是环境变量压根没设进去。C++ 本身不负责设置环境变量，它只是读取进程启动时继承的那一份。
- Linux/macOS 下用
echo $VAR_NAME确认变量已导出（export VAR_NAME=value） - Windows 命令行用
echo %VAR_NAME%，PowerShell 用$env:VAR_NAME - IDE（如 VS Code、CLion）运行程序时，环境变量可能和终端不一致，需在 launch.json 或运行配置里显式添加
- 如果通过脚本启动程序，确保脚本里用了
export（Linux/macOS）或set（Windows cmd），而不是只写VAR_NAME=value
getenv 返回的指针不能 free，也不能长期缓存
getenv 返回的是指向进程环境块内部字符串的常量指针，生命周期和进程一样长，但内容可能被后续 putenv 或 setenv 覆盖——哪怕你没主动调用，某些库（比如 glibc 初始化阶段）也可能悄悄改。
- 不要对返回值调用
free()，会崩溃 - 不要保存该指针到全局变量或长期存活对象中，下次再用可能指向垃圾内存或已失效内容
- 安全做法是立刻用
std::string{getenv("PATH")}拷贝一份，后续操作都基于副本 - 若需多次读取且担心并发修改（极少见），应每次调用
getenv并立即复制
Windows 下区分大小写？实际不区分，但别依赖
Windows 系统层面环境变量名不区分大小写，getenv("Path") 和 getenv("PATH") 都能拿到值；但 POSIX 系统（Linux/macOS）严格区分，getenv("path") 在 Linux 上永远返回 nullptr。
- 开发跨平台代码时，统一用大写命名约定（如
"HOME"、"TMPDIR"），避免歧义 - 不要在代码里写
getenv("Path")试图兼容 Windows，这会让 Linux 用户困惑，也违背可移植习惯 - 如果必须处理用户自定义变量名，建议统一转为小写或大写后再查（注意：变量值本身仍保持原样）
替代方案：C++17 的 std::filesystem::temp_directory_path 不依赖 getenv
很多场景下你以为在用 getenv 读 "TMP" 或 "TEMP"，其实只是想拿临时目录路径——这种通用需求，标准库已有更可靠方式。
立即学习“C++免费学习笔记（深入）”；
-
std::filesystem::temp_directory_path()会自动尝试多个来源：环境变量、系统 API（GetTempPathW / tmpnam）、甚至硬编码 fallback - 它绕过了手动判断
getenv("TMP")是否为空、是否合法、是否可写等一堆检查 - 注意：需开启 C++17（
-std=c++17）并链接-lstdc++fs（GCC）或确保 MSVC 版本 ≥ 2017 - 示例：
std::filesystem::path tmp = std::filesystem::temp_directory_path();
getenv 的返回值既不能改也不能留太久，而环境本身又可能在程序运行中途被其他线程或外部工具篡改——这些细节不写进日志，也不报错，只在某个深夜调试时突然失效。 
