答案是：需通过/proc/[pid]/maps或readelf -l查elf的interp段获取实际loader路径，再用dpkg -s/rpm -qf或getconf gnu_libc_version确认其glibc版本，而非依赖ldd --version。
Linux系统没有统一的“引导加载器版本”概念，你真正要查的是当前进程实际使用的动态链接器（loader）路径及其所属的glibc版本，而不是GRUB或systemd-boot这类bootloader。
为什么不能用 ldd --version 查 loader 版本
ldd 输出的类似 ldd (GNU libc) 2.31 这行，其实是当前 shell 环境所用 glibc 的版本，和你要检查的目标程序完全无关。它不读取目标 ELF 文件的 INTERP 段，也不启动目标程序的真实 loader。
-
ldd是个 shell 脚本，本质是设置LD_TRACE_LOADED_OBJECTS=1后执行目标程序 —— 用的是你当前环境的 loader，不是目标程序声明的那个 - 比如在 Alpine 容器里跑
ldd /bin/bash，显示的仍是 musl 的信息，但 bash 可能根本不是 musl 编译的 - 真正 loader 的路径藏在
/proc/<pid>/maps</pid>或 ELF 的 interpreter 字段里，ldd不暴露这个
查正在运行进程的 loader 路径和 glibc 版本
最可靠的方式是盯住一个真实运行的进程（比如 bash 或你自己启动的程序），直接读它的内存映射或 ELF 头：
- 先找 PID：
pgrep -f "bash"或pidof bash - 看 loader 路径：
cat /proc/<pid>/maps | head -n1 | awk '{print $6}'</pid>（输出类似/lib64/ld-linux-x86-64.so.2） - 确认它属于哪个 glibc 包：
dpkg -S /lib64/ld-linux-x86-64.so.2（Debian/Ubuntu）或rpm -qf /lib64/ld-linux-x86-64.so.2（RHEL/CentOS/Fedora） - 或者直接查 glibc 版本：
getconf GNU_LIBC_VERSION—— 注意这是当前 loader 所属的 libc 版本，不是系统里装了几个不同版本
查静态编译或 musl 程序的 loader
musl 或 fully static 程序根本不走 ld-linux-*.so，它们要么自带 loader（如 musl 的 /lib/ld-musl-x86_64.so.1），要么压根没有 interpreter 段。
- 验证是否静态：
file /bin/busybox输出含statically linked就没 loader - 查 musl 程序的 interpreter：
readelf -l /bin/sh | grep interpreter，可能显示/lib/ld-musl-x86_64.so.1 - musl 版本不能用
getconf，得看文件本身：strings /lib/ld-musl-x86_64.so.1 | grep -E 'musl|version' - 容器里尤其容易混：宿主机用 glibc，镜像里却是 musl，
ldd在宿主机上跑永远查不到镜像内实际 loader
loader 不是全局配置项，每个 ELF 文件自己带；你看到的 /lib64/ld-linux-x86-64.so.2 只是 GCC 默认链接时填进去的路径，删掉、替换、甚至指向不存在的文件，只要 ELF 的 INTERP 段写对了，程序照样能跑 —— 这才是最容易被忽略的底层事实。
