应优先读取SHELL环境变量，但需校验其有效性；不可靠时用getpwuid(getuid())->pw_shell回退；Windows无对应机制，应直接返回默认值或空字符串。
直接读 SHELL 环境变量就行，但别信它一定可靠
大多数 Unix-like 系统（Linux/macOS）会把当前登录 Shell 的路径存进 SHELL 环境变量，比如 /bin/bash 或 /usr/bin/zsh。C++ 里用 std::getenv("SHELL") 就能拿到——但这个值只反映「登录时的 Shell」，不是当前进程实际在跑的 Shell。
常见错误现象：system("echo $SHELL") 输出和 std::getenv("SHELL") 一致，但你在终端里用 exec bash 切换过 Shell 后，SHELL 变量不会自动更新；子进程继承的是父进程的环境副本，不是实时状态。
- 只适用于类 Unix 平台；Windows 没有
SHELL环境变量，返回nullptr - 如果程序是通过桌面环境（如 GNOME Terminal、iTerm2）启动的，
SHELL通常正确；但通过ssh或容器启动时，可能被覆盖或未设置 - 某些精简系统（如 Alpine 容器）默认不设
SHELL，需手动补全逻辑
getpwuid(getuid()) 是更稳的 fallback 方案
当 SHELL 不可用或不可信时，查当前用户的密码数据库项（/etc/passwd）里的默认 Shell 字段，比环境变量更接近“系统认定的登录 Shell”。POSIX 标准保证 getpwuid() 在多数 Unix-like 系统上可用。
使用场景：你写的是系统工具、服务守护进程，或需要在容器/最小化环境中运行，不能依赖用户是否设置了 SHELL。
立即学习“C++免费学习笔记（深入）”；
-
getpwuid(getuid())返回的struct passwd*中，pw_shell字段即目标路径 - 该函数不是线程安全的（返回静态缓冲区），多线程下应改用
getpwuid_r() - macOS 上需链接
-lresolv（部分旧版本），Linux 一般不用额外链接 - 注意：返回值可能为
nullptr（查不到用户），必须判空；且pw_shell可能为空字符串或/usr/bin/false这类非交互式 Shell
Windows 上没有等价机制，别硬套 Unix 思路
Windows 没有登录 Shell 的概念，也没有 SHELL 环境变量。用户可能在 cmd.exe、PowerShell.exe、WindowsTerminal.exe 甚至 WSL 里运行你的程序——这些全是不同进程，彼此不共享 Shell 元信息。
如果你真需要知道“用户大概在用什么命令行”，只能退而求其次：
- 检查
GetConsoleProcessList()+GetModuleFileNameEx()（需psapi.h），看父进程名是不是cmd.exe或powershell.exe——但 Win11+ 的 Windows Terminal 会绕过这个逻辑 - 读
PROCESS_NAME（Windows 10 1809+）或GetProcessImageFileName()，仍受限于权限和 UWP 沙箱 - 绝大多数情况下，直接返回
"cmd.exe"或空字符串更务实；强行探测反而增加崩溃风险
跨平台封装时，最容易被忽略的是“空值”和“权限”
统一接口返回 std::string 很方便，但不同平台失败路径差异极大：Unix 下可能是 nullptr（getenv）、NULL（getpwuid）、或 "/bin/false"；Windows 下连尝试都可能因权限不足失败。
- 永远检查
std::getenv("SHELL")是否非空，再检查字符串是否以/开头（防污染值如"zsh -l"） -
getpwuid_r()需要自己分配缓冲区，大小建议 ≥ 1024 字节；小了会返回ERANGE，但很多代码直接忽略 errno - 在容器或 chroot 环境中，
/etc/passwd可能缺失或不完整，getpwuid会静默失败 - 不要把结果当绝对权威——Shell 路径只是线索，真正执行命令时，还是得靠
PATH查找可执行文件
跨平台判断 Shell 路径这件事，本质是在拼凑碎片信息。越想“精确”，越容易掉进进程树、权限模型和初始化方式的坑里。留好 fallback，接受不确定性，比追求一个“正确答案”更实际。
