linux/macos下用extern char** environ可遍历全部环境变量，形如"key=value"的null结尾数组，需手动解析；windows须用getenvironmentstringsw并释放内存，std::getenv无法获取全量。
Linux/macOS 下用 environ 全局变量遍历最直接
标准 C++ 没有跨平台获取全部环境变量的接口，但在 POSIX 系统（Linux/macOS）上，extern char** environ 是可信赖的入口。它指向一个以 NULL 结尾的字符串数组，每个元素形如 "KEY=VALUE"。
注意：必须包含 <unistd.h></unistd.h>（或 <>cunistd>），且 environ 不是标准 C++ 符号，需在链接时确保可用（绝大多数编译器默认支持）。
常见错误是直接用 std::vector<:string>(environ)</:string> 构造——这会崩溃，因为 environ 不是标准容器，不能靠隐式长度推断。
推荐做法：
- 用
while (environ[i] != nullptr)手动计数或遍历 - 对每个
environ[i]用std::string::find('=')分离键值，避免硬拆第一个=之后所有内容（值本身可能含=） - 若需线程安全，注意
environ是进程全局的，多线程读取没问题，但修改（如调用putenv）需同步
Windows 下必须用 GetEnvironmentStringsW + 手动解析
Windows 没有 environ 的等价全局变量；C 运行时的 _environ 在 MSVC 中存在但行为不稳定（尤其启用安全 Cookie 或 /GS 时可能被重定向），不建议依赖。
正确方式是调用 Win32 API：GetEnvironmentStringsW 返回一个连续的宽字符内存块，各变量以 L'<p>正确方式是调用 Win32 API：<code>GetEnvironmentStringsW 返回一个连续的宽字符内存块，各变量以 L'\0' 分隔，末尾有两个连续 L'\0'。
L'<p>正确方式是调用 Win32 API：<code>GetEnvironmentStringsW 返回一个连续的宽字符内存块，各变量以 L'\0' 分隔，末尾有两个连续 L'\0'。'。
关键细节：
- 必须用
FreeEnvironmentStringsW释放返回指针，否则内存泄漏 - 不能直接把返回指针当
const wchar_t*传给std::wstring构造函数——它不是单个字符串，而是多个零分隔字符串的拼接 - 解析循环要检查
ptr[i] == L'\0' && ptr[i+1] == L'\0'判断结束，而非只看ptr[i] == L'\0'
std::getenv 只能查单个变量，不能列全量
很多人误以为 std::getenv("PATH") 能“列出”变量，其实它只返回指定键的值指针，且返回的是 C 风格字符串，生命周期由实现管理（通常不可 delete，也不保证线程安全）。
更隐蔽的问题：
- 在 Windows 上，
std::getenv对大小写敏感（"Path"≠"PATH"），而系统实际变量名不区分大小写 - 它不反映
SetEnvironmentVariable后立即变更的值（某些 CRT 实现有缓存） - 无法得知当前有哪些键存在——你得预先知道所有可能的键名才能轮询
跨平台封装要注意的三个坑
如果写工具类统一处理，别只做“Linux 用 environ、Windows 用 GetEnvironmentStringsW”的简单分支。
真正容易出错的地方是：
- 编码：Linux/macOS 环境变量是 locale 编码（通常是 UTF-8），Windows 是 UTF-16；混用
std::string和std::wstring会导致乱码或截断 - 空值处理：某些变量值为空（
"KEY="），解析后 value 应为""，不是nullptr或跳过 - 内存所有权：POSIX 下
environ指向的数据由 OS 管理，不能free；Windows 下GetEnvironmentStringsW返回的内存必须用对应Free*函数释放——封装层必须明确谁负责释放
最简健壮方案是：各平台用原生方式获取原始数据，立刻转成 std::map<:string std::string></:string>（Linux）或 std::map<:string std::wstring></:string>（Windows），后续逻辑只操作副本。原始指针/内存在转换完成后立即释放或丢弃。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
