优先用 version_compare() 检测 PHP 版本兼容性；PHP_VERSION_ID 仅适用于不区分预发布版的极简场景，因其无法识别 RC/alpha 等语义差异且不支持自定义策略。
直接结论：检测运行时 PHP 版本兼容性，优先用 version_compare()；仅需粗略判断主版本是否 ≥ 某整数（如 8.0），且确定不涉及 RC/alpha 等后缀时，PHP_VERSION_ID 可用但有局限。
为什么不能用 strcmp() 或直接字符串比较
因为版本号不是纯字典序字符串："7.10" 字符串比较大于 "7.2"，但语义上明显错误；"8.0.0RC1" 和 "8.0.0" 的顺序也无法靠 strcmp() 正确判定。手写解析易漏掉预发布标识（alpha、beta、dev）、补零规则、分段整数转换等细节。
常见错误现象：
-
strcmp("1.2", "1.10") > 0→ 误判为"1.2" > "1.10" -
"8.0.0RC1" > "8.0.0"在字符串比较中为false，但语义上 RC 版本应 "8.0.0"
version_compare() 的实际用法和坑点
它专为语义化版本设计，自动按段拆分、转整数、处理后缀优先级（dev > RC > beta > alpha），还支持 "pl"、"p" 等旧式标记。
立即学习“PHP免费学习笔记（深入）”；
实操建议：
- 第三个参数用小写操作符：
"、<code>">="、"!="—— 大写或拼错（如"GE"）会返回null - 不传第三个参数时，直接用返回值判断更灵活：
version_compare(PHP_VERSION, "8.0.0") >= 0 - 扩展版本检测必须先
extension_loaded("mbstring")，再调phpversion("mbstring")，否则phpversion("xxx")返回false，传给version_compare()会触发 warning - 某些扩展（如
curl）的phpversion("curl")可能返回空字符串，需额外判空
PHP_VERSION_ID 能不能替代 version_compare()
可以，但只适用于极简场景：比如你只要确保是 PHP 8.0+，且完全不关心 "8.0.0RC3" 这类非正式版是否被接受。
它的值是整数格式（如 PHP 8.0.0 → 80000，8.1.20 → 80120），计算快、无函数调用开销。但问题在于：
- 无法识别预发布版本：
PHP_VERSION_ID对"8.0.0RC1"和"8.0.0"都返回80000，失去语义区分 - 不支持自定义比较逻辑，比如“允许 RC 但拒绝 alpha”这种策略无法表达
- 8.0.0 之后新增的
str_contains()等函数，在"8.0.0RC1"环境下并不可用，仅靠PHP_VERSION_ID >= 80000会误判
复杂版本场景下容易被忽略的关键点
真正出问题的地方，往往不在标准 PHP 版本号本身，而在你实际依赖的扩展版本、第三方包版本，或自定义构建的版本字符串（如含 Git hash、日期戳、平台后缀）。
例如：
-
"v2.3.0-rc1+git.abc123"——version_compare()会把整个字符串当主版本，但你想比的只是"2.3.0-rc1" -
"2023.04.15-release"—— 必须先正则提取"2023.04.15"，再喂给version_compare() - Composer 安装时不会执行你的 PHP 代码，所以仅靠运行时
version_compare()检查毫无意义 ——composer.json中的"php": "^8.0"才是第一道防线
别指望一个函数解决所有版本问题；先确认你比的是什么，再决定要不要清洗、要不要 fallback、要不要双重校验。
