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<:string std::string></:string> 存储时要注意等号位置
环境变量字符串格式统一为 "KEY=VALUE"，但 VALUE 可能含等号（比如 PATH=/usr/bin:/bin），所以不能用 std::string::find('=') 找第一个等号就切分——那样会把 PATH 的值错切成 /usr/bin:/bin 以外的部分。
正确做法是只找第一个 =，且必须确保 KEY 不为空：
立即学习“C++免费学习笔记（深入）”；
- 用
pos = line.find('='); - 检查
pos != std::string::npos && pos > 0（排除=value或key=这类非法项） key = line.substr(0, pos); value = line.substr(pos + 1);
别用 std::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<:codecvt_utf8>></:codecvt_utf8>或 C++11 后推荐的std::mbstowcs/std::wcstombs转 UTF-8 - 或者直接用
std::map<:wstring std::wstring></:wstring>避免转码丢失
为什么不用 getenv() 逐个查？
getenv("PATH") 只能查已知 KEY，没法列出“所有已加载”的变量——系统不会暴露变量名列表，getenv 内部也是靠遍历 environ 实现的。有人试图用常见变量名硬编码去查（比如 PATH, HOME, USER），但漏掉自定义变量（如 CI/CD 注入的 GITHUB_TOKEN）或发行版特有变量（如 DESKTOP_SESSION）就白忙了。
还有个坑：getenv 返回的是指向环境块的指针，内容不可修改，且下次调用可能失效（因为底层实现可能复用缓冲区）。而自己遍历 environ 或 GetEnvironmentStrings() 后拷贝进 std::map，数据完全可控、生命周期明确。
真正麻烦的从来不是“怎么读”，而是“哪些变量该信、哪些已被篡改”。比如容器里 LD_PRELOAD 被设成恶意 so，或者 PATH 插入了可疑目录——这些得靠业务逻辑校验，不是 map 一存就万事大吉。
