直接查当前默认编译器版本用 gcc --version 和 g++ --version，输出即终端实际调用的编译器版本，最可靠；注意是双短横线，-version 无效；未安装时提示 command not found，旧版可能不支持新标准，多版本需用 which gcc 和 ls -l $(which gcc) 追踪真实路径。
直接查当前默认编译器版本用 gcc --version 和 g++ --version
这两个命令输出的就是你终端里敲 gcc 或 g++ 时实际调用的编译器版本，不看软链接、不猜路径，最可靠。注意是两个短横线 --version，写成 -version 会报错或没反应。
常见错误现象：
-
command not found：说明没装，不是版本问题，先装gcc和gcc-c++（CentOS/RHEL）或build-essential（Ubuntu/Debian） - 输出版本号但明显偏低（如
4.8.5）：系统自带旧版，不代表不能用，但可能不支持-std=c++17这类新标准 -
gcc有输出，g++没反应：只装了gcc，没装 C++ 支持，需补装gcc-c++或g++包
确认哪个 gcc/g++ 实际被调用：用 which gcc 和 ls -l $(which gcc)
有时候 gcc --version 显示的是 11.4，但项目里编译却报 error: ‘filesystem’ is not a member of ‘std’，大概率是环境里存在多个 gcc，而 PATH 顺序导致调用了别的版本。
执行这两步就能看清真实路径和来源：
-
which gcc：告诉你命令解析到哪个可执行文件 -
ls -l $(which gcc)：如果输出里有箭头（→），说明是软链接，继续追下去看最终指向哪版（比如指向/usr/bin/gcc-11还是/opt/rh/devtoolset-11/root/usr/bin/gcc）
特别注意：某些系统（如 CentOS 7 + SCL）会用 scl enable devtoolset-11 bash 切换工具链，此时 which gcc 的结果只在当前 shell 有效，新开终端就失效。
查 clang 或其他编译器是否存在：clang --version、command -v clang
不是所有 Linux 系统都预装 clang，但越来越多项目（尤其 Rust/C++ 跨平台构建）会显式依赖它。光看 gcc 不够。
推荐组合检查：
-
command -v clang：比which clang更 POSIX 兼容，返回空则未安装或不在PATH -
clang --version：确认 clang 是否可用且能输出版本（有些旧 clang 只支持-v） - 如果要用 clang 编译 C++，记得验证
clang++ --version是否也存在——二者不一定捆绑安装
性能影响提示：clang 编译速度通常比 gcc 快，错误提示更友好，但生成的二进制体积和运行时性能因项目而异，别只看版本号做选型。
想知道某个已编译程序当初用什么编译器：靠 readelf -p .comment /path/to/binary
ldd 看依赖库、file 看架构，都不直接暴露编译器。真正藏编译器信息的地方是 ELF 文件的 .comment section。
实操命令：
-
readelf -p .comment /usr/bin/gcc：常能看到类似GCC: (GNU) 11.4.0的字符串 -
readelf -p .comment ./myapp | grep -i "clang\|gcc"：快速过滤关键词
限制很明确：该字段由编译器自动写入，但可被 strip 删除。如果输出为空或只有乱码，不代表没编译过，只是元数据被清掉了。这时候只能靠构建日志或 strings ./myapp | grep -E "(GCC|clang)" 碰运气。
容易被忽略的一点：交叉编译产物（比如 aarch64-linux-gnu-gcc 编译出的 binary）在 x86 主机上跑 readelf 没问题，但 file 和 ldd 会提示“not a dynamic executable”或“not a valid ELF file”，别因此误判编译器缺失。
