PSR标准不绑定PHP版本，但落地受限于PHP解释器版本和框架支持能力；PHP 7.4+支持PSR-12联合类型等特性，PHP 8.0+才真正兼容PSR-7不可变消息，低于7.2则PSR-4/PSR-12易在加载或校验阶段失败。
PSR-4 自动加载在 PHP 7.2–8.3 中的行为差异
PSR-4 是纯路径映射协议，不依赖语言特性，但实际加载行为受 PHP 版本底层 autoloader 实现影响：
- PHP 7.2–7.4：
spl_autoload_register回调中若抛出ParseError（如语法错误），会中断整个 autoload 链，导致后续类无法加载——这常被误判为“PSR-4 失效”，其实是文件本身语法不兼容 - PHP 8.0+：引入
throw new ParseError的统一异常机制，Composer 的dump-autoload -o会提前报错，而不是运行时静默失败 - ThinkPHP 5.1 在 PHP 7.4 下可跑通 PSR-4，但若类中用了 PHP 8.0 的联合类型（如
string|int），即使路径对、命名空间对，也会在实例化时报Fatal error: Uncaught TypeError，这不是 PSR-4 问题，而是 PHP 版本越界 - composer.json 中的
"php": "^7.4"约束只影响composer install阶段，不阻止你在 PHP 8.2 下运行含 PHP 7.4 语法的代码——但反过来不行
PSR-12 格式校验在不同 PHP 版本下的工具链限制
PHP-CS-Fixer 的规则支持与 PHP 版本强相关，不是所有 PSR-12 条款都能在旧版本上启用：
-
php-cs-fixer v3.15+要求 PHP ≥ 7.2.5，但若你启用了modernize_types_cast或nullable_type_declaration_for_default_null_value这类规则，它们只在 PHP 7.4+ 解析器下生效 - PHP 7.3 下运行
php-cs-fixer fix并启用declare_strict_types规则，会成功插入declare(strict_types=1);，但不会检查函数签名是否真符合严格模式——那是运行时的事 - TP6.x 的源码里常见
public function __construct($config = [])，在 PHP 8.0+ 启用type_declaration_spaces规则后会被强制改成public function __construct(array $config = [])；但 PHP 7.2 不支持参数类型声明，强行加会直接解析失败 - 别在 PHP 7.1 环境下用
--rules=@PSR12全量执行，某些规则（如no_superfluous_phpdoc_tags）依赖 PHP 7.4+ 的反射 API，会报ReflectionException
PSR-3 日志接口在 PHP 版本迁移中的兼容断点
PSR-3 接口定义本身稳定，但实现层（如 Monolog）的最低 PHP 要求会拖累落地：
- Monolog 2.x 要求 PHP ≥ 7.2，且默认使用
Stringable接口（PHP 8.0+）做上下文序列化；在 PHP 7.4 下运行会 fallback 到__toString()，但若日志上下文对象没实现该方法，就静默丢数据 - ThinkPHP 5.1 默认绑定了 Monolog 1.x，它兼容 PHP 5.6+，但不支持 PSR-3 的
log($level, $message, $context)第三个参数传Throwable实例——这个功能是 PSR-3 后期补丁加的，Monolog 1.x 只认Exception - 如果你在 PHP 8.1+ 项目中用
LoggerInterface::error('msg', ['exception' => $e])，其中$e是TypeError实例，Monolog 2.9+ 会自动提取堆栈；但 Monolog 1.26 会把它当普通数组处理，丢失 trace - 不要在
catch块里直接写$logger->error('failed', $e)——PSR-3 明确要求第三个参数是array，传Throwable属于实现层扩展行为，跨版本不保底
composer dump-autoload -o 生成的静态映射表、php-cs-fixer 的规则集、以及日志库的 minor 版本，三者都隐式绑定了 PHP 小版本号。改一个，另外两个可能就失效。 
