c++如何读取系统已加载的所有环境变量并存入Map【技巧】

Linux/macOS 用 extern char** environ 遍历，Windows 用 GetEnvironmentStringsW() 配合宽字符转换，需手动解析连续内存中的“KEY=VALUE\0”序列并注意内存释放与等号位置校验。

如何用 environ 指针遍历所有环境变量

Linux/macOS 下，C++ 程序启动时，系统会把环境变量以 char** environ 的形式传给进程。虽然不是标准 C++ 的范畴，但 POSIX 保证这个指针存在。Windows 这边就不直接提供这个指针了，得改用 GetEnvironmentStrings()。所以，跨平台读取必须分情况处理——别直接写个 extern char** environ 就开干，否则 Windows 下要么链接失败，要么直接崩溃。

实际操作建议如下：

• Linux/macOS：声明 extern char** environ;，然后用 while (environ[i]) { ... } 遍历。注意，它本质上就是个 null-terminated 的指针数组，i 从 0 开始递增，直到遇到空指针为止。
• Windows：调用 GetEnvironmentStrings() 返回 LPTCH（即 char*），这是一块连续内存，每个变量形如 "KEY=VALUE\0"，末尾有两个连续的 \0 作为结束标志。解析时需手动跳过每个 \0，注意别用 strtok，它不适用这种场景。
• Windows 下用完后，记得调用 FreeEnvironmentStrings() 释放内存，否则会造成内存泄漏。

用 std::map 存储时要注意等号位置

环境变量字符串的格式统一为 "KEY=VALUE"，但 VALUE 部分可能包含等号。比如 PATH=/usr/bin:/bin，这里等号后面还有冒号，但 VALUE 本身没有等号，所以看起来还好。但有些情况下，VALUE 里确实可能含有等号，比如某些自定义变量。因此，不能简单用 std::string::find('=') 找到第一个等号就切分——那样会把 PATH 的值错切成不完整的内容。

正确的做法是只找第一个 =，并且必须确保 KEY 不为空：

• 用 pos = line.find('=');
• 检查 pos != std::string::npos && pos > 0（排除 =value 或 key= 这类非法项）
• key = line.substr(0, pos); value = line.substr(pos + 1);

这里建议用 std::map 而不是 std::unordered_map。虽然 unordered_map 查找更快，但环境变量本身是无序的，而 std::map 的键会自动排序，这在调试时观察输出会方便很多。

Windows 下 GetEnvironmentStrings() 返回的是 ANSI 还是 UTF-16？

默认链接到 MultiByte 版本时，GetEnvironmentStrings() 返回的是当前代码页的 ANSI 字符串（比如 GBK 或 Latin-1），不是 UTF-8。如果你的环境变量里包含中文路径（比如 USERPROFILE=C:\用户\张三），在控制台编码不匹配时可能会显示乱码，但 std::string 仍然能原样存下字节流——只是后续打印或比较可能会出问题。

更稳妥的做法，尤其是面向现代 Windows 应用时：

• 改用宽字符版本：GetEnvironmentStringsW()，返回 LPWCH（wchar_t*）
• 用 std::wstring_convert> 或 C++11 后推荐的 std::mbstowcs/std::wcstombs 转 UTF-8
• 或者直接用 std::map 避免转码过程丢失信息

为什么不用 getenv() 逐个查？

有人可能会问：直接用 getenv("PATH") 查已知的变量不就行了？问题是，getenv 只能查已知 KEY，没法列出“所有已加载”的变量——系统根本不会暴露变量名列表，getenv 内部也是靠遍历 environ 实现的。有人试图用常见变量名硬编码去查（比如 PATH, HOME, USER），但这样会漏掉自定义变量（比如 CI/CD 注入的 GITHUB_TOKEN）或发行版特有的变量（比如 DESKTOP_SESSION），结果白忙一场。

还有个坑：getenv 返回的是指向环境块的指针，内容不可修改，而且下次调用可能失效（因为底层实现可能复用缓冲区）。而自己遍历 environ 或 GetEnvironmentStrings() 后拷贝进 std::map，数据完全可控，生命周期也明确。

其实，真正麻烦的从来不是“怎么读”，而是“哪些变量该信、哪些已被篡改”。比如容器里 LD_PRELOAD 被设成恶意 so，或者 PATH 里插入了可疑目录——这些得靠业务逻辑去校验，不是 map 一存就万事大吉的。