最直接可靠的方式是读取 /etc/os-release 文件，因其符合 LSB 标准、字段稳定且语义明确，VERSION_ID 和 PRETTY_NAME 等字段适用于脚本判断与人工识别，而其他方式如 /etc/centos-release 仅作备选，hostnamectl、lsb_release、uname 等均存在兼容性或可靠性问题。
最直接可靠的方式是读取 /etc/os-release 文件，它结构清晰、字段稳定，适合脚本和人工双重使用；/etc/centos-release 或 /etc/redhat-release 作为备选，输出更简明但字段不统一。
为什么优先用 /etc/os-release
这个文件是 LSB（Linux Standard Base）标准定义的跨发行版格式，CentOS 7 及以后版本都支持。它的字段语义明确，不会因系统定制或最小化安装而缺失关键信息。
VERSION_ID="7"直接给出主版本号，可用于条件判断（比如 shell 脚本中if [[ "$(cat /etc/os-release | grep VERSION_ID | cut -d= -f2 | tr -d '"')" == "8" ]]）PRETTY_NAME="CentOS Linux 7 (Core)"是人眼可读的完整标识，含代号（Core / Stream）ID="centos"和ID_LIKE="rhel fedora"表明兼容性谱系，对容器镜像或 Ansible role 选型有实际参考价值- 注意：CentOS Stream 8/9 的
VERSION_ID仍是数字（如"8"），但PRETTY_NAME会含Stream字样，这是区分传统 CentOS 与滚动版的关键
/etc/centos-release 和 /etc/redhat-release 怎么选
两者内容几乎一致，都是纯文本单行输出，例如 CentOS Linux release 7.9.2009 (Core)。区别在于：/etc/centos-release 是 CentOS 最新包自带，/etc/redhat-release 是兼容 RHEL 的通用路径。
- 如果只求快速确认版本，
cat /etc/centos-release最省事，无需依赖额外命令 - 某些精简镜像（如 Cloud-init 初始化的 minimal CentOS）可能删掉
/etc/centos-release，但通常保留/etc/redhat-release - 不要依赖
/etc/issue：它可能被登录横幅覆盖或修改，且 CentOS 8+ 默认不包含有效版本信息
hostnamectl 能不能替代文件读取
hostnamectl 用来做快速概览没问题，但真要拿它做自动化解析，就不太合适了。原因很简单：执行后返回的是多行信息，虽然版本通常写在 Operating System: 这一行里，可它的格式并不稳定——有时候会带括号，有时候又没有。另外，这个命令本身还受 systemd 版本影响（CentOS 7 至少需要 systemd-219，内核太旧时甚至可能压根没有这个命令）。
- 适合运维人员临时查证，尤其当你顺手要一起看主机名、架构、虚拟化类型时
- 若需提取纯版本号，不如直接用
grep -oP 'CentOS Linux release K[0-9.]+'处理/etc/centos-release，更轻量可靠 hostnamectl --static在 CentOS 7.6+ 可用，但返回的是 hostname，不是 OS 版本，别混淆
别踩这些坑
lsb_release -a 乍一看确实很“标准”，但问题在于，它并不是默认就有的。CentOS 的最小化安装里，通常不会预装 redhat-lsb-core 包，直接执行时大概率就会看到 command not found。而且就算后来补装了，它输出的某些字段——比如 Codename——在 CentOS Stream 里也并不稳定。
uname -r返回的是内核版本（如3.10.0-1160.el7.x86_64），el7部分只是暗示大版本，不能代替发行版版本号——你无法从el8准确判断是 CentOS 8 还是 RHEL 8 或 Rocky Linux 8/proc/version和uname -a同样只反映内核，不体现用户空间发行版策略（比如 CentOS Stream 的更新节奏）- RPM 包查询（
rpm -q centos-release）虽可靠，但依赖包未被卸载；有些云镜像会精简该包，导致命令失败
真正需要版本号的地方（比如 CI/CD 脚本、部署前检查），只信任 /etc/os-release；临时排查就打开 /etc/centos-release 瞥一眼——简单的事，别绕远路。
