PHP代码重构：消除版本分支判断的优雅架构设计-php教程-PHP中文网

应使用接口+工厂模式替代version_compare()硬编码分支，将版本差异抽象为实现类（如LegacyJsonEncoder/NativeJsonEncoder），由工厂一次性判断后返回实例，避免逻辑撕裂、测试难覆盖及静态分析失效。

php代码重构：消除版本分支判断的优雅架构设计

PHP 版本分支判断（如 if (version_compare(PHP_VERSION, '8.0', '>='))）不是临时方案，而是架构腐化的明确信号——它意味着同一份逻辑被硬编码撕裂，维护成本随版本增长非线性上升。

直接在业务逻辑里写版本判断，会导致测试难覆盖、IDE 无法跳转、静态分析失效。核心思路是把“行为差异”抽象为接口，让工厂按运行时环境返回具体实现。

定义统一接口，比如 JsonEncoderInterface，声明 encode() 和 decode()
为 PHP 7.4 写 LegacyJsonEncoder（用 json_encode($data, JSON_THROW_ON_ERROR) 模拟异常）
为 PHP 8.0+ 写 NativeJsonEncoder（直接调用 json_encode()，依赖原生错误抛出）
工厂类 JsonEncoderFactory::create() 里只做一次 version_compare()，返回对应实例，后续全走接口调用

很多人把版本判断塞进 autoload.php 或服务提供者构造函数里，结果导致 CLI 命令、单元测试、甚至 composer dump-autoload 都被迫加载不相关逻辑。

这类检查看似轻量，但会掩盖真正的兼容性问题，且无法被 Psalm/PHPStan 推导类型流。

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

function_exists('str_contains') 不等于 “可用”，因为 PHP 8.0 才引入该函数，但它的语义（返回 bool）和 polyfill（如 symfony/polyfill-php80）的行为可能不一致
优先使用 use function 引入 polyfill 函数，并在 composer.json 中显式 require symfony/polyfill-php80，而不是运行时探测
对 class_exists('Stringable') 这类判断，应直接依赖 php >=8.0 或改用 interface_exists() + 显式实现，而非动态判断

架构再优雅，没过这几个点就等于没落地。

CLI 环境下执行 php -d extension=opcache.so -d opcache.enable_cli=1 artisan optimize:clear，确认无版本判断提前触发
在 PHP 7.4 容器中跑单元测试，确保 LegacyJsonEncoder 被调用且异常路径覆盖完整
用 phpstan analyse --level max 检查，所有 JsonEncoderInterface 使用处不能出现混合类型警告

最易被忽略的是「工厂缓存」——JsonEncoderFactory::create() 必须静态缓存实例，否则每次调用都重复 version_compare()，既无意义又干扰性能分析。